1187222409 J * coderanger_ ~coderange@1cc-dhcp-120.media.mit.edu
1187222452 M * Bertl wb coderanger_!
1187222470 M * coderanger_ alo
1187222616 M * daniel_hozac Bertl: is "filesystem tag" cool with you? i feel like just describing it as tag isn't too descriptive.
1187222695 M * Bertl in a description or in the code?
1187222736 M * daniel_hozac description, this in pariticular was for --version.
1187222755 M * Bertl yeah, filesystem (or better inode) tag is fine
1187222780 M * daniel_hozac but then with propagation it's dentry? :)
1187222797 M * Bertl the tag is always on the inode
1187222812 M * daniel_hozac yeah.
1187222827 M * Bertl or if you like, call it persistent filesystem tag
1187222840 M * Bertl we used that for some time now, at least I did :)
1187223085 M * daniel_hozac so, VCI-bit or version-based?
1187223188 M * Bertl hmm, can we somehow put it into the space stuff?
1187223204 M * Bertl (just an idea)
1187223237 M * daniel_hozac IMHO that should be reserved for things that you enter with vc_enter_space()
1187223254 M * daniel_hozac (that's my opinion because that's what the utils assume :))
1187223264 M * Bertl okay, yeah
1187223282 M * Bertl I think, VCI it is then
1187223300 M * daniel_hozac okay.
1187223333 M * Bertl we should make a table for the vci stuff on the wiki
1187223352 M * Bertl what VCI bits do the tools (across the various version) use now?
1187223417 M * daniel_hozac #define VC_VCI_NO_DYNAMIC               (1 << 0)
1187223417 M * daniel_hozac #define VC_VCI_SPACES                   (1 << 10)
1187223417 M * daniel_hozac #define VC_VCI_NETV2                    (1 << 11)
1187223479 M * Bertl okay, let's make it
1187223484 M * Bertl VCI_KCBIT_PPTAG = 28,
1187223511 M * daniel_hozac okay.
1187223538 M * daniel_hozac hmm, are we running out of bits?
1187223559 M * Bertl not really, but I'm trying to keep a few 'ranges' free, just in case
1187223564 M * daniel_hozac ah, okay.
1187223588 M * Bertl but when we do, we simply switch to 64bit
1187223602 M * Bertl I think I reserve a bit for that right now :)
1187223726 M * Bertl hmm, actually we can do a bunch of even niftier things with the current interface
1187223771 M * Bertl daniel_hozac: please consider the following right now (if not already done so), the vc_get_vci() has an argument, which is currently supposed to be 0
1187223817 M * daniel_hozac data or id?
1187223844 M * Bertl id, when we ran out of bits, or just feel like opening new ranges, we set the upper most bit (31) and pass the other bits in (id=1,2, ...)
1187223900 M * Bertl in proc, this will be simply shown as XXXX:XXXX:XXXX ...
1187223935 M * daniel_hozac which other bits? you mean to retrieve 32-bit at a time?
1187223953 M * Bertl let me rephrase, the idea is quite simple:
1187223973 M * Bertl how to retrieve the full? vci information
1187223995 M * Bertl - vc_get_vci(0) -> 32 bit
1187224044 M * Bertl - iif bit 31 is set, vc_get_vci(1) -> 32 bit [32:63]
1187224054 M * Bertl - iif bit 31 is set, vc_get_vci(2) -> 32 bit [64:95]
1187224065 Q * Rich_Estill Quit: Leaving
1187224066 M * daniel_hozac right, okay.
1187224089 M * Bertl we won't ever use up more than 64 bits, but it is extensible
1187224147 M * Bertl to be backwards compatible, you must not check vc_get_vci(1) unless bit 31 is set
1187224178 M * daniel_hozac right.
1187224186 M * Bertl         VCI_KCBIT_MORE = 31,
1187224246 M * daniel_hozac could we agree on 64-bit max?
1187224261 M * daniel_hozac otherwise i'm gonna have to make the utils use an array for it :)
1187224266 M * Bertl for now, we probably won't even go above 32
1187224299 M * Bertl so 64 is fine (for now) if we go above that, you can make the utils use two values
1187224345 M * Bertl but as I said, I doubt we will go above 32 for some time
1187224554 M * dallas a non-grsec vserver kernel didn't change anything with my NetApp .snapshot oddity, btw
1187224579 M * daniel_hozac dallas: i kind of expected that, to be honest. this appears to be an NFS oddity.
1187224589 M * Bertl daniel_hozac: interesting, could you explain to me what the issue is (short version)?
1187224596 M * Bertl or maybe dallas?
1187224598 M * dallas it was worth a try, I guess!
1187224599 M * daniel_hozac NFS will perform mounts.
1187224632 M * daniel_hozac without giving the guest BINARY_MOUNT, it's impossible to use dallas's NFS-server.
1187224652 M * dallas it's a network appliance filer
1187224671 M * Bertl ah, so the NFS server is inside a guest?
1187224676 M * daniel_hozac and even when you give the guest that, the users will not be able to access it, because they don't have the capability the vx_check is looking for.
1187224680 M * daniel_hozac no, NFS client.
1187224709 M * Bertl so by default, those are mounts done from userspace?
1187224740 M * daniel_hozac not all of them.
1187224743 M * dallas the mounts are done by root
1187224760 M * Bertl so how are the permissions (capabilities) missing?
1187224761 M * daniel_hozac see fs/nfs/namespace.c:nfs_do_submount
1187224764 M * dallas the NetApp systems have a .snapshot automatic revision system that appears as part of the filesystem
1187224818 M * dallas for some reason moving into the .snapshot part of the filesystem is seen as a mount attempt by the kernel
1187224852 M * daniel_hozac yeah, it's an NFS-thing.
1187224907 M * dallas the .snapshot part of the filesystem is read-only to everyone (including root)
1187224927 M * Bertl okay, so that is what nfs calls subtrees, right?
1187224964 M * Bertl they have a separate export entry or such and you basically walk into them via the filesystem
1187225016 M * dallas there's not a separate export, no.  you can 'cd .snapshot' from anywhere in the mounted filesystem and you'll see the hourly.0, hourly.1, nightly.0, nightly.1 directories within that each have a past view of your current position in the filesystem
1187225050 M * dallas so if you're in /home/myuser you'll see snapshots for /home/myuser, but if you're in /home you'll see for all of /home, etc.  That's not really relevant to the problem, probably, but it's more detail
1187225051 M * daniel_hozac it's probably an implementation detail for the filer.
1187225098 M * dallas I don't know how it's handled as far as NFS operations go but I know it's always worked as expected for all of our linux nfs clients... never any oddities
1187225119 M * daniel_hozac because the kernel does the mounting for you :)
1187225119 M * dallas you can "cd .snapshot" as any user, as well.  no root required
1187225133 M * Bertl now that is the point I do not understand 
1187225163 J * fatgoose ~samuel@bas4-quebec14-1128560198.dsl.bell.ca
1187225165 M * daniel_hozac ?
1187225169 M * Bertl IIRC, we do not block mount attempts (kernel side) if they would work fine on an unpatched kernel
1187225177 M * dallas it doesn't feel like an nfs mount being done in the background as far as filesystem operations go
1187225177 M * daniel_hozac actually, we do.
1187225198 M * Bertl we do?
1187225204 M * daniel_hozac vx_capable vs. vx_ccaps in vfs_kern_mount and do_kern_mount (in 2.6.19)
1187225270 M * Bertl but I'm missing the point somehow ... please correct me where I'm wrong:
1187225301 M * Bertl - BINARY_MOUNT is required for NFS mounts
1187225324 M * daniel_hozac note that the original mount isn't done from the inside,  AFAIU. dallas?
1187225341 M * Bertl - it is overlayed with the CAP_SYS_ADMIN
1187225343 M * dallas right, the original mount is done when the vserver is started up by the host
1187225373 M * dallas using an fstab file on the host.  an fstab.remote doesn't change anything.. I tried that as first guess
1187225413 M * Bertl - soo, to do a vfs_kern_mount() you need to have both
1187225433 M * daniel_hozac Bertl: right. thing is, vanilla vfs_kern_mount doesn't check for caps at all.
1187225468 M * dallas I appreciate you guys taking the time to think about this, btw!  You looked busy already
1187225473 M * Bertl daniel_hozac: hmm, hmm, so basically anyone can do mounts?
1187225478 M * daniel_hozac yes.
1187225502 M * Bertl interesting detail, didn't think of that ...
1187225512 M * daniel_hozac personally, that seems like a security issue, but it seems to be intentional.
1187225527 M * dallas on our non-vserver setup, you do have to be root (as expected) to mount a NetApp volume.  once mounted anyone with access to the filesystem can also access the .snapshot portion
1187225533 M * Bertl but we could easily restore that behaviour, no?
1187225544 M * Bertl we just have to drop the CAP_SYS_ADMIN check
1187225544 M * daniel_hozac yeah, just vx_capable->vx_ccaps.
1187225573 M * Bertl dallas: would you like to try that?
1187225578 M * daniel_hozac or, hmm. that would break the host.
1187225605 M * Bertl not if done properly
1187225619 M * daniel_hozac well of course :)
1187225630 M * dallas the host doesn't actually need its own nfs access to these volumes currently, if that helps
1187225638 M * Bertl let me have a look what the actual changes are, sec
1187225657 M * dallas it has them mounted now as a convenience.  I'm willing to try whatever you think might work...
1187225680 M * daniel_hozac dallas: it should be done right :)
1187225682 Q * Piet Quit: Piet
1187225699 M * dallas indeed!
1187226012 M * Bertl what about:
1187226014 M * Bertl        if ((type->fs_flags & FS_BINARY_MOUNTDATA) &&
1187226014 M * Bertl 	       !vs_check(0, VS_ADMIN) && !vx_ccaps(VXC_BINARY_MOUNT))
1187226055 M * daniel_hozac s/vs_check/vx_check/?
1187226061 M * Bertl yep
1187226072 M * daniel_hozac yeah, that's what i was thinking.
1187226115 M * Bertl we probably would want similar for proc and devpts too, I guess
1187226130 M * Bertl but that should not be an issue here
1187226145 M * daniel_hozac hmm? users aren't able to mount proc or devpts normally?
1187226188 M * Bertl well, it shouldn't be blocked from our side, it should be left to security_sb_kern_mount()
1187226243 M * daniel_hozac i think the vx_capable in do_new_mount takes care of that.
1187226272 M * Bertl okay, let me rephrase that:
1187226310 M * Bertl we do not need to check for masked SYS_ADMIN/BINARY_MOUNT for in the second case either
1187226332 M * Bertl we just need to check for host and vx_ccaps(VXC_BINARY_MOUNT)
1187226342 M * daniel_hozac ah, you mean the other hunk?
1187226343 M * daniel_hozac yeah.
1187226347 M * daniel_hozac .
1187226348 M * Bertl yep
1187226380 M * Bertl now, IIRC, we added that cap check because some security issue was reported, no?
1187226409 M * Bertl I do not think that we always checked for SYS_ADMIN there
1187226429 M * daniel_hozac yeah, that's pretty recent.
1187226444 M * daniel_hozac i don't remember the details though... will try to find the delta.
1187226476 M * Bertl okay, tx, dallas, could you please try the following change (just to see if that fixes your issues)
1187226508 M * dallas sure, is this a kernel patch source change?
1187226508 M * Bertl in fs/super.c ~870
1187226585 M * dallas Bertl: ok, that's vfs_kern_mount?
1187226603 M * Bertl http://paste.linux-vserver.org/5885
1187226613 M * Bertl yep, precisely
1187226613 J * friendly12345 ~friendly@ppp121-44-237-56.lns2.mel4.internode.on.net
1187226679 M * Bertl dallas: you do not need to build the kernel from scratch
1187226694 M * Bertl if you have a build dir (from the kernel build) just change this and do 'make'
1187226704 M * Bertl should just take a few seconds
1187226778 M * dallas Bertl: I'm seeing that line in do_kern_mount at line 928 or so.  Am I using the wrong version?
1187226827 M * daniel_hozac you're using 2.6.19, that's fine.
1187226827 M * Bertl well, probably a different one, I'm looking at 2.6.22.2 here
1187226848 M * Bertl but there is only one place which has this check, so if you see it, you're fine
1187226853 M * dallas oh oh, ok.  so I should change it in do_kern_mount, then?  ok, good
1187226932 Q * fatgoose Quit: fatgoose
1187226996 M * daniel_hozac Bertl: tag_cmd.h is missing from include/linux/vserver/Kbuild :)
1187227010 M * Bertl ah, nice catch
1187227017 M * Bertl regarding the additional check in vc_task_xid()
1187227031 M * Bertl I think that is obsolete already
1187227038 M * Bertl because:
1187227040 M * daniel_hozac nothing broke when you removed it?
1187227054 M * Bertl didn't try yet, but let me argue :)
1187227069 M * Bertl         __VCMD(task_xid,         2, VCA_NONE,   0);
1187227079 M * Bertl that means, perm=2, right?
1187227089 M * daniel_hozac yeah.
1187227096 M * Bertl and we have a check:
1187227100 M * Bertl         if ((perm > 1) && !capable(CAP_SYS_ADMIN))
1187227106 M * Bertl right after state=2
1187227136 M * daniel_hozac yeah.
1187227142 M * Bertl and the         if (!capable(CAP_CONTEXT))
1187227150 M * Bertl right before that
1187227188 M * Bertl now, except for the VS_WATCH case, we should be already covered, no?
1187227236 M * daniel_hozac AFAICT, the only thing that check disables is if the context is in SETUP state.
1187227251 M * daniel_hozac and, well, i don't really see the point in that.
1187227280 M * dallas ok, well.. I'm sorry to report that change didn't help my situation.  I have to leave now, though.  I'll check in again later.  Thanks!
1187227307 M * Bertl wow, that was a fast check, np, cya!
1187227327 M * daniel_hozac i think we need to change the other one too.
1187227335 M * Bertl most likely
1187227366 M * Bertl the setup case is handled too, btw
1187227393 Q * dallas Quit: dallas
1187227393 M * Bertl because without VCF_SETUP, it will be blocked 
1187227411 M * Bertl hmm, that might actually cause an issue 
1187227432 M * Bertl in what cases is vc_task_xid invoked?
1187227465 M * daniel_hozac hmm, i'm not reading the code that way.
1187227477 M * Bertl okay, let's hear what you see/read :)
1187227485 M * daniel_hozac IMHO, VXF_SETUP is only used if VCF_ADMIN fails.
1187227496 M * daniel_hozac s/VXF/VCF/
1187227506 M * daniel_hozac as permit = 1 just above those.
1187227521 M * Bertl correct
1187227526 M * daniel_hozac without VCF_ADMIN, there's no way permit will be 0 in the SETUP check.
1187227535 M * daniel_hozac so that shouldn't be a problem.
1187227560 M * Bertl okay, so removing the check shouldn't change anything, yes?
1187227583 M * daniel_hozac well, it would let SETUP contexts call it.
1187227595 M * daniel_hozac but honestly, i don't see a problem with that.
1187227658 M * Bertl would we have a problem if we made it VCF_ADMIN ?
1187227704 M * daniel_hozac hmm, not AFAICT...
1187227728 M * Bertl but actually it is info stuff, so we shouldn't really care
1187227740 M * Bertl you cannot do real harm with that I guess
1187227760 M * Bertl (besides the fact that the setup state is basically secure)
1187227949 M * Bertl we should definitely make a tool/script to test all the syscall command permissions (and display them in a matrix or so)
1187228027 M * daniel_hozac yeah...
1187228308 J * DoberMann_ ~james@AToulouse-156-1-121-253.w90-30.abo.wanadoo.fr
1187228418 Q * DoberMann[ZZZzzz] Ping timeout: 480 seconds
1187228918 M * daniel_hozac Bertl: you wouldn't happen to know whether userspace should use __NR_Linux or similar on architectures that have that in the kernel's unistd.h?
1187229047 M * Bertl you mean for syscall bases?
1187229049 M * daniel_hozac eah.
1187229055 M * daniel_hozac y+
1187229129 M * Bertl what would you use that for?
1187229176 M * daniel_hozac that's what i was wondering. the kernel handles that, yes?
1187229218 M * daniel_hozac i.e. the correct offset is added whenever a syscall is made.
1187229248 M * Bertl yes, that basically is for binary compatibility
1187229272 M * Bertl i.e. if you are running a solaris executable on a linux kernel (or vice versa)
1187229349 M * daniel_hozac right.
1187229390 Q * Radiance Quit: changing servers
1187229410 J * Radiance be848a850d@halt.1984world.eu
1187229443 M * daniel_hozac that means the kernel headers can't be used on those arches, no?
1187229484 M * Bertl hmm, why?
1187229542 M * daniel_hozac hmm, nevermind. i guess it's just smart enough to actually check
1187229581 M * daniel_hozac i.e. if it's a "fully-specified" syscall number, or whether magic should be applied.
1187230136 M * daniel_hozac Bertl: heh, i guess delta-tag-feat01 is missing the hunks for do_vserver?
1187230282 M * Bertl that's in feat02 :)
1187230310 M * daniel_hozac hehe.
1187230535 Q * Johnnie Ping timeout: 480 seconds
1187231072 J * Johnnie ~jdlewis@c-67-163-142-234.hsd1.ct.comcast.net
1187231119 M * daniel_hozac Bertl: dynamic context support is completely removed from 2.3, right?
1187231583 J * wolfhe ~9fe22b2d@207.250.49.6
1187232115 M * Bertl daniel_hozac: yep, it should be
1187232119 M * Bertl welcome wolfhe!
1187232309 M * wolfhe HI everyone
1187232354 M * daniel_hozac i'm about ready to commit the utils with vtag.
1187232386 M * Bertl wow, great!
1187233082 M * daniel_hozac hmm. so the tag has to be migrated before the context.
1187233239 M * Bertl yep, as usual, context is the final one
1187233855 M * daniel_hozac http://people.linux-vserver.org/~dhozac/t/uv-testing/util-vserver-0.30.214-pre2589.tar.bz2
1187233856 Q * Aiken Read error: Connection reset by peer
1187233865 J * Aiken ~james@ppp121-45-255-55.lns2.bne4.internode.on.net
1187234190 Q * Aiken Remote host closed the connection
1187234198 J * Aiken ~james@ppp121-45-255-55.lns2.bne4.internode.on.net
1187234223 Q * Aiken 
1187234241 J * Aiken ~james@ppp121-45-255-55.lns2.bne4.internode.on.net
1187237685 M * Bertl okay, I'm off to bed now .. have a good whatever everyone!
1187237693 N * Bertl Bertl_zZ
1187237726 J * puck ~puck@leibniz.catalyst.net.nz
1187240749 J * emtty ~eric@dynamic-acs-24-154-34-241.zoominternet.net
1187241423 Q * wolfhe Quit: CGI:IRC (EOF)
1187242934 Q * coderanger_ Quit: coderanger_
1187243551 N * DoberMann_ DoberMann
1187243660 J * dna ~dna@219-213-dsl.kielnet.net
1187245470 Q * emtty Ping timeout: 480 seconds
1187246844 N * DoberMann DoberMann[PullA]
1187248066 J * Borg- borg@aprogas.student.utwente.nl
1187250240 Q * ensc Remote host closed the connection
1187251324 J * meandtheshell ~markus@85.127.103.154
1187253826 Q * balbir__ Ping timeout: 480 seconds
1187254334 N * phedny_ phedny
1187256114 J * yarihm ~yarihm@whitehead2.nine.ch
1187257093 M * bXi morning
1187257321 M * yarihm morning everyone
1187257881 M * derjohn is there already a known tool that monitors the processes of all guests (!) from the host-level? And restarts them if needed? As we use rlimits for rss, from time to time the guests processes are killed due to OOM situations. It would be nice, if vserver would offer such a thing, maybe as part of the rss-limit sytem (limit reached, OOM killer killed, after $timeout restart it...)
1187258012 J * Piet hiddenserv@tor.noreply.org
1187258132 J * Risjh rsjds@59.93.135.219
1187258445 M * neuralis derjohn: you can see all processes from the observer context
1187258622 M * derjohn neuralis, sure, but the question was, if i have to configure e.g. monit myself for each guests, or if there is something that e.g. scans for syslog, which processes dies.
1187258666 M * neuralis there's no such thing that i'm aware of, and i suspect everyone would want it to behave differently so it probably doesn't belong in vserver proper
1187258779 M * derjohn neuralis, well, vserver also does the init for the guest (if you dont use initstyle plain), so the argument  that vserver doesnt "know" about is only half of the truth :)
1187258802 M * neuralis right, i wasn't making that argument though
1187258815 M * derjohn but i agree that pidfiles etc are not generally on the same position ...
1187258827 M * derjohn (differnet distros etc....)
1187258868 M * derjohn maybe i'll create a auto-config script for such a task if you run debian guests. it will ceate a conf file for monit.
1187258902 M * derjohn but before, I'll have to check if I do the right thing(tm) [hello Bertl_zZ :) ]
1187259062 M * derjohn hm, if I see in the log that the OOM killer killed a process in context 42 with PID 1111. It should be straighrforward to grep /var/lib/vservers/$vserver/var/run/*pid to see which daemon is was and do a vserver exec /etc/init.s/$daemon .... maybe such a thing. But before doing so, I'll ask around here ;)
1187259077 A * derjohn now off -> hungry ;)
1187259088 M * derjohn neuralis, thx for your input !
1187259546 J * lilalinux ~plasma@dslb-084-058-218-047.pools.arcor-ip.net
1187263724 M * transacid derjohn: nagios could help i guess
1187264262 M * derjohn transacid, probably not more than monit, mon etc. can do. Or ?
1187264324 M * transacid oh ic i didn'T know that monit actually was a piece of software. i assumed it was a short form for "monitoring tool"
1187264353 M * transacid derjohn: but nagios is very powerfull, you should have a look at the docs
1187264540 M * derjohn ah, no, monit is a monitoring software which is more host/shell based than the pile of bugs called "nagios" is. I used Nagios around 2000-2002 but was very disappointed and abandoned it. Plugins did not work as expected, escalation procedures sent alert too often (via sms) or didnt sent alert at all... but maybe the product is nor much more mature. personally I had a look at OpenNMS, which seems to fit much more in my needs (but not the proceess-autorestart
1187264540 M * derjohn -case)
1187264599 M * transacid ah ok
1187264605 M * transacid good luck then further on
1187264691 M * daniel_hozac "Using Java, XML & XSL..." OpenNMS doesn't really seem ideal either :)
1187264711 J * balbir ~balbir@59.145.136.1
1187268407 J * Freax ~Linus@bl7-128-38.dsl.telepac.pt
1187268801 Q * Linus Ping timeout: 480 seconds
1187269066 N * Bertl_zZ Bertl
1187269066 M * Bertl morning folks!
1187269091 M * Risjh morning Bertl :)
1187269360 Q * balbir Ping timeout: 480 seconds
1187269725 Q * Risjh Ping timeout: 480 seconds
1187270100 J * fatgoose ~samuel@206-248-170-5.dsl.teksavvy.com
1187270359 N * virtuoso_ virtuoso
1187270888 J * ema ~ema@fw.galliera.it
1187270905 M * Bertl wb fatgoose! ema!
1187270920 M * fatgoose allo
1187270960 P * friendly12345 
1187271614 J * DavidS ~david@85.125.165.34
1187271637 M * matti Hi B.
1187271638 M * matti :)
1187271697 M * Bertl hey matti! DavidS!
1187271728 M * matti ;]
1187271782 M * DavidS hey Bertl!
1187272242 M * Bertl k, off to the shower now .. bbs
1187272269 J * Risjh rsjds@59.93.135.187
1187272436 Q * Greek0 Remote host closed the connection
1187273398 J * gerrit ~gerrit@c-67-169-199-103.hsd1.or.comcast.net
1187273442 J * balbir ~balbir@122.167.93.202
1187275188 J * bzed ~bzed@dslb-088-068-125-189.pools.arcor-ip.net
1187275283 J * wenchien ~wenchien@59-105-176-11.adsl.static.seed.net.tw
1187276054 Q * Aiken Remote host closed the connection
1187277149 J * Piet_ hiddenserv@tor.noreply.org
1187277279 Q * Piet Remote host closed the connection
1187277877 Q * Hollow Quit: Disconnecting from stoned server.
1187277897 J * Hollow ~hollow@proteus.croup.de
1187278480 J * Julius ~julius@p57B255F8.dip.t-dialin.net
1187278692 Q * Julius 
1187279044 Q * arachnist Quit: brb/bbl
1187279211 J * arachnist arachnist@088156185052.who.vectranet.pl
1187279577 J * ntrs ntrs@68-188-55-120.dhcp.stls.mo.charter.com
1187279822 M * bXi think i found another issue with vservers
1187279893 M * fb heh, 2.2.0.3 with grsec and ipv6 in harry's home. Thanks! :)
1187279922 A * nanonyme drools at 2.3.0.17
1187279950 Q * ntrs__ Ping timeout: 480 seconds
1187279955 M * Bertl bXi: let's hear!
1187280030 M * Risjh hehe
1187280314 J * arcil ~arcil@p5B07735B.dip.t-dialin.net
1187280373 J * bonbons ~bonbons@2001:960:7ab:0:20b:5dff:fec7:6b33
1187280433 M * Bertl okay, heading to the office now .. bbl
1187280434 M * bXi Bertl: i couldnt create a connection to my hostserver 
1187280440 N * Bertl Bertl_oO
1187280457 M * bXi not sure what caused it
1187280471 M * bXi probably some stopping/startng of several vservers
1187280738 Q * arcil Remote host closed the connection
1187280958 J * arcil ~arcil@p5B07735B.dip.t-dialin.net
1187280992 J * arcil_ ~arcil@p5B07735B.dip.t-dialin.net
1187281008 M * fb harry: could you please take a look at the ipv6 patch? I think you've created it using wrong vanilla linux tree
1187281074 M * daniel_hozac fb: you sure you're using the _right_ tree? :)
1187281187 M * fb daniel_hozac: he used the tree with vs patch 
1187281209 M * daniel_hozac so?
1187281229 M * daniel_hozac the IPv6 patch is on-top of the other patches.
1187281262 M * fb but it's grsec + ipv6 
1187281285 M * fb and i'm sure previously it contained all vs + grsec + ipv6
1187281295 M * fb also the name suggests this 
1187281338 M * fb well, i'm probably the only user of this patch, so... ;)
1187281418 Q * lilalinux Remote host closed the connection
1187281439 M * daniel_hozac except for the dontdiff thing, the patch looks fine.
1187281444 M * daniel_hozac i.e. it's only IPv6.
1187281445 M * bXi fb: daniels 2.2.0 ipv6 patch?
1187281464 M * daniel_hozac no, harry's patch.
1187281897 Q * arcil_ Quit: Leaving
1187282196 Q * Risjh Quit: Leaving
1187282238 M * fb daniel_hozac: i also noticed, there's no grsec in grsec patch ;)
1187282281 M * daniel_hozac yes there is.
1187282346 M * fb i mean in ipv6-vs-grsec patch. hmh
1187282371 M * fb so i'm assuming i was wrong about the patch
1187282436 M * daniel_hozac it's _only_ IPv6.
1187282479 M * fb uhm
1187282512 M * daniel_hozac you'll need the correct grsec+vserver patch _before_.
1187282543 Q * ema Quit: leaving
1187282558 M * fb and i was sure it's vs+grsec+ipv6, and it's _only_ ipv6 and it's against vs-grsec version of vserver
1187283264 N * Bertl_oO Bertl
1187283267 M * Bertl back now ...
1187283623 M * harry daniel_hozac: tnx :)
1187283658 M * harry you need a vanilla kernel, the grsec+vserver patch and THEN the ipv6 patch in my ipv6 dir
1187283690 M * matti Hi harry 
1187283700 M * harry heya matti 
1187284070 Q * yarihm Quit: This computer has gone to sleep
1187284252 J * Roey ~katz@dsl093-083-226.wdc1.dsl.speakeasy.net
1187284254 M * Roey hey all!
1187284258 M * Roey Hey Bertl!
1187284259 M * Roey http://www.linux-foundation.org/en/Linux_Weather_Forecast#Forecast_summaries 
1187284259 M * Bertl hey Roey!
1187284274 M * Roey When they mention 'containers', they don't mention Linux-VServer
1187284277 M * Roey :(
1187284549 J * arcil_ ~arcil@p5B07735B.dip.t-dialin.net
1187284567 Q * arcil Read error: No route to host
1187284790 Q * arcil_ Remote host closed the connection
1187284874 J * arcil ~arcil@p5B07735B.dip.t-dialin.net
1187285219 Q * Guy- Quit: leaving
1187285323 J * ensc ~irc-ensc@p54B4CA27.dip.t-dialin.net
1187285378 J * Guy- ~korn@elan.rulez.org
1187285716 J * marcfiu ~mef@aegis.CS.Princeton.EDU
1187286211 M * marcfiu hello
1187286297 J * fatgoose_ ~samuel@206-248-170-5.dsl.teksavvy.com
1187286297 Q * fatgoose Read error: Connection reset by peer
1187286333 J * fatgoose ~samuel@206-248-170-5.dsl.teksavvy.com
1187286781 Q * fatgoose_ Ping timeout: 480 seconds
1187288327 Q * arcil Remote host closed the connection
1187289095 N * Piet_ Piet
1187289586 J * yarihm ~yarihm@84-75-109-39.dclient.hispeed.ch
1187290132 M * Bertl daniel_hozac: what are the patches now missing for ipv6 (on your side?)
1187290169 M * daniel_hozac 2.3.0.17?
1187290189 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-v4rcvsaddr-fix01.diff http://people.linux-vserver.org/~dhozac/p/k/delta-v6rcvsaddr-fix02.diff http://people.linux-vserver.org/~dhozac/p/k/delta-mappedv4-fix01.diff
1187290191 M * Bertl yep
1187290196 M * daniel_hozac with those, it works fine.
1187290516 M * Bertl excellent! tx!
1187291358 J * Julius ~julius@p57B255F8.dip.t-dialin.net
1187292168 M * Bertl daniel_hozac: we are seeing tag_migrate() giving EPERM on the tools you uploaded?
1187292195 M * daniel_hozac hmm? where is it called from?
1187292200 M * daniel_hozac is this with the scripts?
1187292206 M * Bertl yep, testme.sh
1187292268 M * Bertl e.g. chcontext --xid 42 true
1187292295 M * Bertl gives vtags: vc_tag_migrate(): EPERM
1187292355 M * Bertl the version is pre2589 here (maybe I got an older one?)
1187292406 M * daniel_hozac does the context exist?
1187292417 M * Bertl it should not
1187292429 M * daniel_hozac it's working fine here.
1187292445 M * Bertl okay, will investigate and return with more info
1187292489 M * daniel_hozac humm. i'm not using the new chcontext for some bizarre reason.
1187292536 M * daniel_hozac actually, my entire install appears to be more or less broken... let me build another one.
1187292553 M * Bertl np, take your time ...
1187292744 M * daniel_hozac okay, i'm seeing it too...
1187292764 J * ktwilight_ ~ktwilight@38.110-66-87.adsl-dyn.isp.belgacom.be
1187292992 M * daniel_hozac want a new tarball or just the patch?
1187293174 Q * ktwilight Ping timeout: 480 seconds
1187293276 J * coderanger_ ~coderange@1cc-dhcp-90.media.mit.edu
1187293399 M * daniel_hozac http://people.linux-vserver.org/~dhozac/t/uv-testing/util-vserver-0.30.214-pre2590.tar.bz2
1187293512 N * DoberMann[PullA] DoberMann
1187293908 Q * Piet Ping timeout: 480 seconds
1187293915 A * bXi builds that as well
1187294182 A * Freax boas
1187295765 Q * meandtheshell Quit: Leaving.
1187296335 M * Bertl daniel_hozac: setattr still does not allow to change the immutable flag only? or is that just missing from the help?
1187296351 M * daniel_hozac just missing from the help, i guess.
1187296358 M * daniel_hozac i know i added it :)
1187296412 M * Bertl ah, yeah, is there, just a help issue ...
1187297124 N * esa fede
1187297288 J * leebi ~mleeb@80.108.127.20
1187297319 M * Bertl welcome leebi! wb fede!
1187297321 P * leebi 
1187297631 Q * Julius Remote host closed the connection
1187298257 J * FHTech ~Miranda@62.140.244.26
1187298386 M * FHTech Hello why it can guest not be reloaded? command reboot there are no error, but reboot not
1187298517 J * Piet hiddenserv@tor.noreply.org
1187298611 M * daniel_hozac what initstyle?
1187298615 M * Bertl FHTech: you mean, you are rebooting from inside a guest?
1187298684 M * FHTech Bertl: yes, command reboot is carried out on guest
1187298705 M * Bertl FHTech: if you are using sysv init style, you want to use 'reboot -f' instead of reboot
1187298728 M * Bertl (because there is no init to notify :)
1187298758 M * FHTech Bertl: Thanks, now I shall try
1187299201 Q * bonbons Quit: Leaving
1187299509 J * Aiken ~james@ppp121-45-255-55.lns2.bne4.internode.on.net
1187299562 Q * Aiken 
1187299677 M * FHTech Bertl:  Thanks, one more question. 
1187299752 M * FHTech [root@srv ~]# df -m
1187299752 M * FHTech Filesystem           1M-blocks      Used Available Use% Mounted on
1187299762 M * FHTech  Bertl: It is not displayed, used and use %. available shows
1187299802 M * FHTech "/dev/hdv1                 3072         0      2916   0% /"
1187300327 M * Bertl what do you expect there? used disk space or so?
1187300340 M * Bertl check out disk limits for that
1187300468 M * baldy morning guys ;)
1187300556 M * baldy FHTech: do u setup tagxid on your host-system?
1187300621 M * FHTech Bertl: How many remains space and how many all is shows, but does not show how many is used and in %
1187300657 M * baldy FHTech: have a look on my question ,)
1187300700 Q * dna Quit: Verlassend
1187300717 M * FHTech baldy: sorry, how it is possible to check up, it is established or not?
1187300742 M * baldy FHTech: show me the fstab on the host
1187300777 M * baldy btw the mount options
1187300782 Q * DavidS Quit: Leaving.
1187300929 N * DoberMann DoberMann[ZZZzzz]
1187300956 J * Aiken ~james@ppp121-45-255-55.lns2.bne4.internode.on.net
1187301063 M * Bertl FHTech: you need to enable fs tagging and configure the disk limits
1187301072 M * Bertl FHTech: then they will show up properly
1187301119 M * baldy Bertl: jep he forget it
1187301120 Q * yarihm Quit: Leaving
1187301180 Q * quasisane Quit: ERC Version 5.2 (IRC client for Emacs)
1187301354 J * virtuoso_ ~s0t0na@pppoe-219.2.110.89-adsl.spbnit.ru
1187301640 M * FHTech Bertl: thanks
1187301656 M * Bertl np
1187301719 M * FHTech Bertl: Without tagxid restrictions on space for guest operates or not? It will not be displayed only how many it is borrowed
1187301749 M * Bertl without tag(xid) it will not work at all
1187301764 Q * virtuoso Ping timeout: 480 seconds
1187301764 M * Bertl i.e. you can only see the data for the full device
1187301769 P * marcfiu 
1187301859 M * FHTech Bertl: clearly, I shall try to make tomorrow, thanks
1187301871 M * Bertl you're welcome!
1187301894 Q * FHTech Quit: FHTech
1187302131 J * berest ~KVIrc@nat65.homenet.glazov.net
1187302136 M * berest hello )
1187302145 J * bzed_ ~bzed@dslb-084-059-049-094.pools.arcor-ip.net
1187302177 M * Bertl welcome berest!
1187302201 Q * Freax Read error: Connection reset by peer
1187302226 M * berest bertl i have a problem with fb on my GeForce6600GT and kernel 2.6.22.2. what i can do?
1187302236 M * berest what can i do*)
1187302274 M * berest where i can find kernel developer ?)
1187302284 Q * bzed_ 
1187302291 M * AStorm berest, I'd try #nouveau
1187302296 M * AStorm then #kernel
1187302299 M * AStorm then ask me :>
1187302303 M * berest )))
1187302308 J * bzed_ ~bzed@dslb-084-059-049-094.pools.arcor-ip.net
1187302321 M * Bertl off for dinner now, should be back shortly ...
1187302322 M * berest empty
1187302329 N * Bertl Bertl_oO
1187302337 M * berest this channel is empty )
1187302340 M * AStorm berest, uhm, not on this server
1187302341 M * AStorm on Freenode
1187302377 J * Linus ~Linus@bl7-128-38.dsl.telepac.pt
1187302417 M * berest astrom - what are full address ?
1187302433 M * AStorm irc.freenode.net
1187302473 M * berest thx
1187302557 Q * bzed Ping timeout: 480 seconds
1187302717 P * berest Time makes no sense
1187303817 Q * bzed_ Quit: Leaving
1187305720 J * meandtheshel1 ~markus@85.127.116.57
1187305777 Q * meandtheshel1 
1187306319 J * FHTech ~Miranda@62.140.244.26
1187306721 N * Bertl_oO Bertl
1187307133 Q * FHTech Quit: FHTech
1187307581 M * baldy Bertl: who maintain the util-vserver deb?
1187307605 M * daniel_hozac micah
1187307619 M * baldy oke
1187307626 M * daniel_hozac i guess Ola may touch it every once in a while too.
1187307648 M * baldy i will ask him some thinks when he is online ,)
1187307693 M * daniel_hozac such as? bug reports are best handled in the BTS.
1187307709 M * baldy nope isnt a bug
1187307789 M * baldy can it be that the util .deb dont use /vserver for the guests?
1187307801 M * Bertl yep, definitely
1187307803 M * daniel_hozac yes, it uses /var/lib/vservers.
1187307820 M * Wonka i have a symlink...
1187307839 M * baldy is the needed to use /var/lib?
1187307857 M * Bertl yep, debian policy :)
1187307905 M * baldy because i will build a deb for openvcp and i will handle it with depends
1187307929 M * baldy nad openvcp use /vserver for the guests
1187307932 M * baldy and
1187307958 A * baldy dont wanne build a seperate util deb packet
1187307991 M * daniel_hozac surely you can configure OpenVCP to look elsewhere.
1187308004 M * baldy i know
1187308026 M * baldy but openvcp doku say /vserver hehe
1187308037 M * daniel_hozac as do all of our docs.
1187308038 M * daniel_hozac so?
1187308052 M * daniel_hozac Debian is weird, and the users will have to suffer for it.
1187308114 M * baldy oke i will use /var/lib/ ;)
1187308148 A * baldy have some precompiled vserver kernel
1187308161 M * baldy which can be installed with apt-get
1187308170 M * baldy on my privat reposity 
1187308182 M * daniel_hozac uh,  you know Debian has that, right?
1187308196 M * baldy yeah but old kernel or?
1187308253 M * baldy 2.6.18.5 is the lastest
1187308254 M * daniel_hozac linux-image-2.6.22-1-vserver-amd64_2.6.22-3_amd64.deb
1187308259 M * daniel_hozac doesn't look too old to me...
1187308317 M * baldy linux-image-2.6.18-5-vserver seems to be the lastes in the etch reposity
1187308363 M * daniel_hozac 2.6.21 is the latest for etch.
1187308382 M * baldy mhh
1187308385 M * baldy i cant find it
1187308395 M * daniel_hozac backports.org
1187308399 M * baldy ahh
1187308404 A * baldy dont use backports
1187308421 M * daniel_hozac so you're also using the old utils in etch?
1187308434 M * baldy self compiled utils
1187308439 M * baldy .213
1187308460 M * daniel_hozac that's available from bp.o too...
1187308483 M * baldy the normaly reposity is 212 the lates
1187308489 M * baldy latest
1187308513 M * daniel_hozac yes. thus, bp.o
1187308663 M * baldy oke let me check how can i handle it easily
1187308700 A * baldy wanne create a image which can be installed on thy fly
1187308744 M * baldy with all needed vserver features
1187308755 M * daniel_hozac huh?
1187308778 M * baldy ?