1185235239 Q * jescheng Remote host closed the connection
1185235249 Q * bzed Quit: Leaving
1185235250 J * jescheng ~jescheng@proxy-sjc-2.cisco.com
1185238177 J * DoberMann_ ~james@AToulouse-156-1-3-52.w81-250.abo.wanadoo.fr
1185238286 Q * DoberMann[ZZZzzz] Ping timeout: 480 seconds
1185242932 J * friendly12345 ~friendly@ppp59-167-144-7.lns4.mel6.internode.on.net
1185247384 N * Bertl_zZ Bertl
1185247391 M * Bertl morning folks!
1185247396 M * daniel_hozac morning Bertl!
1185247420 M * Bertl what did I mis the laste three days?
1185247437 M * daniel_hozac propagation is harder than it looks :)
1185247471 M * Bertl how so?
1185247471 M * daniel_hozac i can't recall there being anything else...
1185247497 M * daniel_hozac getting access to the mnt in permission would require lots of rewrites.
1185247513 M * daniel_hozac the nd that's passed in is optional, and a number of places omit it.
1185247552 M * Bertl hmm, but BME should have everything in place for that no?
1185247578 M * daniel_hozac actually, i thought about that.
1185247593 M * daniel_hozac i think it might be possible to circumvent BME.
1185247596 M * Bertl after all, that is what it does (except for non vfsmount aware FS like nfs and vfat)
1185247626 M * daniel_hozac file_permission e.g. doesn't pass in an nd.
1185247631 M * Bertl well, it wasn't updated for quite some while, so it might be completely broken by now
1185247680 M * Bertl we might also look at one of the IBM submissions of my code, it seems they are keeping it somewhat up-to-date
1185247704 M * daniel_hozac yeah, i was planning on doing that.
1185247809 M * daniel_hozac when i made dx_permission take the nd instead of the inode, while i got the functionality i wanted, i was getting lots of warnings about denied access (and with no nd, no path...)
1185247820 M * daniel_hozac (http://people.linux-vserver.org/~dhozac/p/k/delta-propagate-feat01.diff)
1185247891 M * daniel_hozac so there are definitely common cases where the nd isn't available.
1185247913 M * Bertl ah, yeah, well, that is not unexpected :)
1185247964 M * Bertl I think, you actually want to do it the other way round, except for the create case
1185247990 M * Bertl i.e. go from dentry to vfs mnt for xid checks
1185248013 M * Bertl that is, where the 'original' propagation idea comes in
1185248053 M * daniel_hozac i don't follow.
1185248053 M * Bertl i.e. mark inodesas 'anonymous' when no tagging there
1185248072 M * Bertl and once the dentry has a tagging, propagate that
1185248107 M * daniel_hozac hmm, you mean, set the inode's tag based on the mount's?
1185248119 M * Bertl the real problem, IMHO, you are facing is the fact that inodes can (and usually will) be shared between dentries
1185248172 M * daniel_hozac exactly.
1185248192 M * Bertl so, to make that work, we have two options
1185248193 M * daniel_hozac which is why i wanted to just override the check.
1185248214 M * Bertl 1) the actual 'propagation' idea
1185248226 M * Bertl 2) a dentry based tagging for access control
1185248236 M * daniel_hozac what is the actual 'propagation' idea?
1185248261 M * Bertl okay, let me explain that one
1185248275 M * daniel_hozac please :)
1185248295 M * Bertl it basically comes from the old ages, where I was working on the 'shared' filesystem approach
1185248335 M * Bertl the idea was to have some 'marking' which can be based on a directory tree (we didn't think of vfs mounts back then)
1185248353 M * Bertl and the basic concept is this:
1185248375 M * Bertl by default, all inodes belong to all contexts
1185248423 M * Bertl when a context opens (or creates) a dentry (during path walk) which is clearly belonging to that context (i.e. should be tagged)
1185248445 M * Bertl then the tag is assigned to the directory inode (and/or dentry)
1185248485 M * Bertl and when the same context tries to open a file inside that directory (which again happens during path walk) the tagging is 'propagated' down
1185248528 M * Bertl eventually the dentry tags are made persistant via the actual inodes, if they are untagged
1185248583 M * Bertl (that is/was the basic idea)
1185248607 M * daniel_hozac okay, makes sense.
1185248642 M * Bertl now, for example for the OLPC case, it would be more than sufficient, to have a 'notag' for vfsmounts, which disables the checks
1185248674 M * Bertl (given that the dentry is sufficient for checks, of cours)
1185248676 M * Bertl *course
1185248703 M * Bertl which, OTOH, would require to move the tagging from inodes to dentries, and check them there
1185248731 M * daniel_hozac right, so the tagging would check dentries, which would get their initial values from the inodes?
1185248745 M * Bertl depending on the vfs flags
1185248750 M * daniel_hozac right.
1185248756 M * Bertl i.e. vfs = notag -> 0
1185248763 M * Bertl vfs = tag=27 -> 27
1185248772 M * Bertl otherwise -> inode.tag
1185248772 M * daniel_hozac exactly.
1185248808 M * daniel_hozac is there an easy way to get the vfsmount from the dentry? otherwise we still have the same problem, the nd is a requirement :)
1185248811 M * Bertl inode creation would do it the other way, as it is now
1185248827 M * Bertl yes, the dentry has a strong relation to the vfs mount
1185248859 M * daniel_hozac yeah, i realize that (vfsmount, dentry) defines a path, i'm just not seeing a way to go from dentry to mount.
1185248903 M * daniel_hozac OTOH, either way it'll require a change to permission's argument(s).
1185248974 M * daniel_hozac so i guess it doesn't really matter for the workload.
1185249065 M * Bertl well, not necessarily, we are only interested in the access/creation cases, not that much in the operation cases (for the propagation)
1185249108 M * Bertl which boils down to the very same checks ro --bind mounts should cover
1185249136 M * Bertl with one exception: the propagate on create case
1185249139 M * daniel_hozac i'm not sure i see the difference between access/operation.
1185249181 M * Bertl access is the first contact with the dentry
1185249183 M * daniel_hozac or access meaning do_lookup, operation meaning MAY_WRITE?
1185249186 M * daniel_hozac right, okay.
1185249188 M * daniel_hozac got it.
1185249196 M * Bertl while operation is manipulation of the entries
1185249296 M * Bertl in a first shot, I would aim for a NOTAG flag which simply makes the checks ignore inode taggings, without actually affecting or changing the inode tagging mechanisms
1185249335 M * Bertl if course, that requires to remove the inode specific checks for taggings
1185249350 M * Bertl (and move them upwards to the dentry access functions)
1185249474 Q * boneb Ping timeout: 480 seconds
1185249610 M * daniel_hozac okay, thanks. i'll take another stab at it.
1185249628 M * Bertl np, thank you for looking into it! 
1185250966 J * boneb ~ben@mail.fourtwoseven.co.uk
1185250974 M * Bertl welcome boneb!
1185252866 Q * balbir Ping timeout: 480 seconds
1185254658 M * Bertl daniel_hozac: do you remember that site to check dns setups?
1185254770 J * DavidS ~david@85.125.165.34
1185255685 Q * DavidS Remote host closed the connection
1185256479 J * balbir ~balbir@59.145.136.1
1185256801 Q * jescheng Remote host closed the connection
1185256814 J * jescheng ~jescheng@proxy-sjc-2.cisco.com
1185258591 J * dna ~naucki@229-199-dsl.kielnet.net
1185258829 N * DoberMann_ DoberMann[PullA]
1185259379 J * C14r ~C14r@h58173.serverkompetenz.net
1185260093 M * matti Morning.
1185260744 M * Bertl good morning matti!
1185261821 J * Baby ~miry@195.37.62.208
1185263081 J * meandtheshell ~markus@85.127.104.34
1185264965 Q * balbir Ping timeout: 480 seconds
1185266433 J * bzed ~bzed@dslb-084-059-126-233.pools.arcor-ip.net
1185266864 J * pmenier ~pmenier@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr
1185267545 J * balbir ~balbir@59.145.136.1
1185267653 M * Bertl welcome Baby! C14r!
1185268321 M * Baby hi Bertl!
1185268474 M * pmenier hi Bertl
1185268578 M * pmenier the diff beetween vs2.2.0.2-rc1 and vs2.2.0.3-rc1 for 2.6.22.1 just concerns nsproxy,right ?
1185268616 M * Bertl actually it should contain a few more fixes, IIRC
1185268682 M * matti Hi Bertl 
1185268750 M * Baby bbl
1185268852 Q * meandtheshell Quit: Leaving.
1185268993 J * cedric ~cedric@80.70.39.67
1185269204 J * meandtheshel1 ~markus@85.127.110.196
1185270817 J * dreamind ~dreamind@p54A7B0D3.dip0.t-ipconnect.de
1185270847 N * dreamind Guest128
1185270864 Q * Johnnie Ping timeout: 480 seconds
1185270864 M * Guest128 hi
1185271166 M * Bertl welcome Guest128!
1185271216 M * Guest128 oh
1185271251 N * Guest128 dreamind
1185271264 M * dreamind thats better
1185271271 M * Bertl nap attack ... back later ...
1185271278 N * Bertl Bertl_zZ
1185271416 J * Johnnie ~jdlewis@c-67-163-142-234.hsd1.pa.comcast.net
1185272083 M * baldy mhh
1185272089 M * baldy what was the reason for:
1185272090 M * baldy vhost04:~# vserver h4vs02 start
1185272090 M * baldy vsysctl: open("."): Permission denied
1185272181 M * dragonheart no execute permissions on it
1185272236 M * baldy mhhhh
1185272238 M * baldy strange
1185272442 M * baldy das kann doch net sein
1185272482 M * baldy where are the permissions set?
1185272499 M * baldy it looks for me everythink oke
1185275046 M * AStorm baldy, chmod :-)
1185275276 J * Piet ~piet@tor.noreply.org
1185276550 Q * balbir Ping timeout: 480 seconds
1185277969 J * gerrit ~gerrit@yktgi01e0-s5.watson.ibm.com
1185278064 Q * Johnnie Ping timeout: 480 seconds
1185278613 J * Johnnie ~jdlewis@c-67-163-142-234.hsd1.ct.comcast.net
1185279171 Q * dreamind Quit: dreamind
1185279210 J * balbir ~balbir@59.145.136.1
1185279688 J * dna_ ~naucki@48-204-dsl.kielnet.net
1185279791 Q * balbir Ping timeout: 480 seconds
1185280096 Q * dna Ping timeout: 480 seconds
1185280155 J * ema ~ema@rtfm.galliera.it
1185280467 J * EtherNet ~EtherNet@OL240-101.fibertel.com.ar
1185281998 M * eyck- what does it mean when vserver-stast shows VSS as '15.9+' ?
1185282136 M * daniel_hozac that it overflowed :)
1185282275 M * eyck- good, good
1185282710 Q * Aiken Remote host closed the connection
1185282758 J * fishingshrimp ~staenzer@static-87-79-237-223.netcologne.de
1185282768 M * fishingshrimp hello
1185282776 M * daniel_hozac hi
1185282829 M * fishingshrimp "Kernel panic - not syncing: Aiee, killing interrupt handler!" - this just happened twice after moving a lot of data inside a courier imap inside a vserver... any ideas?
1185283099 J * balbir ~balbir@122.167.3.244
1185283268 M * daniel_hozac we'd need the actual panic in order to make any sort of guess ;)
1185283283 M * daniel_hozac (i.e. the 40 or so lines before that)
1185283410 M * fishingshrimp i could upload the screenshot
1185283425 M * fishingshrimp the server is not locally here...
1185283438 M * fishingshrimp but I have access through an eric remote console
1185283451 M * fishingshrimp wait..
1185283560 M * fishingshrimp http://img239.imageshack.us/my.php?image=screenshotxt8.jpg
1185283571 M * fishingshrimp that's all I have
1185283616 M * daniel_hozac no function names? do you still have the kernel tree around?
1185283662 M * fishingshrimp no function names, no :( I already mailed technical support at the datacenter for more details..
1185283702 M * fishingshrimp what exactly do you mean by "kernel tree"? the config file of the compiled kernel?
1185283741 M * daniel_hozac no, the source tree.
1185283848 M * fishingshrimp oh ok, sure it's still there
1185283868 M * daniel_hozac do you have CONFIG_DEBUG_INFO enabled?
1185283889 M * fishingshrimp no
1185283904 M * fishingshrimp at least it doesn't show up with grep in .config
1185284010 M * daniel_hozac okay, how about ksymooops? is that able to tell you anything?
1185284038 M * fishingshrimp empty..
1185284083 M * fishingshrimp ah wait..
1185284167 M * fishingshrimp how to use ksymoops? never had to use it before, sorry
1185284406 M * fishingshrimp support just mailed back - should be a "software" problem, not hardware... they assume it's related to my vserver kernel and/or bios settings
1185284420 M * daniel_hozac i really don't remember. i haven't used ksymoops for years.
1185284444 M * fishingshrimp hmm ksymoops tells me there's no such file... ksymoops dir is emtpy..
1185284451 M * fishingshrimp l
1185284491 M * daniel_hozac i guess you could just do it manually. look for the address closest to RIP in System.map.
1185284503 M * daniel_hozac you want the one that is less than RIP.
1185284523 M * fishingshrimp already there, yep...
1185284680 M * fishingshrimp ffffffff8029b830 t end_bio_bh_io_sync and ffffffff8029b870 T submit_bh ... but this doesn't tell me a thing..
1185284786 M * daniel_hozac addr2line -e vmlinux ffffffff8029b85f returns ??:0, right?
1185284824 M * fishingshrimp mom... have been running a e2fsck
1185284883 M * fishingshrimp buffer.c:0
1185284908 M * daniel_hozac hmm, interesting.
1185284915 M * fishingshrimp just an idea - could this be related to my dlimit settings?
1185284934 M * fishingshrimp before I've been playing around with the inode and total_space setting of that server
1185284951 M * fishingshrimp and I have to admit I do not fully understand the relation inodes vs. total space
1185284961 M * daniel_hozac it's possible i guess. we fixed a couple of bugs, but none that would cause crashes in the buffer code.
1185284971 M * daniel_hozac what kernel is this btw?
1185284986 M * fishingshrimp 2.6.19.7-grsec2.1.10-vs2.2.0 #1 Fri Apr 6 01:58:03 CEST 2007 x86_64 GNU/Linux
1185285046 M * fishingshrimp dev/sda4            35160064  311874 34848190    1% /data
1185285061 M * fishingshrimp inodes for that vserver: 8790016
1185285072 M * fishingshrimp space total: 50242880
1185285081 M * fishingshrimp reserved: 5
1185285126 M * fishingshrimp i googled for hours but didn't find any detailed "how-to" about these settings only general stuff but nothing that explains "if you need 50gb give the vserver xxxx inodes..."
1185285195 M * daniel_hozac because there is no direct space<->inodes relationship.
1185285387 M * fishingshrimp I'm running the server in the rescue mode now... and mounting sda2 (root) tells me: ext3-fs warning: maximal mount count reached, running e2fsck is recommended
1185285434 M * fishingshrimp strange.. shouldn't it run e2fsck automatically at startup...
1185285484 M * daniel_hozac maybe not in rescue mode.
1185285513 M * fishingshrimp it didn't at normal boot either.. syslog shows me the same message
1185285575 M * daniel_hozac then your initscripts are bad :)
1185285694 M * fishingshrimp i'm going to try again starting the vserver and moving the data.. but how can I log the kernel panic?
1185285706 M * daniel_hozac serial console.
1185285716 M * daniel_hozac (netconsole if you're lucky)
1185285912 M * fishingshrimp hmm nothing happens when deleting 500 mails from the imap folder..
1185286010 M * fishingshrimp now let's see what happens when moving 10.000 mails to trahs..
1185286198 P * friendly12345 
1185286876 J * chand ~chand@212.99.51.254
1185286921 J * ensc|w ~ensc@www.sigma-chemnitz.de
1185286936 M * ensc|w hi; what is with the maillist server?
1185287005 M * daniel_hozac the web interface?
1185287011 M * daniel_hozac or in general?
1185287028 M * daniel_hozac the first has been broken for a really long time.
1185287036 N * Bertl_zZ Bertl
1185287045 M * daniel_hozac morning Bertl!
1185287047 M * Bertl hey ensc|w! LTNS!
1185287094 M * ensc|w latest mail seems to be from july 18; but I wrote one 30 minutes ago which did not showed up
1185287128 M * daniel_hozac hmm, maybe it's really down now.
1185287145 M * daniel_hozac it can take some time though.
1185287160 M * ensc|w ok; then I ask here: is it on purpose that CLONE_NEWNS does not work in contexts anymore?
1185287182 M * Bertl hmm, kernel version?
1185287200 M * daniel_hozac i think it is.
1185287201 M * ensc|w with 2.6.21.5 it worked; there was a hunk in copy_mnt_ns() which checked for VCX_SECURE_MOUNT. This does not exist anymore with recent patch
1185287214 M * daniel_hozac it requires in CAP_SYS_ADMIN.
1185287227 M * Bertl yep, mainline change
1185287242 M * ensc|w bad...
1185287263 M * ensc|w I do not want to give full CAP_SYS_ADMIN just to create a new namespace
1185287289 M * Bertl well, I think we can add a context capability for that
1185287460 M * ensc|w it would be nice too, when http://pastebin.com/m33e0af5b would be added
1185287481 M * ensc|w this allows to bind-mount a /dev filesystem without setting 'nodev' flags
1185287609 M * Bertl hmm, did you test what effects that might have on bind mounts in general?
1185287641 M * Bertl i.e. what about other filesystems, which are currently mounted ro (for this specific guest)?
1185287652 M * ensc|w it should affect only stuff like 'mount --bind /dev /mnt'
1185287678 M * Bertl how so? what about RO bind mounts?
1185287682 M * ensc|w current (unpatched) code sets -o nodev, patch prevents this implicit flagging
1185287708 M * ensc|w it affects the MNT_NODEV flag only
1185287747 M * Bertl what if I do, mount --bind /tmp /my_dev ?
1185287778 M * Bertl do I still have a nodev on /my_dev ?
1185287795 M * ensc|w with unpatched kernel; you will not have usable devices in /my_dev (nodev is set)
1185287810 M * ensc|w with patch; my_dev will have nodev only, when /tmp has it
1185287885 M * Bertl okay, will look into it .. if it seems safe, we can add that, I think debian folks wanted something like that too
1185287923 M * daniel_hozac i don't think it's safe.
1185287952 M * daniel_hozac if /tmp is nodev, mount --bind /tmp /my_dev should make /my_dev dev, no?
1185287958 M * daniel_hozac (due to BME)
1185287989 M * Bertl yes, I think so
1185288093 M * ensc|w mount --bind does not copy flags like MS_NOEXEC, MS_RDONLY?
1185288098 M * fishingshrimp dang there it is..
1185288102 M * fishingshrimp famd
1185288109 M * fishingshrimp segfault at 0000...something..
1185288128 M * daniel_hozac ensc|w: if it does, i don't see it.
1185288169 M * fishingshrimp FAM seems the be the culprit..
1185288184 M * Bertl daniel_hozac: one option would be to switch to an explicit bind mount system call, for adding and _removing_ mount flags
1185288223 M * Bertl but I guess that is something we leave up to mainline
1185288299 M * matti Bertl: :)
1185288352 M * Roey Hey Bertl!
1185288435 M * Bertl hey Roey!
1185288560 M * Roey So what brings you to #linuxchics, anyway?
1185288619 M * Bertl hmm, usually my irc client :)
1185288718 M * Roey :)
1185288739 M * Roey I mean what motivated you to go there in the first place (besides girls who are into gnu/linux)
1185288789 Q * sid3windr Remote host closed the connection
1185288792 J * sid3windr luser@bastard-operator.from-hell.be
1185288816 Q * Radiance Ping timeout: 480 seconds
1185288846 Q * LaZaR 
1185288957 M * Bertl Roey: TrAns13nT's bash script brought me there IIRC ...
1185289091 M * Roey aahhh cool :)
1185289269 M * ensc|w Bertl: there seems to be a security issue with the BME patch... http://pastebin.com/m5d64cf7a   when bind-mounting directories (e.g. into NFS4 roots), nosuid and noexec attributes are silently dropped
1185289347 M * Bertl yep, NFS is not BME safe
1185289372 M * Bertl mainly because all the checks happen on the server side
1185289417 M * ensc|w Bertl: no; NFS4 requires (on server-side) that exported directories are below a certain directory. Usually, they are mounted to this place like 'mount --bind /home /var/lib/nfs4/root/home'
1185289417 M * daniel_hozac won't that happen anyway though?
1185289451 M * ensc|w without BME, /var/lib/nfs4/root/home will keep nosuid, with BME, suid is allowed at /var/lib/nfs4/root/home
1185289477 M * ensc|w --> your NFS4 server is insecure with the BME patch
1185289502 M * Bertl ah, BME on the server?
1185289519 M * ensc|w vserver on the server ;)
1185289529 M * Bertl if so, that is the sole purpose of BME (with the current mount interface)
1185289553 M * Bertl otherwise you would not have a chance to change any of the flags :)
1185289603 M * ensc|w what's when changing BME that flags can be only set, but not removed?
1185289634 M * Bertl then you cannot do inversions
1185289666 M * ensc|w inversions?
1185289675 M * daniel_hozac are there cases where you'd want to remove flags though?
1185289702 M * Bertl yes, e.g. EO bind mount /
1185289703 M * ensc|w currently, I have only cases where I want to set flags
1185289720 M * Bertl *RO, then make certain exceptions
1185289778 M * daniel_hozac actually, if you give a guest VXC_SECURE_MOUNT and it's on a RO /... it would be able to mount --bind that rw, right?
1185289832 M * ensc|w [root@koji-builder0 /]# touch /x
1185289832 M * ensc|w touch: cannot touch `/x': Read-only file system
1185289840 M * ensc|w [root@koji-builder0 /]# mount -n  --bind / /mnt
1185289840 M * ensc|w [root@koji-builder0 /]# touch /mnt/x
1185289840 M * ensc|w [root@koji-builder0 /]# 
1185289848 M * ensc|w yep; that's a secleak
1185289864 M * Bertl if you give that capability, yes
1185289947 M * Bertl but BME is kind of pointless as protection feature if you allow mounts inside
1185289963 M * Bertl (at least the current inkarnation :)
1185289963 M * ensc|w mmmh.... effect seems to violate the _SECURE_ string in VCX_SECURE_MOUNT...
1185289999 M * Bertl the SECURE only concerns NODEV
1185290017 M * Bertl (which is exactly what you want to disable, btw :)
1185290077 M * Bertl but I'm open for suggestions there .. as long as we do sufficient testing
1185290081 M * ensc|w I would interpret VXC_SECURE_MOUNT as: do not give more rights than there were before
1185290098 M * daniel_hozac i think we should define just exactly what each of the mount options mean.
1185290143 M * Bertl maybe even add another flag or a mount flag mask?
1185290143 M * daniel_hozac i have to agree with that, secure_mount sounds like a safe capability.
1185290312 M * Bertl the main problem is that sys_mount() was never designed for move or bind mounts
1185290371 M * Bertl so, if we disable BME completely, you end up with expected behaviour (according to mainline :)
1185290380 Q * balbir Ping timeout: 480 seconds
1185290382 M * daniel_hozac sure.
1185290422 M * Bertl we could now have a new capability for 'removing flags' on bind mounts
1185290435 M * Bertl or just disable this for guest contexts completely
1185290459 M * Bertl nobody says that a guest should have BME capabilities at all
1185290468 M * ensc|w afais, main-point in BME is: +       mnt->mnt_flags = mnt_flags;
1185290494 M * ensc|w I would make '|=' instead of '=' there...
1185290507 M * Bertl but only for guests
1185290603 M * ensc|w I still do not understand the problem with inversions resp. why they are needed
1185290656 Q * fishingshrimp Quit:  HydraIRC -> http://www.hydrairc.com <- Go on, try it!
1185290849 M * Bertl hmm ... it shouldn't be a problem to 'reverse' the bind mount layer with another direct bind mount
1185290890 M * Bertl so yes, I think we could drop the 'remove flags' feature 
1185290981 M * Bertl although it would complicate a host only setup ...
1185291038 M * Bertl i.e. mount -o bind,ro / / might cause you some trouble :)
1185291101 M * daniel_hozac wouldn't umount fix that? :)
1185291128 M * Bertl except for EBUSY, yes :)
1185291164 M * Bertl but remount could help
1185291178 M * Bertl (if implemented correctly for bind mounts)
1185291215 J * balbir ~balbir@122.167.9.203
1185291311 M * Bertl btw, yes, it seems like the ML is finally down
1185291333 M * sid3windr :/
1185291335 M * sid3windr "finally"
1185291339 M * Bertl so I guess we have to bite the bullet and setup a new one
1185291366 M * matti ;/
1185291369 M * Bertl I will gather a list of folks who posted to the ML and send them a notification
1185291441 M * Bertl Hollow: do you think you can setup mailman on helios?
1185291527 M * Hollow Bertl: sure, will look at it in the evening
1185291546 J * stefani ~stefani@flute.radonc.washington.edu
1185292947 N * ensc Guest171
1185292957 J * ensc ~irc-ensc@p54B4CCF5.dip.t-dialin.net
1185293054 Q * Guest171 Ping timeout: 480 seconds
1185293498 M * baldy wenn ihr ne ML brauchs oder so kann ich euch sowas gerne einrichten auf nem vserver hihi
1185293608 M * Wonka *yawn*
1185293838 M * Bertl baldy: tx, we might get back to that at some point
1185294983 M * Bertl okay, off for now ... back later ...
1185294989 N * Bertl Bertl_oO
1185295391 Q * slack101 Ping timeout: 480 seconds
1185295481 Q * pmenier Quit: pmenier
1185297317 Q * cedric Quit: cedric
1185297613 Q * ema Quit: leaving
1185298510 N * DoberMann[PullA] DoberMann
1185299716 Q * matti Ping timeout: 480 seconds
1185299718 M * AStorm daniel_hozac, uhm, next time when you see a guy with a filesystem saying something about "maximum count reached" after a full crash
1185299725 M * AStorm do not tell him to run fsck
1185299741 M * AStorm it's probably a HDD failure in this case (unless his init scripts are totally broken)
1185299918 J * matti matti@acrux.romke.net
1185300002 Q * jescheng Remote host closed the connection
1185300013 J * jescheng ~jescheng@proxy-sjc-2.cisco.com
1185300832 M * daniel_hozac AStorm: or something simply scribbled over those bytes. again, not psychic.
1185300909 M * baldy vsched: non-numeric value specified for '--priority_bias' any idea?
1185300964 M * daniel_hozac baldy: replace dummy with a valid value in /etc/vservers/<guest>/schedule
1185300972 M * daniel_hozac and/or upgrade to the new configuration format.
1185301012 M * baldy ahh oke now it works
1185301025 M * baldy daniel_hozac: yeah i use the new format on my new server hehe
1185301037 M * daniel_hozac /etc/vservers/<guest>/schedule is not the new format.
1185301055 M * baldy nonon this was a old server
1185301197 Q * AStorm Remote host closed the connection
1185301205 M * baldy i still so some tests with opvenvcp and ipv6 stuff
1185301270 Q * chand Ping timeout: 480 seconds
1185303786 Q * FireEgl Quit: Bye...
1185304797 J * FireEgl ~FireEgl@Atlantica.Inet6.Info
1185304864 J * ktwilight ~ktwilight@20.199-66-87.adsl-static.isp.belgacom.be
1185304864 Q * ktwilight_ Read error: Connection reset by peer
1185305855 Q * dragonheart Ping timeout: 480 seconds
1185306513 J * dragonheart ~dragonhea@ppp59-167-41-164.lns2.cbr1.internode.on.net
1185308550 J * emtty ~eric@dynamic-acs-24-154-34-240.zoominternet.net
1185308746 Q * cehteh Ping timeout: 480 seconds
1185308758 Q * Piet Remote host closed the connection
1185308793 J * Piet ~piet@tor.noreply.org
1185309438 J * cehteh ~ct@pipapo.org
1185310030 N * Roey WorkRoey
1185310904 P * stefani I'm Parting (the water)
1185310982 J * Aiken ~james@ppp121-45-220-241.lns2.bne1.internode.on.net
1185312362 Q * dna_ Quit: Verlassend
1185312370 Q * gerrit Ping timeout: 480 seconds
1185312932 J * bonbons ~bonbons@2001:5c0:85e2:0:20b:5dff:fec7:6b33
1185313004 Q * ard Read error: Connection reset by peer
1185313281 J * marcfiu ~marcfiu@c-68-39-177-97.hsd1.nj.comcast.net
1185314798 Q * bonbons Quit: Leaving
1185314883 Q * marcfiu Quit: The computer fell asleep
1185315218 J * AStorm ~astralsto@host-81-190-179-124.gorzow.mm.pl
1185315307 Q * fs Ping timeout: 480 seconds
1185316871 N * DoberMann DoberMann[ZZZzzz]
1185316887 J * menomc ~amery@kilo105.server4you.de
1185316900 Q * AStorm Quit: Bye, and thanks for all the fish
1185316993 Q * mnemoc Ping timeout: 480 seconds
1185316993 N * menomc mnemoc
1185317229 Q * FireEgl Quit: Bye...
1185317279 J * AStorm ~astralsto@host-81-190-179-124.gorzow.mm.pl
1185318474 Q * AStorm Remote host closed the connection
1185318931 J * FireEgl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa
1185319706 J * AStorm ~astralsto@host-81-190-179-124.gorzow.mm.pl
1185319757 J * ard ~ard@gw-cistron.kwaak.net
1185320915 M * Bertl_oO okay, off to bed for today ... have a good one everyone!
1185320921 N * Bertl_oO Bertl_zZ