1412812802 Q * fisted Remote host closed the connection
1412812820 J * fisted ~fisted@xdsl-87-78-230-52.netcologne.de
1412817898 J * Thomas ~user@HSI-KBW-095-208-191-224.hsi5.kabel-badenwuerttemberg.de
1412823457 P * Thomas 
1412824025 M * Bertl_oO off to bed now ... have a good one everyone!
1412824030 N * Bertl_oO Bertl_zZ
1412827082 J * zerick ~eocrospom@190.187.21.53
1412833821 J * Ghislain ~aqueos@adsl1.aqueos.com
1412833935 M * undefined gnarface, yoshi314_: http://paste.linux-vserver.org/256361
1412833964 M * undefined that's the patch to fix up the "krag_t" problem
1412834083 M * undefined i created that patch back on sep 9 (according to the file's timedate stamp), but i see Bertl_zZ hasn't released a new linux-vserver patch since then (incorporating that fix)
1412835772 Q * zerick Ping timeout: 480 seconds
1412838899 Q * Romster Quit: Geeks shall inherit properties and methods of object earth.
1412839751 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com
1412841470 M * gnarface undefined: thanks, that's basically what i had done, but its good to know it was correct
1412841487 M * gnarface undefined: any idea about the thing where it won't compile with user namespaces enabled?
1412841663 J * BenG ~bengreen@212.183.128.12
1412841778 M * Corsac undefined: so your patch appears to work just fine here too
1412841782 M * Corsac (for CAP_CONTEXT)
1412845011 Q * BenG Ping timeout: 480 seconds
1412845073 J * theocrite ~Hubert@kim.theocrite.org
1412847547 J * BenG ~bengreen@host-92-27-135-217.static.as13285.net
1412852827 N * Bertl_zZ Bertl
1412852839 M * Bertl morning folks!
1412853218 M * gnarface 'morning Bertl 
1412853322 M * gnarface Bertl: so about that inability to compile with user namespaces enabled, could you explain to me what that's actually for and why its ok to leave it out?
1412853387 M * Bertl yes, there are many different namespaces appearing in the mainline kernel since about 3 years
1412853413 M * Bertl we are constantly trying to incorporate them into Linux-VServer as soon as they become useable/stable
1412853431 M * Bertl this has basically happened for all spaces except for the user namespace
1412853473 M * Bertl Linux-VServer was developed more than 10 years ago, so it doesn't really need any of thos spaces
1412853496 M * gnarface hmm. i see. so leaving it out won't really mark a regression in security over previous versions?
1412853560 M * Bertl until recently, we blocked the user namespace selection from the Linux-VServer patch, which is why the build issues (preparations for getting the user namespace to play nicely with Linux-VServer) appeared
1412853577 M * gnarface ah i see
1412853633 M * gnarface so, if i go forward with this kernel build and user namespaces get fixed later, and i want to rebuild with the fix and enable them, will i have to recreate all my vservers or the filesystem they're on or user permissions or anything like that?
1412853689 M * gnarface or would vserver guests made without that feature still be completely compatible with a kernel built with that feature later?
1412853697 Q * Aiken Remote host closed the connection
1412853726 M * Bertl they are supposed to work just fine once the user namespace is enabled (with no change to the current state)
1412853806 M * gnarface alright
1412856001 Q * fisted Remote host closed the connection
1412856020 J * fisted ~fisted@xdsl-81-173-185-248.netcologne.de
1412856898 M * gnarface hmm. what characters are valid for vserver names?
1412857733 Q * BenG Quit: I Leave
1412857775 M * Bertl I'd stick with alphanumeric starting with a letter
1412857796 M * Bertl but basically everything you can get through the bash scripts unharmed should be fine
1412857825 M * undefined gnarface: you're lucky the kernel won't compile with user_ns, because once upon a time, the kernel would compile but user_ns broke linux-vserver at run-time
1412857846 M * gnarface undefined: ouch
1412857858 M * gnarface Bertl: i guess i was just wondering mostly if - and _ are ok too
1412857870 M * gnarface Bertl: and what the max character length is
1412857970 M * Bertl similar to host names
1412857982 M * gnarface ok
1412857986 M * gnarface thanks
1412857988 M * Bertl they are only stored in the kernel for reference
1412857995 M * undefined Corsac: thanks for testing the CAP_CONTEXT patch!
1412858002 M * Bertl i.e. they are not used by the kernel, userspace handles that
1412858977 M * gnarface hmm.  i'm trying to build new vservers now, i haven't done this since kernel 3.2.2 and its giving me the error "Cache-directory '/var/cache/vservers' does not exist or is invalid" 
1412859010 M * gnarface is that a completely new thing, or does it correspond to something i'd be familiar with from using the old stock squeeze tools?
1412859020 M * gnarface maybe /var/lib/vservers.rev or something?
1412859044 M * gnarface (i also had to create /var/lib/vservers due to a similar error but i know what that is for)
1412859150 M * gnarface hmm.  or should it have created these for me and i broke it because i used checkinstall instead of dpkg-buildpackage ?
1412859189 M * Bertl there is a build howto on the wiki
1412859215 M * gnarface yea but i wanted it to be packaged
1412859217 M * Bertl it is rather straight forward, but you usually want to read and do what the tools tell you even during build
1412859241 M * gnarface yea, the note is rather straight forward but it looked like it was just gonna make install spray files all over my harddrive unpacakged
1412859251 M * gnarface i don't like doing that
1412859263 M * gnarface additionally the note was missing a couple necessary configure flags
1412859273 M * Bertl like?
1412859304 M * gnarface hang on i have to find where it stored it in the build tree
1412859380 M * gnarface oh, just one actually: --libexecdir=/usr/lib
1412859409 M * gnarface i also set --with-vrootdir=/var/lib/vservers too though
1412859435 M * gnarface i was trying to make it as much like the directory layout i was familiar with from squeeze 
1412859439 M * Bertl why not use one of the debian packages if you are on debian and want a package?
1412859481 M * gnarface because debian has removed vservers from the distro at ... i thought you told me it was at your request
1412859486 M * gnarface maybe someone else said that, it was a long time ago
1412859498 M * Bertl yes, but psand has nice and recent packages
1412859507 M * Bertl (they are also listed/linked on the wiki)
1412859522 M * gnarface yea but i'm keen to build my own if they're not official 
1412859539 M * gnarface using 3rd party packages violates debian dogma 
1412859554 M * gnarface this way at least i know where it put everything
1412859556 M * Bertl that's fine, but then make sure to get the post install stuff right :)
1412859578 M * gnarface so you're saying it SHOULD have created those directories?
1412859592 M * gnarface i'm willing to believe checkinstall broke that
1412859594 M * Bertl i.e. do in your packages whatever is necessary to have the same result as with a manual install
1412859621 M * gnarface well the thing is i can take it out and try again
1412859634 M * gnarface but i have a question about the build command: make && make install install-distribution
1412859655 M * gnarface is the "install-distribution" part supposed to actually make a package from the source?
1412859673 M * gnarface it didn't seem apparent that it would do that, but i didn't see the ./debian/ directory before
1412859676 M * Bertl no, that creates the necessary directories and such
1412859692 M * gnarface did checkinstall create the ./debian directory? or did a developer put that there for dpkg-buildpackage ?
1412859707 M * gnarface if i'd noticed its presence before i tried checkinstall, i would have tried dpkg-buildpackage instead
1412859720 Q * undefined Quit: Closing object
1412859725 M * Bertl no idea, you have to check with daniel_hozac, I'm not really using debian
1412859764 M * gnarface ok, well thanks for your patience 
1412859782 M * Bertl you're welcome!
1412859879 J * undefined ~undefined@00011a48.user.oftc.net
1412859981 M * ard gnarface : you can also just do dpkg-buildpackage -rfakeroot to build util-vserver
1412860075 M * gnarface ard: thanks.  so it appears, but now that i'm looking at the postinst scripts, it doesn't appear they're sensitive to things like setting "--with-vsrootdir" on the configure line to anything other than default 
1412860585 M * gnarface Bertl: with regards to this thing, do i still need to do setattr --barrier on my vservers mountpoint?: http://linux-vserver.org/Secure_chroot_Barrier#Solution:_Secure_Barrier 
1412860600 M * gnarface Bertl: need to/should do?
1412860620 M * gnarface ard: do you know?
1412860624 M * Bertl if your filesystem supports the barrier, then it can't hurt
1412860633 M * Bertl but it shouldn't be necessary anymore
1412860638 M * gnarface ok, noted
1412860907 M * gnarface hmm. odd, says my filesystem supports it, but its not responding to setattr
1412860908 M * gnarface oh well
1412861537 M * gnarface well so far it appears as though the only important things checkinstall missed by leaving out the postinst scripts that weren't mentioned as manual steps on http://linux-vserver.org/Installation_on_Debian were the creation of the directories for /var/cache/vservers, and /var/lib/vservers, and it would have created /var/lib/vservers in the wrong place
1412861618 M * gnarface (it appears it would have created it at /vservers, the default, ignoring the setting of --with-vrootdir=)
1412861676 M * gnarface hmm. although maybe that's expected behavior considering the rules file, nevermind me
1412861724 M * gnarface perhaps http://linux-vserver.org/Installation_on_Debian should simply be updated to mention all you need to do is use dpkg-buildpackage -us -uc -rfakeroot or whatever
1412862691 M * Bertl please update it when an update is necessary
1412863420 M * gnarface uh, i didn't realize i was allowed to
1412863463 M * gnarface if i am i suppose i should want to confirm with someone that is actually the recommended approach in debian now
1412863492 M * gnarface i'm guessing these instructions might predate the presence of the ./debian directory and pre/postinst scripts in the source 
1412864002 J * Wermwud ~Wermwud@69-29-150-18.stat.centurytel.net
1412864518 M * ard gnarface : the util-vserver packaging is not compliant with the debian filesystem "standards"
1412864552 M * ard but as far as useability goes, it is preferrable to the previously official debian version
1412864561 M * gnarface ard: i'm seeing that, though honestly it doesn't appear that it would be difficult to alter it to comply with fhs 2.3
1412864624 M * gnarface ard: really its appears to merely be the question of a couple directory locations that are autoconf-configurable
1412864706 M * gnarface ard: (and then updating the pre/post scripts to match or detect right)
1412871204 J * jrklein_ ~osx@proxy.dnihost.net
1412871232 Q * jrklein Read error: Connection reset by peer
1412874079 J * zerick ~eocrospom@190.187.21.53
1412874449 J * bonbons ~bonbons@ppp-156-215.adsl.restena.lu
1412884218 Q * _BWare_ Remote host closed the connection
1412884329 J * BWare ~itsme@31.25.99.5
1412884889 J * Aiken ~Aiken@d63f.h.jbmb.net
1412890706 Q * bonbons Quit: Leaving
1412892875 Q * Wermwud Quit: Leaving (Please imagine me slamming the door on my way out)
1412896105 Q * funnel Remote host closed the connection
1412896122 J * funnel ~funnel@0001c7d4.user.oftc.net
1412896376 Q * hparker Quit: I've fallen off the 'net and can't get up
1412897028 Q * funnel Remote host closed the connection
1412897045 J * funnel ~funnel@0001c7d4.user.oftc.net
1412897894 J * hparker ~hparker@0000fb24.user.oftc.net