1358469180 Q * quasisane Ping timeout: 480 seconds
1358470868 J * quasisane ~sanep@0001267b.user.oftc.net
1358472226 M * Bertl off to bed now ... have a good one everyone!
1358472232 N * Bertl Bertl_zZ
1358480372 J * clopez ~clopez@9.12.117.91.dynamic.mundo-r.com
1358485287 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1358488076 N * Bertl_zZ Bertl
1358488079 M * Bertl morning folks!
1358490454 Q * clopez Ping timeout: 480 seconds
1358490834 Q * FireEgl Read error: Operation timed out
1358491511 J * FireEgl ~FireEgl@173-25-83-57.client.mchsi.com
1358491613 Q * FireEgl Read error: Connection reset by peer
1358492112 J * nkukard_ ~nkukard@196-210-205-18.dynamic.isadsl.co.za
1358492260 Q * _WildPikachu_ Ping timeout: 480 seconds
1358492388 J * Guy- ~korn@elan.rulez.org
1358493607 M * Bertl off for now ... bbl
1358493612 N * Bertl Bertl_oO
1358495276 J * Ghislain ~aqueos@adsl1.aqueos.com
1358501907 Q * Guy- Read error: Operation timed out
1358502933 J * Guy- ~korn@elan.rulez.org
1358503153 M * BlackPanx i have a weird thing
1358503157 M * BlackPanx our vserver is started
1358503158 M * BlackPanx and running
1358503168 M * BlackPanx has all files on it, can write and works properly
1358503170 M * BlackPanx but on host
1358503180 M * BlackPanx when i try to go to /vservers/my_server
1358503184 M * BlackPanx i only see dev
1358503185 M * BlackPanx file
1358503188 M * BlackPanx nothing else
1358503222 M * BlackPanx while other servers that actually run have all / directories
1358503282 M * BlackPanx oh damn
1358503285 M * BlackPanx i see...
1358503300 M * BlackPanx i have this vserver on LV...
1358503320 M * BlackPanx and not in /vservers/
1358503323 M * BlackPanx nevermind
1358503325 M * BlackPanx my bad
1358504397 M * Bertl_oO np
1358507224 Q * fisted Ping timeout: 480 seconds
1358508847 Q * ircuser-1 Read error: Operation timed out
1358509236 J * fisted ~fisted@b2b-46-252-140-2.unitymedia.biz
1358509252 Q * fisted Remote host closed the connection
1358509273 J * fisted ~fisted@b2b-46-252-140-2.unitymedia.biz
1358509338 Q * fisted Remote host closed the connection
1358511104 M * Bertl_oO off for a nap ... bbl
1358511114 N * Bertl_oO Bertl_zZ
1358512044 J * clopez ~clopez@9.12.117.91.dynamic.mundo-r.com
1358512670 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1358514874 J * arekm ~arekm@ixion.pld-linux.org
1358515042 Q * arekm 
1358515043 J * arekm ~arekm@ixion.pld-linux.org
1358515856 J * thierryp ~thierry@2a01:e35:2e2b:e2c0:15be:ae55:c102:87cd
1358520546 Q * ircuser-1 Remote host closed the connection
1358522538 M * Jb_boin are unify/hashify function still supposed to be usable on recent util-vserver and kernels (3.2)?
1358523066 M * wurtel__ hi, I noticed while using the 'ps' command in a vserver with debian testing that the start times of all processes were listed as '2012'. I found it was down to a patch in procps: "Read system time from /proc/stat instead of calculating - From SuSE" patch btime-from-proc-stat
1358523104 M * wurtel__ would it be possible to "fix" the btime entry in /proc/stat inside vserver context to show the start time of the vserver?
1358524095 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1358525366 J * fisted ~fisted@xdsl-78-35-93-62.netcologne.de
1358525473 M * Ghislain jb_boin: they work ok for us on 3.2 and 3.4, i do see only xfs that can be an issue for 3.6+
1358525541 N * Bertl_zZ Bertl
1358525545 M * Bertl back now ...
1358525597 M * Bertl wurtel__: what kernel/patch version?
1358526748 M * wurtel__ Bertl: good question, the answer is: too old :)  I just tested with 2.3.5.3 and it's fine; so you can forget I asked :)
1358526966 M * Bertl okidokili :)
1358529285 J * Walex ~Walex@78-86-80-54.zone2.bethere.co.uk
1358529683 M * Jb_boin mhh
1358529775 M * Jb_boin if i use vserver XXX hashify i got : /usr/sbin/vserver: line 255: /usr/lib/util-vserver/vhashify: No such file or directory
1358529775 M * Jb_boin /usr/sbin/vserver: line 255: exec: /usr/lib/util-vserver/vhashify: cannot execute: No such file or directory
1358529792 M * Jb_boin using util-vserver and kernel 3.2 from beng repo
1358529826 M * Jb_boin i assume there are some missing files in the packages
1358529884 M * Bertl looks like. please double check that they are indeed missing in the package (might be a missing library dependancy as well) and report to beng
1358532728 J * Seattle ~chatzilla@c-24-34-74-228.hsd1.ma.comcast.net
1358532830 M * Seattle Hi All - we've been experimenting with encrypting /home on guest.  Have ended up getting Encfs (not ecryptfs) to work....are stuck though getting it to automount.  Unless we start mount manually and provide password, we connect but default /home files get created (assume from skel), and encrypted area will there but not mounted.  Do we need to mess with the fstab in the vdir?
1358532880 M * Seattle PS:  by "be there", mean if we log out, mount the encrypted area manually, and log in again, see data that is in encrypted area
1358532938 M * Seattle PPS have tried various posts on google that seem to mess with PAM to get encrypted areas to automount at login, and while we may not have done them correctly, no joy so far
1358533026 M * Seattle PPPS this may have nothing to do with Vserver, and if so, would be useful to "rule that out"
1358533305 M * Bertl trying to understand the problem, but I'm a little confused by the description :)
1358533343 M * Bertl automount means that it is started without user intervention, yes?
1358533356 M * Bertl if so, where does the passphrase come from?
1358534187 Q * ensc|w Remote host closed the connection
1358534198 J * ensc|w ~ensc@www.sigma-chemnitz.de
1358534291 Q * Walex 
1358534321 Q * clopez Ping timeout: 480 seconds
1358534687 M * Seattle Hi Bertl - yes, want to encrypted home to be available, probably when guest boots but possibly when user tries to ssh.  Passphrase is created when encrypted the /home, and is the same (per some of the posts) as login pw.
1358534752 M * Seattle So, again, can ssh in and all is well (does not ask for password - using ssh passwordless authentication with authenticated_keys) if we mount the encrypted home manually.
1358534836 M * Bertl okay, so how is the automount supposed to get the passphrase?
1358534884 J * clopez ~clopez@9.12.117.91.dynamic.mundo-r.com
1358534890 M * Bertl is it basically 'known' to you? i.e. do you just set it to something known when the guest is created?
1358534934 M * Bertl and if so, where does the automounter run and how is it configured to use the appropriate passphrase?
1358535056 M * Seattle Yes - we create it randomly, but we "know it".  Some of the posts suggest putting in a "volume definition" line in "/etc/security/pam_mount.conf.xml" but that hasn't worked so far.  
1358535110 M * Seattle E.g,, post about pam_mount to automatically mount encrypted Filessystem in reference to using dropbox (we're not trying to use dropbox per se, but were trying this approach)
1358535117 M * Bertl sounds like you want to do the mount from inside the guest, yes?
1358535160 M * Bertl if so, does the guest have the necessary capabilities to do this kind of mount?
1358535172 J * hijacker_ ~hijacker@cable-84-43-134-121.mnet.bg
1358535212 M * Seattle Yes, want to mount inside the guest.  I'm assuming it has the necessary capabilities because we can manually mount the encrypted area (we get asked for the password, enter it, and the encrypted area mounts).
1358535278 M * Bertl okay, and what does pam log regarding the mount (when you try to do it automagically)?
1358535321 M * Seattle Don't know!  Sounds like that is where we should look?
1358535379 M * Bertl would be a good start, I'd say ... I'd also test with a script doing the automated mount without userintervention (i.e. without asking for a password) 
1358535442 M * Seattle OK - will do.  Thanks!  
1358535449 M * Bertl np
1358535795 Q * clopez Ping timeout: 480 seconds
1358536305 J * clopez ~clopez@9.12.117.91.dynamic.mundo-r.com
1358539697 M * sannes How high can the context id be?
1358540416 M * Bertl depends on the kernel, but nowadays it is 16bit with 0 and 1 as special context ids (as well as -1, -2 for debugging), so 65533 is a good upper limit
1358540597 M * sannes Hm, if I generate throw away vservers and delete them, then I'm bound to end up in trouble if I don't take into account .. does dynamic context ids work these days?
1358540635 M * Bertl they work, but they are done in userspace
1358540686 M * sannes that works for me :)
1358540743 M * sannes Does mixing static and dynamic work?
1358540765 M * Bertl yes, AFAIK, there is no problem with that
1358540812 M * Bertl (as long as you do not use the IDs assigned to 'dynamic' guests as static ones :)
1358540843 M * sannes How do I choose a range for dynamic?
1358540872 M * sannes When we talk about dynamic we are not talking about .defaults/context.next are we?
1358540902 M * Bertl that is the mechanism used, yes
1358540939 M * Bertl I'm pretty sure you can easily confine the script(s) to a certain range
1358541086 M * Bertl you can also implement your own mechanisms to pick a unique context id when the guest is created
1358541088 M * sannes Seems like it will just +1 until it goes over .. starting at context.start
1358541105 M * Bertl precisely, but it should avoid existing contexts
1358541138 M * sannes Yes, but wil stop work ing at 65533 + 1
1358541177 M * Bertl if you filled up all the space between context.start and 65533, then yes
1358541204 M * Bertl (but same was valid for the 'old style' dynamic contexts
1358541207 M * Bertl )
1358541213 M * Bertl s/valid/true/
1358541226 M * sannes well, it does not have any "clear"
1358541250 M * sannes not that it matters much, just needed to know if I needed to work around it :)
1358541279 M * sannes I was hoping I could be lazy :P
1358541428 M * Bertl I was hoping it does some checks like 'does the xid exist?' but it seems it doesn't do that (yet), so I guess you need to do that yourself for now
1358541468 M * Bertl IMHO the simplest approach would be to check for the next free context with the same generator already used
1358541514 M * Bertl i.e. just compare all the guest contexts (in /etc/vservers/) against the new generator number until you find an unused one
1358541545 M * Bertl make sure to keep the first one around to avoid endless loops
1358541554 J * _WildPikachu_ ~nkukard@196-210-204-27.dynamic.isadsl.co.za
1358541701 Q * nkukard_ Ping timeout: 480 seconds
1358543294 M * Bertl off to bed now ... have a good one everyone!
1358543304 N * Bertl Bertl_zZ
1358543683 J * bonbons ~bonbons@2001:a18:20a:1601:e947:b29f:b173:ed1f
1358545193 Q * hijacker_ Quit: Leaving
1358546449 J * cuba33ci_ ~cuba33ci@114-25-195-121.dynamic.hinet.net
1358546800 Q * cuba33ci Ping timeout: 480 seconds
1358546808 N * cuba33ci_ cuba33ci
1358549348 Q * bonbons Quit: Leaving
1358549467 Q * ircuser-1 Read error: Operation timed out
1358550010 Q * fisted Remote host closed the connection
1358550070 J * fisted ~fisted@xdsl-84-44-226-175.netcologne.de