1105402001 M * Pazzo Seraph: I uploaded conflicts: http://vserver.gelf.net/debmerge_gelf_verfaction.diff
1105402019 M * Pazzo I tried to remove all useless things manually
1105402046 M * Pazzo (for example all the new variables $_RM & co missing in my package)
1105402075 M * Seraph apart from the german comments it's fine..
1105402084 M * Pazzo pay attention at /usr/lib/util-vserver/vserver-build.debootstrap, starting from line 95
1105402090 M * Pazzo ehm 96
1105402117 M * Pazzo I didn't know how to remove this $_RM stuff and the comments without destroying the line numbers :-)
1105402151 M * Seraph what's the use of getting rid of the macros?
1105402166 M * Pazzo getting rid of the macros?
1105402193 M * Pazzo which macros?
1105402256 Q * mikelcu Quit: Client exiting
1105402320 M * Seraph $_RM
1105402322 M * Seraph and $_MV
1105402343 M * Seraph btw. flavour is missing for bootstrapping
1105402344 M * Pazzo that's what I tried to explain:
1105402347 M * Seraph and it should use cdebootstrap
1105402402 M * Seraph but that's more than a oneliner
1105402404 M * Seraph *g*
1105402412 M * Seraph yet long term that should be switched
1105402420 M * Seraph in case you wanna try, feel free to do that..
1105402432 M * Pazzo $_RM & co are missing in the official 0.30.196 source - I cleaned up the diff manually but on line 96 I didn't know how to change the diff without causing wrong line numbers...
1105402439 M * Seraph and add support for normal flavour and build (in cdebootstrap talk)
1105402472 M * Seraph you can always delete whole blocks from "^--- ..." until the next "^---"
1105402478 M * Seraph where ^ is the beginning of a line
1105402538 M * Pazzo ??? doesn't --- start a new file? I cleaned blocks from ^@@ to ^@@
1105402549 M * Seraph nope
1105402559 M * Seraph --- does only start a new file if it's from 0,0 to 0,0 
1105402566 M * Seraph and +++ is non-zero
1105402577 M * Seraph ok, what's your name and email to add to the dpatch header?
1105402598 M * Pazzo Thomas Gelf - thomas@gelf.net
1105402671 M * Seraph oh
1105402675 M * Seraph now i see what you mean *g*
1105402680 M * Seraph yes, that's a bit more tricky
1105402733 M * Pazzo the problem is that I modified an older version than yours...
1105402754 M * Seraph *g*
1105402755 M * Seraph np
1105402764 M * Pazzo and I need only the second part of /usr/lib/util-vserver/vserver-build.debootstrap, @@ -96,15 +96,15 @@
1105402765 M * Seraph you get used to writing diffs =)
1105402775 M * Seraph @@ -103,8 +103,8 @@
1105402776 M * Seraph  ###   main starts here <---
1105402777 M * Pazzo for sure :o)
1105402779 M * Seraph should do the trick
1105402823 M * Pazzo 103 or 104?
1105402879 J * ntrs ntrs@Dardeene-68.188.50.87.charter-stl.com
1105402885 M * Seraph 96+7=103
1105402892 M * Seraph and i erased 7 lines
1105402899 M * Seraph but we'll just see =)
1105402926 M * Pazzo ok, but then there is a newline in front of ### main... - right?
1105402945 M * Seraph yep
1105402949 M * Seraph 3 lines above the fix line
1105402956 M * Seraph as unified diff looks like
1105402971 M * Pazzo try to reload http://vserver.gelf.net/debmerge_gelf_verfaction.diff
1105402986 M * Pazzo I got it :)
1105402992 M * Seraph hehe, that's about as my patch looks like now =)
1105403005 M * Seraph alright, let's have it reloaded then
1105403050 M * Seraph *dumdidum*
1105403075 Q * ntrs_ Ping timeout: 480 seconds
1105403121 M * Pazzo Seraph: what did you mean by "(01:12:24) Seraph: btw. flavour is missing for bootstrapping"?
1105403124 M * Seraph *argh*
1105403140 M * Seraph you can bootstrap a "regular" chroot or a "buildd" chroot
1105403144 M * Seraph and that's called flavour
1105403155 M * Seraph buildd is sort of a *very* minimized bootstrap
1105403164 M * Seraph but including build-essential
1105403178 M * Seraph i'm not sure there's a flavour "core" or so
1105403180 M * Seraph but it might be too
1105403194 M * Seraph for you don't seriously need stuff like ppp and pppoe in the vserver, eh?
1105403198 M * Pazzo aaah, ok. I've seen buildd in the scripts but didn't know how (and for what) to use it
1105403240 M * Pazzo we started to create our personal debootstrap scripts
1105403261 M * Pazzo for example "really base debian vps"
1105403274 M * Pazzo or "fully-equipped-hosting-vps"
1105403277 M * Pazzo and so on :)
1105403290 M * Pazzo and that's why we added the -s switch
1105403323 Q * xTomx Quit: xTomx
1105403369 M * Seraph try cdebootstrap
1105403379 M * Seraph i'm sure you'll like it =)
1105403440 M * Pazzo Seraph: wouldn't this be an'idea for the official util-vserver packages? -m debootstrap -- -d sarge -s basevserver ?
1105403459 M * Seraph hmm
1105403468 M * Pazzo hey, I discovered something else:
1105403469 M * Seraph i'd very much love to switch to cdebootstrap
1105403474 M * Pazzo vserver - build --help
1105403477 M * Seraph like cdebootstrap -f base
1105403481 M * Pazzo debootstrap ... -- -d <distribution> [-m <mirror> [-s <script>] ] [-- <debootstrap-options>*]
1105403495 M * Seraph you just telling me your fix ain't needed? ;)
1105403506 M * Pazzo I didn't realize that there was this [-- <debootstrap-options>*]
1105403564 M * Seraph actually "-f standard" is most probably what most people expect from cdebootstrap =)
1105403567 M * Pazzo this was:
1105403569 M * Pazzo debootstrap ... -- -d <distribution> [-m <mirror>] [-- <debootstrap-options>*]
1105403609 M * Pazzo do you think  ... build -- -d sarge -- -s myscript would have done the job?
1105403617 M * Seraph very likely
1105403628 M * Seraph but for now the -s shouldn't hurt
1105403636 M * Pazzo "debootstrap -h" says:
1105403644 M * Pazzo usage: [OPTION]... <suite> <target> [<mirror> [<script>]]
1105403669 M * Pazzo and that's what we wanted to realize:
1105403678 M * Pazzo -d <distribution> [-m <mirror> [-s <script>] ]
1105403729 M * Pazzo I think it looks better like this, and <debootstrap-options>* remains for all the things mentioned in "man debootstrap" but not in "debootstrap -h"
1105403761 M * Pazzo tell me that I'm right - I don't want to hear that my patch is nearly useless ;-)
1105403822 M * Seraph well... it'll at least keep more people finding it
1105403834 M * Seraph yet it'll vaninsh over the versions when switching to cdebootstrap anyway
1105403840 M * Seraph for there'll be a new syntax
1105403841 M * Seraph =)
1105403880 M * Pazzo what are the benefits of cdebootstrap over debootstrap?
1105403920 M * Seraph cdebootstrap is coded in C and about powers of ten faster
1105403935 M * Seraph plus it's the new and maintained replacement
1105403951 M * Seraph whereas debootstrap is rather "only updated where needed" afaik
1105403985 M * Pazzo there is no cdebootstrap in woody - but who cares? (I don't :-)
1105403994 M * Seraph there's a cdebootstrap in sarge and sid
1105404004 M * Seraph and we won't get to woody with util-vserver alpha anyway
1105404012 M * Seraph woody is only updated on security-critical things
1105404021 M * Seraph and this is not seriously one, eh? ;)
1105404130 M * Pazzo I'm using only sarge since nearly a year - and I was really happy with it. but now as it is going to be stable the number of packages I'm forced to use from sid increases :(
1105404138 M * Seraph alright.. check the updated archive
1105404157 M * Seraph well, there will be an etch soon =)
1105404200 M * Seraph could you try that deb and make sure it WorksForYou(TM)?
1105404384 M * Seraph btw. now you can also check that debian/patches/vserver_stop.dpatch is right =)
1105404391 M * Seraph i had to poke the paths around a bit
1105404516 M * Pazzo shit
1105404520 M * Seraph mmh?
1105404521 M * Pazzo there is an error
1105404541 M * Seraph where?
1105404545 M * Pazzo -        dir=$($_MKTEMPDIR /var/tmp/debootstrap.XXXXXX) +        dir=$(mktemp -d /var/tmp/debootstrap.XXXXXX)
1105404555 M * Seraph no -d
1105404562 M * Seraph right?
1105404586 M * Pazzo no, $_MKTEMPDIR instead of mktemp
1105404594 M * Pazzo -        dir=$($_MKTEMPDIR /var/tmp/debootstrap.XXXXXX)
1105404598 M * Pazzo +        dir=$(mktemp -d /var/tmp/debootstrap.XXXXXX)
1105404602 M * Pazzo this block is wrong
1105404612 M * Pazzo I've overseen this, sorry
1105404618 M * Seraph ok, deleted
1105404644 M * Pazzo the rest is ok
1105404655 M * Seraph *g*
1105404659 M * Seraph let's do new ones =)
1105404678 A * Seraph wishes for a larger upload bw..
1105404696 M * Pazzo I think you can leave away the comments around the debootstrap stuff
1105404712 M * Pazzo but maybe the remount line needs a little comment?!
1105404712 M * Seraph nah, that's ok
1105404721 M * Seraph feel free to propose one
1105404745 M * Pazzo (upload bw -> did you forget to write a letter to Santa Claus?)
1105404767 M * Seraph well, this box is going to the hosting center in like 2 weeks
1105404779 M * Seraph and then the "upload" will be local to the webserver *g*
1105404785 M * Seraph yet for the time being it's a bit annoying
1105404843 M * Pazzo # remount hack to force vservers to stop cleanly
1105404850 M * Pazzo # unless fixed otherwise
1105404854 M * Pazzo something like this?
1105404863 M * Pazzo my english is not that good :(
1105404879 M * Pazzo s/to//
1105404879 M * Pazzo ?
1105404924 M * Seraph you'll love my comment.. hold on a sec..
1105404930 M * Seraph *g*
1105405039 M * Seraph alright new diff is up =)
1105405114 M * Pazzo great :-)
1105405125 A * Seraph likes the easy solutions
1105405192 M * Seraph alright binary debs updated
1105405204 M * Seraph let me know if there's something else that needs fixing plz =)
1105405211 M * Pazzo for sure
1105405225 M * Pazzo and thnx for the diff lesson :)
1105405229 M * Seraph hehe, np
1105405255 M * Seraph for a "diff -urN" there's missing the actual diff command above ---, but that's ok
1105405306 M * Pazzo what about kernel packages? the last vserver patch I applied to a debian kernel was 2.6.8.1-vs1.9.8.2 - since then I stopped following the debian way and I'm really happy with vanilla kernels :)
1105405313 M * Seraph how come you moved down to italy btw.?
1105405330 M * Seraph hehe, debian kernels is another topic..
1105405346 M * Seraph and well.. kernel-package is just a third one even
1105405363 M * Pazzo I'm living in Suedtirol in the north of Italy - most of the people here are speaking german as we have been part of Austria long time ago...
1105405508 M * Pazzo mantaining a vserver-patched debian kernel would be a hard work...
1105405518 M * Seraph in case you'll one day find a dmk in Debian main.. i might even be on the uploaders =)
1105405522 M * Pazzo ...and probably a useless work
1105405529 M * Seraph hmm, useless i doubt
1105405537 M * Seraph but it'd be $MUCH_WORK for sure
1105405590 M * Pazzo bertl follows vanilla kernels and sarge will probably keep it's 2.6.8-1234556... kernel
1105405638 M * Seraph that doesn't need to mean it's a 2.6.8.1 though =)
1105405646 M * Pazzo maybe we can find some masochist modifying each vserver patch to fit the official debian kernel?
1105405659 M * Seraph naming it 2.6.8.1-whateverpluspluspatched could also make it a 2.6.11 if needed for security
1105405665 M * Pazzo sure, but it will be a very debianish thing
1105405669 M * Seraph it was just "derived from 2.6.8"
1105405681 M * Seraph yet packaging now for sarge would be kinda overkill
1105405694 M * Seraph putting it into scud would actually sound feasible
1105405708 M * Seraph nobody expects experimental to work *g*
1105405723 M * Seraph well, bertl wanted to check the debian-kernel IIRC
1105405738 M * Seraph and then try to get vserver at least apply to there
1105405764 M * Seraph but i know that debian kernel managers have very very few interest in linux-vserver
1105405773 M * Seraph they reckon it's nothing but a big ugly hack..
1105405793 M * Seraph (and put vserver down just as UML)..
1105405811 M * Seraph therefore neither of Vserver nor UML will be shipping in the default debian kernel for a long time still
1105405824 M * Seraph maybe if vserver will become LSM-based or so, they'll change their mind
1105405837 M * Seraph i haven't gone very deep into discussing with them
1105405854 M * Pazzo I was using UML for a while, it's great for playing nice routing scenarios :o) I've also been using it on productional webservers *brrrr* I'll never switch back :)
1105405927 M * Seraph but they very apparently don't "Honour The Bug" like http://www.southeren.com/blog/archives/000093.html
1105405961 M * Pazzo btw: vserver IS a big ugly hack - sudo crashed because I've had an ipv6 address configured on an unused interface, I need to remount proc to cleanly stop a vserver... ;-)
1105405990 M * Seraph Pazzo: you have tried XEN?
1105406031 M * Doener Pazzo: hey, that ipv6 bug has been fixed :P
1105406062 M * Pazzo I know :)
1105406069 M * Pazzo what's XEN?
1105406076 A * Seraph still wonders what an "unusual interface" is for ipv6
1105406092 M * Seraph Pazzo: apparently a UML lookalike with Vserver-like performance
1105406101 M * Seraph at least from their graphs
1105406117 M * Pazzo Serpah: cpu and ram performance: yes
1105406126 M * Doener "unusual interface"? where did you get that one from?
1105406141 M * Seraph 02:12 < Pazzo> btw: vserver IS a big ugly hack - sudo crashed because I've had an ipv6 address 
1105406144 M * Seraph                configured on an unused interface, I need to remount proc to cleanly stop a 
1105406147 M * Seraph                vserver... ;-)
1105406150 M * Seraph argl
1105406153 M * Seraph unused..
1105406155 M * Pazzo unused != unusual
1105406158 M * Seraph yes yes..
1105406162 M * Doener ah... *g*
1105406164 A * Seraph should crouch
1105406201 M * Seraph Pazzo: alright.. bonna notte.. keep me posted.. ciao =)
1105406205 M * Seraph n8 Doener 
1105406212 M * Pazzo Serpah: when I have been using uml I didn't know anything about lvm and I didn't wan't to change my partition table to resize a vps
1105406226 M * Doener good night Seraph!
1105406227 M * Pazzo so the only solution have been loopback mounted sparse files
1105406242 M * Pazzo they are great - anless they are growng :)
1105406247 M * Pazzo good night seraph!
1105406256 M * Pazzo btw: hi doener!
1105406285 M * Pazzo and good night doener, I need 3 or 4 hours of sleep too...
1105406289 M * Pazzo cya!
1105406298 M * Doener night!
1105406328 Q * Pazzo Quit: chrrrr....
1105409156 N * Doener Doener_zZz
1105410526 Q * chrish01 Quit: Leaving
1105415409 J * tad ~tad@h00e0816059e1.ne.client2.attbi.com
1105415817 Q * tad Read error: Operation timed out
1105417437 Q * we2by Ping timeout: 480 seconds
1105417456 J * we2by ~we2by@dc5146d009.adsl.wanadoo.nl
1105420398 Q * meebey Read error: Connection reset by peer
1105420650 J * meebey meebey@meebey.net
1105424683 J * chrish01 ~chrish01@69.90.131.10
1105425342 J * grecea ~grecea@h-195-22-237-74.mdl.net
1105428488 M * are|afk disc
1105428491 Q * are|afk Quit: Disconnecting
1105428553 Q * we2by Read error: Connection reset by peer
1105428553 J * we2by ~we2by@dc5146d009.adsl.wanadoo.nl
1105431361 J * Mega\work ~Megabart2@host111-101.pool80182.interbusiness.it
1105431367 M * Mega\work hi
1105431895 Q * BWare Ping timeout: 480 seconds
1105433183 J * BWare ~bware@212.26.196.158
1105435388 J * jsambrook ~jsambrook@aelfric.plus.com
1105435758 Q * jsambrook Remote host closed the connection
1105436523 Q * no_maam Remote host closed the connection
1105436525 J * no_maam ~erik@datenzone.de
1105436846 J * rs rs@ice.aspic.com
1105436997 N * Bertl_zZ Bertl
1105437003 M * rs hey bertl!
1105437008 M * Bertl greetings folks!
1105437011 M * Bertl hey rs!
1105437028 M * rs hwo are you ?
1105437072 M * Bertl fine thanks ...
1105437075 M * Bertl and you?
1105437101 M * chrish01 hey Bertl
1105437117 M * Bertl hey chrish01!
1105437172 M * Mega\work good morning Bertl! :D
1105437271 M * Bertl morning to you too Mega\work!
1105437509 M * Mega\work Bertl, why in a client with sshd in 2 vserver and in a real host, i have problem to connect to vserver ssh?
1105437613 M * Mega\work Yesterday, one user of chanel, have advised me to use v_ssh if i remember
1105437727 M * Bertl don't know what issues you encounter, but v_ssh is not a good solution ...
1105437803 M * Mega\work then, vserver ldap have ip 192.168.0.10, vserver samba 192.168.0.20 and real host 192.168.0.1
1105437868 M * Mega\work if sshd of the vserver is down, and i try  connect to the ip of vserver......i enter in a real host ssh
1105437900 M * chrish01 is host ssh listening to 0.0.0.0?
1105437922 M * Mega\work uhm........i don't now
1105437939 M * Mega\work uhm........i don't know
1105437950 M * BWare cat /etc/ssh/sshd_config | grep Listen
1105437955 M * Mega\work ok
1105437982 M * BWare if your ssh config resides in /etc/ssh
1105438045 M * Mega\work server2:~# cat /etc/ssh/sshd_config | grep Listen
1105438045 M * Mega\work #ListenAddress ::
1105438045 M * Mega\work #ListenAddress 0.0.0.0
1105438045 M * Mega\work server2:~#
1105438054 M * Mega\work the line is commented
1105438068 M * chrish01 make it only listen to the host IP addr
1105438080 M * chrish01 then restart ssh
1105438288 M * Mega\work good, now i try to connect with vserver ip.......
1105438538 M * Mega\work good......it work
1105438540 M * Mega\work :))
1105438611 M * chrish01 good good
1105438783 Q * BWare Remote host closed the connection
1105438785 M * Mega\work you have always solutions for any problem
1105438845 J * BWare ~bware@212.26.196.158
1105439243 N * chrish01 chris|zzz
1105440014 Q * BWare Ping timeout: 480 seconds
1105440618 J * BWare ~bware@212.26.196.41
1105442735 M * Bertl okay, back later ...
1105442740 N * Bertl Bertl_oO
1105444865 J * _v00dY v00dy@62.241.52.143
1105444970 Q * v00dY Ping timeout: 480 seconds
1105445665 N * _v00dY v00dY
1105445895 Q * eyck Read error: Connection reset by peer
1105445978 J * are|afk ~are@gateway-dsl.lihas.de
1105446258 N * are|afk _are_
1105446260 M * _are_ hi
1105446951 J * eyck eyck@81.219.64.71
1105447851 J * Pazzo ~thomas@host130-250.pool8172.interbusiness.it
1105448383 J * lilo_ ~lilo@lilo.usercloak.oftc.net
1105448383 Q * lilo Read error: Connection reset by peer
1105448808 J * lilo ~lilo@lilo.usercloak.oftc.net
1105448808 Q * lilo_ Read error: Connection reset by peer
1105452627 N * Bertl_oO Bertl
1105452677 M * Bertl evening folks!
1105452696 M * Pazzo hi bertl!
1105452884 M * rs wb Bertl 
1105452899 M * Bertl hey rs! still awake?
1105452904 M * rs yeah :)
1105452967 M * rs Bertl: do you consider your capset patch stable ?
1105452972 M * rs ready for production ?
1105452987 M * Bertl which one?
1105452996 M * rs the cap mask stuff
1105453023 M * Bertl well, it's in 1.9.3.14+, but it needs some other work to finally make sense ...
1105453043 M * Bertl (i.e. the overloaded caps have to be cleaned up)
1105453056 M * rs you mean it's not yet functionnal ?
1105453069 M * rs or it will change in the future ?
1105453070 M * Bertl and I'm trying to get a statement regarding the future of linux capabilities from lkml folks ...
1105453081 M * rs yeah I saw you mail to linus
1105453105 M * Bertl so that we do not go in a direction and mainline in another ;)
1105453151 M * Bertl we added the capmask for a single capability and the cleanup there isn't complete ... so it's partially functional ...
1105453195 M * rs ok
1105453219 M * Bertl but it's easy to add the missing pieces, it's jsut a hell of testing work
1105453220 M * rs and is there some significant change in 1.9.3.X ?
1105453255 M * Bertl yes, actually a bunch of changes, and I'm not sure all are towards stability ...
1105453268 M * rs no bugfixes ?
1105453273 M * rs only new features ?
1105453285 M * Bertl bugfixes too, not much features but architectural changes
1105453291 M * _are_ Bertl: the Ooopses are at http://vgn.lihas.de/bugs/opteron-megaraid-ops-1.jpg and http://vgn.lihas.de/bugs/opteron-megaraid-ops-2.jpg, but unfortunately the photographer took only a photo of the left part of the screen. :-/
1105453322 M * _are_ I think it is some bug in the megaraid_mbox module
1105453373 M * Bertl are those two different oopses, or one oops following another?
1105453386 M * _are_ the same screen, top and bottom of screen
1105453408 M * _are_ unfortunately no right handside
1105453415 M * rs bugs in megaraid code? surprising! :o)
1105453451 M * Bertl well, looks more like a reiser issue to me ...
1105453462 M * _are_ to my understanding, find went over a reiserfs and crashed the box in megaraid_mbox
1105453474 M * Bertl (but as I do not see the first lines and the right side :/)
1105453485 M * _are_ but I am not used to reading OOpses, so i might approach tis wrong
1105453507 M * _are_ ...1.jpg is th top of the screen, no possibility to scroll back :-(
1105453530 M * _are_ and the right handside, well, hmm, umpf. seems my indstructions had not been specific enough.
1105453572 M * sannes .. :)
1105453594 M * sannes morning folks! hi _are_, Bertl & rs! :)
1105453601 M * _are_ Hi sannes
1105453621 M * sannes _are_ : experiencing problems with reiserfs aswell now?
1105453627 M * _are_ the good news: i got at least a 32-bit qemu running in a vserver now
1105453652 M * _are_ sannes: told you reiserfs gives trouble, as well as ext3 and xfs. had all of them killing data already
1105453684 M * sannes _are_ : cause the test that made my 2.6.10 was a fgrep amazingstring * -R ..
1105453704 M * sannes _are_ : so find it really parallell to that.. 
1105453720 M * sannes ext3 aswell.. ok, *ditching plan to move to ext3 for the time beeing*
1105453734 M * sannes guess ext2 just will have to do.. :)
1105453751 M * Bertl hey sannes!
1105453752 M * _are_ well, last ext3 corruption is 1 year ago
1105453775 M * _are_ last xfs corruption 1.5 years (but had no xfs since 1 year, either)
1105453792 M * _are_ you basically have the choice between bad and worse.
1105454076 M * sannes but you are getting OOPSes with 2.6.10 w/ reiserfs when doing a find ?
1105454111 M * _are_ well, seems so. looking at the photos I see 3 things I know: find, reiserfs and megaraid_mbox
1105454133 M * _are_ it is this dual-opteron machine, so might as well be some 64-bit issue elsewhere, I still don't really trust it
1105454614 M * sannes I was using a hyperthreaded xeon ..
1105454619 M * sannes and that was 32 bit..
1105454809 M * sannes thing is, after I cleaned up the filesytem (and all extended attributes, I havn't enabled them in the new kernel) I always get the same oops, and from what I see from it current is NULL at some point, and referencing it current->mm is of course going to fail..
1105454937 M * rs Bertl: is there a 2.6.0-vs1.9.3 patch ?
1105454957 M * Bertl 2.6.0?
1105454962 M * rs oups :)
1105454965 M * rs 2.6.10 sorry
1105454977 M * Bertl hmm, not that I know of ...
1105454995 M * rs no-one was interested in ?
1105455016 M * Bertl well, there is 1.9.3.17 for 2.6.10 ...
1105455093 M * rs yeah but are changes between 1.9.3 and 1.9.3.17 stable enough for production ?
1105455113 M * Bertl not without some testing first ...
1105455135 M * Bertl just for the record, 1.9.3 isn't production either
1105455141 M * rs yeah it's why I would like to use 1.9.3 which is already tested for weeks
1105455151 M * rs it's production for us :)
1105455186 M * _are_ what changed from 1.9.3.16 to 1.9.3.17? any bugfixes that might be relevant for my opteron setup?
1105455216 M * Bertl we fixed a race/sleep issue with 1.9.3.17
1105455258 M * rs Bertl: so you think that .17 would fit for a little upgrade with some testing?
1105455310 M * Bertl no, but 1.9.3.18+ should ...
1105455357 M * sannes know when we can disable legacy vserver support ? :)
1105455378 M * Bertl as soon as ngnet is up and running ...
1105455478 M * rs Bertl: I can't find .18 :)
1105455498 M * Bertl ;)
1105455554 M * rs ok got the message :)
1105455589 M * sannes If I understood correctly; with ngnet I can add new IPs to a contexts interface without actually restarting the context? :)
1105455618 M * sannes (or entering it with more ips using chbind)
1105455632 M * rs btw, would it be possible to avoid nfs mounts from inside vservers ? maybe with a compile time option of a separated patch ?
1105455737 M * Bertl sannes: well, ngnet doesn't have this 'the host controlls the interfaces' scheme at all ...
1105455787 M * sannes Bertl : so I understood correctly, which is good :)
1105455867 M * Bertl basically ngnet consists of two parts (from the userspace point of view)
1105455885 M * Bertl some rules to permit traffic from and to the vserver
1105455902 M * Bertl and the vserver internal configuration (which is not host controlled)
1105456059 M * sannes in other words, less startup scripts to adjust :)
1105456098 M * Bertl hmm ... I'd say more, but YMMV
1105456117 M * sannes from the vservers perspective..
1105456129 M * sannes it will setup the networking itself..
1105456147 M * Bertl yes
1105456148 M * sannes so copying it from a physical computer and viceversa ..
1105456180 M * sannes maybe more on the outside, but that is something you control yourself so it is all good.. :)
1105456232 M * Loki|muh so, the vserver can assign itself any ip it wants but the host must permit traffic from and to that ip?
1105456421 M * Mega\work excuse me if i'm OT
1105456452 M * Mega\work Anyone knows the new bug of kernel 2.4.28 or first?
1105456458 M * sannes does the current util-vserver have any support for this? and iptables has to have a patch right? and it uses contextids, so maybe there should be a wrapper around iptables to enable name to -> vserver id lookup..
1105456464 M * Mega\work privilege excalation
1105456901 P * Pazzo 
1105458091 J * mhepp ~mhepp@r72s22p13.home.nbox.cz
1105458225 M * _are_ yesterday 'suddenly' all my --rbind mounts became --bind mounts when one partition below a --rbind source section got remounted.
1105458263 M * _are_ I hadto add all directories to /etc/fstab and mount them with --bind to access them again, --rbind din't work anymore.
1105458281 M * _are_ or, --rbind did a --bind.
1105458289 M * _are_ has anyone else experienced this?
1105458306 M * sannes what was rbind again?
1105458318 M * _are_ sannes: recursive --bind
1105458343 M * sannes it binds all the mounts below too ?
1105458362 M * _are_ so if you mounted /a/b, /a/b/c, a/b/d you can just --rbind a -> x and get x/b, x/b/c, x/b/d
1105458369 M * _are_ yes
1105458434 M * _are_ the real problem there is the vserver not recognizing it when a filesystem gets mounted below its /, you have to restart the vserver for it to take effect inside, or is there some easier way?
1105458791 M * sannes with 2.6 you mount stuff into a namespace, this is why mounts done in the host isn't seen until you make a new namespace (I think I have understood this correctly, not sure) .. so the question is how do you mount something into a namespace that already exist, but your are not in.. and basically I think we just have too look at how it is done when a new namespace is created ...
1105458859 M * sannes (this is also why the fstab for each vserver doesn't mount anything into the host namespace)
1105458889 M * _are_ argh.
1105458900 M * _are_ and a namespace is a context?
1105458955 M * _are_ if so, chcontext should do the trick, if I understand correctly
1105458968 M * Bertl Loki|muh: yes
1105459058 M * Bertl _are_: no, namespaces are a mainline feature, the vserver kernel just allows to use them for contexts in an easy and natural way
1105459116 M * _are_ ok, does chcontext by chance still permit me to mount something for a vserver? or do i need some other tool?
1105459203 M * Bertl you need vnamespace
1105459305 M * Mega\work Bertl, you have see the new bug of kernel?
1105459306 M * sannes this reminds me of something, why can't I have / in the vserver fstab? or is it just an ordering issue?
1105459324 M * _are_ vnamespace -e 101 mount --rbind /backup /var/lib/vservers/samba/backup/ works, indeed :-)
1105459429 Q * sannes Read error: Connection reset by peer
1105459478 M * Bertl Mega\work: maybe ... any url?
1105459486 M * Mega\work yes
1105459521 M * Mega\work one moment.......i search the links
1105459557 M * Mega\work http://lists.debian.org/debian-kernel/2005/01/msg00131.html
1105459662 M * Bertl ah, yes, read that one ...
1105459825 M * Bertl looks interesting, but should be easy to fix ...
1105459831 M * Mega\work i want to patch the kernel, but the problem is: I must repatch with all patch (patch bug+grsec+vserver) or I can patch the source also with the grsec+vserver patch?
1105459839 M * Mega\work easy?
1105459877 M * Bertl That
1105459879 M * Bertl segment is created with the  current->mm->mmap_sem  semaphore  NOT  held
1105459882 M * Bertl ...
1105459894 M * Bertl so just holding that semaphore should be enough ;)
1105459910 M * Bertl s/enough/sufficient/
1105459914 M * Mega\work i don't understand
1105459939 M * Bertl the exploit is based on an unintentional race
1105459966 M * Bertl (which probably causes other issues without any 'exploit')
1105460076 M * Mega\work uhm..........and,what's the solutions?
1105460209 M * Mega\work the exploit isn't remote, is true?
1105460229 M * Bertl no, most local exploits are not remote ;)
1105460232 M * Bertl *sorry*
1105460253 M * Bertl but you are right that this issue is interesting for linux-vserver
1105460277 M * Bertl because it might allow you to escape UML but _not_ linux-vserver ;)
1105460339 M * Loki|muh hehe, nice
1105460396 A * _are_ feels save ;)
1105460967 J * sannes ~ace@home.skarby.no
1105461679 M * sannes hm
1105461705 M * Bertl a good start for a question ;)
1105461759 M * Mega\work eheheh
1105462435 J * jsambrook ~jsambrook@aelfric.plus.com
1105462845 Q * BWare Ping timeout: 480 seconds
1105463824 M * Snow-Man Bertl: err, hrmpf.
1105463829 Q * _are_ Quit: Disconnecting
1105463838 M * Bertl Snow-Man: exactly!
1105463845 M * Snow-Man Bertl: Can you keep the vserver patch to *just* vserver stuff?
1105463859 M * Snow-Man Bertl: As in, don't do things like merge in the uselib fix.
1105463876 M * Snow-Man That'll just make the vserver patch conflict with distribution kernel trees.
1105463884 M * Bertl hmm, how do you know?
1105463901 M * Snow-Man Because the uselib fix is already in the Debian distributed 2.6.10 kernel release.
1105463917 M * Bertl excellent!
1105463930 M * Snow-Man And I can cleanly patch in the vserver patch w/ all of Debian's patches currently. :)
1105463933 M * Snow-Man And I like that. :)
1105463936 M * Bertl (but it's not in vanilla 2.6.10, right?)
1105463944 M * Snow-Man No, it's not in vanilla 2.6.10.
1105463964 M * Bertl ;)
1105464005 M * Snow-Man I'm just saying, don't make the vserver patch anything but the *vserver* patch.
1105464025 M * Bertl hmm, okay, guess we have to remove a lot of stuff then :/
1105464031 M * Snow-Man If you really want to have another patch that's "vserver plus other fixes we thought you might like" then maintain that as a seperate patch.
1105464049 M * ndim Hmm. If the vserver patch depends on another patch, then there should still be a patch from vanilla to vserver, including all the other stuff.
1105464086 M * Snow-Man erm, if the vserver patch *depends* on another patch (is that actually the case?) then I can see a claim that, really, that other patch is part of vserver stuff.
1105464097 M * Snow-Man It's just extra ancillary things, like the uselib fix, that I don't like.
1105464107 M * Snow-Man Mostly because it'll conflict with other things.
1105464108 M * Bertl or the memory split?
1105464138 M * Snow-Man You'll have to enlighten me on that one.
1105464158 M * Snow-Man I do know that the 2.6.9 vserver patch conflicted with the later Debian 2.6.9 kernels, which sucked.
1105464160 M * Bertl well, it allows you to use 2GB memory without highmem, for example
1105464175 M * Bertl (very useful for linux-vserver ;)
1105464193 M * Snow-Man Bertl: Is it really?
1105464210 M * Snow-Man And does it interact with the vserver patch?
1105464223 M * Bertl yeah, avoids a bunch of lowmem issues and the highmem overhead
1105464240 M * Snow-Man That's true generally though, not something vserver specific.
1105464247 M * Bertl and it's 'in' linux-vserver since a few releases
1105464247 M * ndim How dependent is that from the "real" vserver patch? As in "does one have to merge manually" or "merging can be done by applying two patches"?
1105464274 M * ndim AFAIR, the vserver patch always comes broken out into several smaller patches.
1105464279 M * Bertl yep
1105464298 M * ndim Snow-Man: Can't you just ignore those of them which you already have?
1105464309 M * Snow-Man ndim: I only know of one vserver 2.6.10 patch..
1105464318 M * Bertl that's what I do with new releases (mainline)
1105464335 M * Snow-Man What I'm asking for is to have seperate patches for different things.  If that exists already, then that's great.
1105464337 M * Bertl http://vserver.13thfloor.at/Experimental/split-vs1.9.3.14/
1105464346 M * Bertl this was the last 'requested' splitup ;)
1105464360 M * Bertl http://vserver.13thfloor.at/Experimental/split-vs1.9.3.14/25_other.diff
1105464368 M * Bertl (useful, but not required stuff ;)
1105464395 M * Snow-Man Bertl: Everything else is 'vserver-required' stuff then?
1105464415 M * Bertl well, you can look at it this way .. I guess ...
1105464440 M * Snow-Man And is that for 2.6.10, and what of that is included in patch-2.6.10-vs1.9.3.17.diff ?
1105464467 M * Bertl it's vs1.9.3.14 ...
1105464479 M * Bertl (against 2.6.10)
1105464479 A * Snow-Man blinks.
1105464496 M * Snow-Man So, you don't maintain the seperate patches normally?
1105464496 M * ndim </blink>
1105464531 M * Snow-Man ndim: :)
1105464540 M * Bertl Snow-Man: no, but if you like a splitted version of 1.9.3.17, you can get that ...
1105464558 M * Bertl but I'd wait for 1.9.3.18+
1105464576 M * Bertl or use 1.9.3.14 for now, and add the delta later
1105464592 M * Snow-Man Bertl: I can get that... how?
1105464617 M * Bertl usually by doing /msg Bertl hey bertl, I'd like to get a broken out version of ...
1105464643 M * Snow-Man heh.
1105464687 M * Snow-Man I don't really want to have to instigate it every time, and it seems like it'd take up alot more of your time..
1105464732 M * Bertl well, every 'release' has it by default ...
1105464751 M * Bertl (so you don't have to bother me for those splits)
1105464766 M * ndim Bertl: Do you really create these broken out patches manually?
1105464768 M * Snow-Man ok, that's really what I'm after, I guess there hasn't been a '2.6.10' release yet?
1105464792 M * Bertl ndim: no, that does a magic script for me, but I do some checks on the releases ...
1105464853 M * Loki|muh automagically *g*
1105464893 M * Snow-Man Ah, I'm guessing that's the 'split-blah'
1105464909 M * Snow-Man hrmpf, that's actually a bit more of a pain in the butt for me. :)
1105464937 M * Snow-Man Since it means I'm gonna have to go through and figure out which of the split patches have already been merged by the Debian kernel team because they're things like uselib.
1105465002 M * Snow-Man I really wonder about the HZ changes too...
1105465052 M * Bertl Snow-Man: hmm, guess you didn't understand it yet ...
1105465075 M * Snow-Man Bertl: Which is that?
1105465087 Q * sannes Read error: Connection reset by peer
1105465094 M * Bertl you can _assume_ that all patches except the *_other patch are 'essential' vserver patches
1105465119 M * Snow-Man Bertl: Alright..
1105465132 M * Bertl and that *_other is a mix of the _additional_ patches like HZ/split or uselib (if included)
1105465157 M * Snow-Man As long as that assumption holds then I suppose I can live with that. :)
1105465170 M * Bertl the advantage of the 'splits' is that you have it grouped by category
1105465189 M * Snow-Man The split mem patch scares me less than the HZ changes. :)
1105465203 T * services.oftc.net http://linux-vserver.org/ | latest stable 1.29, devel 1.3.9, 1.9.3, ng8.7
1105465211 M * Bertl so if you _know_ that debian is messing with the vma (for example)
1105465230 M * Bertl then you would concentrate on the *_memory stuff ;)
1105465285 M * Snow-Man Well, if anything other than _other.diff fails then it's a bigger issue.
1105465307 M * Bertl exactly!
1105465308 M * Snow-Man I expect that Debian vserver releases would include everything except the _other.diff.
1105465327 M * Snow-Man And as such you can put whatever you want in there. :)
1105465351 M * Snow-Man For me, personally, some of the other things might be nice.
1105465367 M * Bertl well, and I expect that a linux-vserver kernel has the features I put in ... which might include the *_other stuff ...
1105465371 M * Snow-Man I'm not 100% confident about your HZ patch atm though.
1105465397 M * Bertl so it's fine if debian kernels do not include this stuff, but it should be stated somewhere ...
1105465423 M * Snow-Man Bertl: The Debian kernels are probably going to already have some things (at least if you put things like security patches into other)
1105465448 M * Bertl yeah, in this case, it's fine ...
1105465450 M * Snow-Man But they won't have other things (like the HZ stuff and memory split)
1105465462 M * Bertl maybe I shoild add a *_security too?
1105465463 M * Snow-Man At least not until that's accepted upstream anyway.
1105465486 M * Snow-Man Bertl: I dunno.
1105465486 M * Bertl just make sure to document it somewhere ...
1105465507 M * Snow-Man Bertl: We can have the README.Debian mention it, but I don't think it's going to outline every specific thing that's in or not in.
1105465510 M * Bertl something like: the following linux-vserver kernel features are missing ...
1105465530 M * Snow-Man Since it'll basically be impossible to have it be up-to-date.
1105465558 M * Snow-Man If, for example, the HZ changes or the memory split changes get into a -rc Linus kernel and then show up in the Debian kernels.
1105465575 M * Bertl as long as the other debian packages do not 'require' folks to use the debian kernel/patch, it's probably fine with me
1105465577 M * Snow-Man That can happen w/o the Debian kernel-patch-vserver package ever being updated.
1105465590 M * Bertl (they can always switch to a recent release)
1105465607 M * Snow-Man Bertl: I don't see how it could require it...
1105465620 M * Snow-Man Unless you change the kernel interface to depend on things in _other..
1105465645 M * Bertl userspace -> kernel (was what I meant)
1105465658 M * Bertl something like the rh folks did with nptl
1105465708 M * Snow-Man eh, I don't expect Debian to make changes like that in their kernel.
1105465724 M * Snow-Man I do expect the util-vserver packages to work w/ the Debian kernels + patches though.
1105465757 M * Snow-Man If that means the util-vserver Debian packages don't work w/ stock kernels then personally I think that'd be a bug somewhere.
1105465776 M * Bertl okay, that's what I meant!
1105465780 M * Snow-Man (err, stock vserver releases, I mean)
1105465797 M * Bertl and it should be fine then!
1105465801 M * Snow-Man Welp, if that happens then let me know and we can see about addressing it, but I don't really expect it to happen.
1105465820 M * Snow-Man Just don't make the vserver kernel interface depend on stuff in _other. ;)
1105465855 M * Snow-Man let's talk about the HZ stuff tho.
1105465868 M * Bertl hmm?
1105465874 M * Snow-Man Since, atm, that's in my personal kernels and I'm not entirely convinced it doesn't break things.
1105465887 M * Loki|muh Snow-Man: hmm, are you a debian developer?
1105465903 M * Snow-Man Loki|muh: Yes, though I'm not the maintainer of util-vserver.
1105465938 M * Loki|muh i just wondered, thanks :)
1105465963 M * Snow-Man Bertl: I see that the patch as-is, if you don't actually use CONFIG_KERNEL_HZ, does change some things.
1105465983 M * Bertl yes? what?
1105465997 M * Snow-Man Bertl: What's worse, I'm a little worried that if you do use CONFIG_KERNEL_HZ that not everything that uses HZ's/jiffies are fixed.
1105466057 M * Bertl any change at HZ=1k is considered a bug (except for the wraparound fix), so please report it 
1105466101 M * Snow-Man hrmm, wraparound fix?
1105466102 M * Bertl any missing HZ/jiffie thingy which doesn't work at 20-20k as expected is considered a bug too, please report, patches are welcome
1105466175 M * Snow-Man jiffies change at a faster rate if you change HZ, right?
1105466233 M * Bertl yep, jiffies = ticks = timer irqs 
1105466297 M * Snow-Man Hmm, actually, I guess I do use HZ.
1105466352 M * Snow-Man Bertl: I was just thinking it might impact the netfilter kernel module I wrote (ipt_recent).
1105466389 M * Snow-Man +#else
1105466389 M * Snow-Man +unsigned long ip_ct_sctp_timeout_established       =  2U DAYS;
1105466389 M * Snow-Man +#endif
1105466394 M * Snow-Man What's with stuff like that though?
1105466442 M * Bertl depends on the values
1105466486 M * Bertl #define SECS  * HZ
1105466486 M * Bertl #define MINS  * 60 SECS
1105466486 M * Bertl #define HOURS * 60 MINS
1105466486 M * Bertl #define DAYS  * 24 HOURS
1105466519 M * Bertl 2^32/(24*60*60*20000)
1105466519 M * Bertl 2.4855134814
1105466527 M * Bertl so 2 should be fine ;)
1105466556 M * Snow-Man It's supposted to be 5 days tho?
1105466586 M * Bertl 5 is bad ... only work up to 2^32/(24*60*60*5)
1105466586 M * Bertl 9942.0539259259
1105466591 M * Bertl HZ ;)
1105466618 M * Snow-Man erm, the point is that the spec is *5 days&
1105466661 M * Snow-Man I realize that doesn't work if HZ > 10,000 w/ your current changes, but that's not the point.
1105466664 M * Bertl well, needs a larger type then ...
1105466685 M * Bertl (I'll probably do that in the future ...)
1105466718 M * Snow-Man I've got a meeting, but that'd certainly be a reason to not encourage usage of your HZ changes.
1105466722 M * Snow-Man bbiab.
1105467828 Q * Mega\work Quit: Leaving
1105468256 Q * bengrimm Read error: Connection reset by peer
1105468888 M * Bertl okay, I'm off for now ... back alter ...
1105468895 N * Bertl Bertl_oO
1105469361 J * Pazzo ~thomas@host130-250.pool8172.interbusiness.it
1105470440 Q * rs Quit: leaving
1105470903 N * chris|zzz chrish01
1105472285 J * sannes ~ace@home.skarby.no
1105472450 Q * dsanta Ping timeout: 480 seconds
1105472617 J * dsanta ~santa@c68.190.156.105.roc.mn.charter.com
1105475532 J * nayco ~nayco@lns-vlq-47-nan-82-252-247-66.adsl.proxad.net
1105475562 M * nayco 'llo !
1105476935 Q * sannes Read error: Connection reset by peer
1105477591 Q * serving Ping timeout: 480 seconds
1105477803 J * Tbery ~tb@81.27.192.66
1105478203 Q * mhepp Remote host closed the connection
1105479495 P * Pazzo 
1105479511 Q * Tbery Quit: Ukončuji
1105481945 J * frz ~frz@jaim.at
1105481977 P * frz 
1105482557 J * frz ~frz@jaim.at
1105482560 P * frz 
1105482577 J * frz ~frz@jaim.at
1105483183 J * _are_ ~are@dsl-084-056-148-176.arcor-ip.net
1105483902 J * sannes ~ace@home.skarby.no
1105484313 J * serving ~serving@213.186.185.143
1105484412 M * nayco 'llo (again) all !
1105484434 M * nayco How can I get rid of the errors when starting/stopping a vserver, pls ?
1105484458 M * nayco Do I have to poke around in the startup scripts to comment the lines ?
1105484824 M * _are_ which error?
1105484898 M * _are_ you can't set up networking, hostname, hardwareclock or mount stuff -> don't do it i init scripts
1105484909 M * _are_ (within the vserver, ofc)
1105485043 M * nayco yes, this kind of errors !
1105485079 M * nayco I understand some errors, like "(un)mounting swap", "syncing clock", etc...
1105485096 M * nayco But I don't know how to get rid of !
1105485108 M * _are_ yes, just remove the init scripts as these tasks are already done in the host
1105485134 M * nayco Can I simply erase the responsible scripts, or do they stillhave a useful role in the vserver ?
1105485149 M * _are_ wel, they might be oart o pakcage management
1105485154 M * nayco ok. Basically, what needs to be preserved ?
1105485155 M * _are_ hmpf
1105485166 M * _are_ wel, they might be part o package management
1105485166 M * nayco sorry ?
1105485170 M * nayco ok ;-)
1105485178 M * _are_ not much better, that time
1105485204 M * _are_ chkconfig on redhat, update-rc.d on debian helps
1105485209 M * nayco well, dunno... Package management needs something initialized at startup time ?
1105485229 M * _are_ no, if you update something they might re-set the links
1105485279 M * nayco Yes, good point.
1105485292 M * _are_ anyway, asleep now
1105485297 N * _are_ are|afk
1105485362 M * nayco By the way, I managed to setup my second vserver today, using a local mandrake mirror on a partition, and "urpmi --root --media local basesystem"... I get a ~100Mb template vserver.
1105485373 M * nayco thanks, good night.
1105485440 M * nayco s/--root/--root /vservers/template\//
1105485464 M * nayco well... Missed ;)
1105485569 Q * monrad Quit: Leaving
1105485917 Q * dsanta Remote host closed the connection