1215822368 J * doener_ ~doener@i577B9A3D.versanet.de
1215822471 Q * doener Ping timeout: 480 seconds
1215822496 Q * FireEgl Quit: Leaving...
1215823069 J * dniel ~ary@host235.190-30-187.telecom.net.ar
1215825047 Q * dniel Quit: Leaving
1215825909 Q * awake Ping timeout: 480 seconds
1215826894 M * micah arg, bind9 in lenny seems to require capabilities
1215827014 M * Bertl_oO micah: you mean, capability masking is not sufficient?
1215827047 M * micah Bertl_oO: sadly this is a newer guest than the host, which has an older kernel
1215827073 M * Bertl_oO ah, okay, so a very? old debian kernel :)
1215827097 M * micah an etch kernel, I wouldn't say *very* old :)
1215827107 M * micah but wouldn't have capability masking
1215827152 M * Bertl_oO hmm, we have capability masking since vs2.1
1215827174 M * Bertl_oO so except for vs2.0.x kernels, it should be there
1215827274 M * micah didn't we establish a few days back that the etch kernel was vs2.0.2.2-rc9.patch with some patch modifications?
1215827290 M * micah yes, it looks like it is
1215827307 M * Bertl_oO well, so it _is_ very old then :)
1215827388 M * micah 1.5 years since 2.6.18 was released
1215827394 M * Bertl_oO get a bind8 or so for that, for bind9, a recent kernel should be used
1215827430 M * micah uff bind8
1215827444 M * micah that one is vulnerable to the port randomization issue that was released recently
1215827498 M * Bertl_oO well, you can't expect that a kernel/patch which is more than a year old, handles (almost) up to date bind issues
1215827655 M * micah i can't really expect anything :)
1215827692 M * Bertl_oO what I mean is, if userspace gets updated (newer bind branch), then somebody has to update the kernel branch too
1215827770 M * Bertl_oO 2.0.2.2-rc9 was december 2006
1215827794 M * Bertl_oO we have now july 2008 .. time to switch to vs2.2.x
1215827851 M * Bertl_oO (which was declared stable in april 2007, btw :)
1215827877 M * micah there is a vast gulf that lies between development and production, both sides have different priorities :)
1215827914 M * micah debian will be freezing soon and then when the release comes, there will be a great lurch forwards 
1215827936 M * Bertl_oO np with that, but, if production uses a kernel that is almost two years old, why use a bind branch which is only a few months?
1215827979 M * micah because the Linux-Vserver project allows us to have guests of different operating system release levels while the host is at a more stable one
1215828022 M * micah so, because the host insists on debian stable, which means 2.6.18 with 2.0.2.2-rc9, I'll have to find a different solution for the bind9 in newer guests until the release
1215828032 M * Bertl_oO I don't buy the stable part, kernels are not 'more stable' just because they are older :)
1215828066 M * Bertl_oO and in this specific case, we know that a lot of things got fixed since 2.0.2.2-rc9
1215828122 M * micah well, your definition of stable is different... mine is: it works so dont change it
1215828126 M * Bertl_oO that's why there was a 2.0.3 release, for example
1215828161 M * micah the current kernel works fine, if I update to the newer kernel then I risk new issues being exposed, while the current one is predictible
1215828195 M * Bertl_oO yes, it fails predictably in certain situations :)
1215828195 M * micah once there has been a thorough round of testing, and there is distribution support for it, then I will switch to it
1215828207 M * micah its nice to know the limitations and failures actually
1215828226 M * micah because you can work with them, a whole new set of issues with a new kernel means something different entirely
1215828253 M * micah let me tell you...when you are managing 300+ servers its not fun to install the latest kernel whenever they are released
1215828273 M * Bertl_oO you just don't get this part, I'm not talking about changing the kernel, I'm talking about updating the kernel you use by incorporating fixes to known bugs
1215828276 M * micah its more fun to do other things then spend all your time chasing down the latest problem that someone didn't think of :)
1215828294 M * micah updating the kernel without changing the kernel?
1215828319 M * Bertl_oO and debian should have adopted the stable branch of Linux-VServer a long time ago, like 1 and a half year ago or so
1215828382 M * Bertl_oO you might have noticed that we have to tell all debian folks who come here to use tools and kernel from backports, because we _know_ that the kernel they install (from the distro) doesn't work
1215828433 M * Bertl_oO where 'doesn't work' subsumes all the known (and for a long time fixed) bugs as well as the missing features of the current stable branch
1215828494 J * awake ~irc-user@75-121-151-1.dyn.centurytel.net
1215828525 M * micah I thought that the stable branch of Linux-VServer was not 2.0.3 by the time the debian kernel was frozen for etch
1215828537 M * Bertl_oO but Linux-VServer is in good company, when it comes to broken 'kernel' features on debian ... I recently tried to get a debian sid/lenny to play nice with clustering .. it worked once I replaced the kernel and most of userspace by self compiled stuff
1215828584 M * micah Bertl_oO: I know you hate debian, its no secret :)
1215828599 M * Bertl_oO wrong, I hate 'Debian Policy'!
1215828609 M * micah or perhaps the kernel team
1215828656 M * micah you might not like the users then, because the policy is set after years and years of bickering with the debian community and developers
1215828669 M * micah there really isn't a good solution that fits everyone
1215828675 M * Bertl_oO well, it's the interpretation
1215828692 M * micah which perhaps is a fault of a distribution that is trying to serve the most common denominator
1215828720 M * Bertl_oO I haven't seen debian users here who agreed that an outdated and 'known broken' kernel, which is 'labeled' stable is something they actually like
1215828743 M * micah heheh
1215828752 M * Bertl_oO nor do they like to install tons of stuff from backports to get their system running :)
1215828773 M * micah well, this was the reason for Etch and a half
1215828781 M * micah which was to ship 2.6.24
1215828803 M * Bertl_oO which is, btw, one of the worst kernel releases since 2.6.0
1215828806 M * micah which I am not sure what the status of that project is
1215828814 M * micah yeah, I think that might have been part of the problem :)
1215829094 M * Bertl_oO anyway, debian is your business, just let me know when I can stop telling 'the debian users' that they should forget about the 'stable debian branch' when they want to actually use Linux-VServer :)
1215829158 A * cehteh happily uses vserver on debian without the debian packages :)
1215829202 M * Bertl_oO okay, off to bed now ... have a good one everyone!
1215829208 N * Bertl_oO Bertl_zZ
1215829219 M * cehteh n8
1215829243 M * micah goodnight Bertl_zZ
1215831301 Q * marv_ Quit: Leaving
1215840649 Q * awake Quit: awake has no reason
1215847866 N * DoberMann[ZZZzzz] DoberMann[PullA]
1215850946 J * dna ~dna@204-238-dsl.kielnet.net
1215851238 J * danman danman@eliza.wigner.bme.hu
1215851318 M * danman Hi! My ISP assigned me an additional IP for my server that is on a completely different subnet. I only have 1 network interface phisically, but what I would like is that the vserver would use this new IP with a completely different default gw. Is this possible?
1215852020 M * cehteh yes
1215852052 M * cehteh just setup the IP as usual, vservers use aliased interfaces anyways
1215852082 J * arachnist arachnist@atlnts.org
1215852085 M * arachnist hi
1215852114 M * arachnist kerrigan ~ # vserver centkupa build --hostname centkupa --interface eth0:192.168.0.237 --initstyle sysv -m yum --rootdir /home/vservers -- -d centos5
1215852117 M * arachnist capget(): Invalid argument
1215852125 M * arachnist but i do have capabilities enabled in the kernel
1215852132 M * arachnist kerrigan ~ # zgrep -i cap /proc/config.gz
1215852132 M * arachnist CONFIG_SECURITY_CAPABILITIES=y
1215852142 M * arachnist any ideas?
1215852178 M * danman cehteh: and how about the different default gw?
1215852303 M * cehteh danman: there is a config option for that -> great flower page
1215852346 M * danman ok, great flower
1215852347 M * danman thx
1215852479 M * cehteh mhm or not? .. well if not, normal routing applies
1215852506 M * danman 1 more thing, if I may ;-) There's  this page: http://www.gentoo.ro/doc/en/vserver-howto.xml  I don't seem to have vserver-new on my gentoo for some reason. how can that be?
1215852516 M * danman I have util-vserver emerged
1215852567 M * cehteh dunno how gentoo does that
1215852574 M * danman ok
1215852584 M * danman cehteh: so normal routing :-( I need I guess iproute2
1215852590 M * cehteh well try     vserver foo build --help
1215852608 M * danman ok
1215852622 M * cehteh .. naptime
1215853555 J * friendly ~friendly@ppp59-167-145-230.lns4.mel6.internode.on.net
1215853784 J * loddafnir ~mike@193.170.138.233
1215854163 J * mire ~mire@204-172-222-85.adsl.verat.net
1215854245 Q * mire Read error: Connection reset by peer
1215855021 M * arachnist ok
1215855043 M * arachnist i had util-vserver compiled with newer linux-headers than my current kernel is
1215855085 A * ruskie looks for vserver patches for 2.6.25.10... can anyone point me to such?
1215855176 M * arachnist ruskie: http://vserver.13thfloor.at/Experimental/patch-2.6.25.10-vs2.3.0.34.13.diff ?
1215855201 M * ruskie tnx
1215855443 M * ruskie would be nice if that were to be linked from the wiki sometime...
1215856055 J * raphinou ~rb@88.197.235.173
1215856061 M * raphinou hi
1215858539 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1215859184 J * kuben ~chatzilla@dsl-240-149-81.telkomadsl.co.za
1215859498 P * kuben 
1215859632 Q * friendly Quit: Leaving.
1215863270 M * danman is it possible to limit the maximum memory usage of a vserver?
1215865219 J * lilalinux ~plasma@80.69.41.3
1215865500 M * phedny danman: yes, you can use either vlimit commandline tool to do so on the fly
1215865509 M * phedny danman: or you can set values in rlimit directory
1215865552 M * phedny http://linux-vserver.org/Resource_Limits
1215865575 M * phedny look at de rss setting
1215865723 J * duckx ~Duck@81.57.39.234
1215866348 N * Bertl_zZ Bertl
1215866352 M * Bertl morning folks!
1215866395 M * Bertl ruskie: how about adding it there then (maybe under Downloads)?
1215866502 M * Bertl danman: you need to setup rule based routing (multiple routing tables) if you really have separate default gateways (on the host)
1215867067 M * Bertl have to get some groceries ... bbl
1215867072 N * Bertl Bertl_oO
1215867675 Q * Mojo1978 Read error: Connection reset by peer
1215867729 M * danman phedny: thx
1215867740 M * danman Bertl: you mean ip rule ?
1215867750 M * danman is there any howto or sample stuff for this somewhere?
1215867758 M * danman (iproute2 I guess)
1215869235 J * Blissex ~Blissex@82-69-39-138.dsl.in-addr.zen.co.uk
1215870428 N * Bertl_oO Bertl
1215870452 M * Bertl danman: well, it's actually quite simple, you create a new routing table for your second network
1215870478 M * Bertl danman: you send all packets based on IP to that table (ip rule ... src ...)
1215870508 M * Bertl and that's it, make sure that the second table has proper routing for lo and whatever else you want to reach
1215870775 Q * Aiken Remote host closed the connection
1215872096 M * Bertl okay, off for now .. bbl
1215872101 N * Bertl Bertl_oO
1215872318 J * RenOS ~renos@athedsl-4392175.home.otenet.gr
1215872325 M * RenOS hello
1215872668 M * RenOS can I migrate guests from one physical machine to  another on the fly?
1215873017 M * danman Bertl_oO: thx very much
1215873018 M * danman !
1215874645 M * fosco hi
1215874719 M * fosco I have some issues with postfix+vda patch: setrlimit seems to be limited (postfix/cleanup[23173]: fatal: setrlimit: Operation not permitted)
1215874757 M * fosco is it some  capability to add, other then CAP_SYS_RESOURCE in /etc/vservers/*/bcapabilities ?
1215874984 M * fosco (I thinks it's a setrlimit(RLIMIT_FSIZE, ...) that's not working)
1215876433 M * Bertl_oO fosco: what kernel/patch?
1215876450 M * fosco 2.6.24.7-vs2.3.0.34
1215876656 M * Bertl_oO I'd suggest to update to a 2.6.25.x kernel, but you should be able to control the limits (hard/soft) from inside the guest (within the guest limits that is) or at least via the config
1215876682 M * Bertl_oO strace -fF should show you what it tries to raise
1215876698 M * fosco that will be tricky
1215877085 M * fosco (last time I tried, 2.6.25.x with vserver patches don't compile on sparc64)
1215877321 Q * raphinou Quit: Leaving
1215879702 Q * dna Ping timeout: 480 seconds
1215879702 M * Bertl_oO fosco: well, when mainline works on sparc64, and Linux-VServer does not, please just tell us, we'll fix it
1215880334 M * fosco ok, so here is a pastebin of the compilation error http://paste.geeknode.org/7tw3i9-4209
1215880346 M * fosco if I can help (testing, etc...)
1215880925 M * arachnist http://phpfi.com/331513 <| wtf?
1215881094 Q * lilalinux Remote host closed the connection
1215882660 J * opuk ~kupo@alla.beundrar.kupo.se
1215882982 J * dna ~dna@70-232-dsl.kielnet.net
1215883634 M * daniel_hozac arachnist: your yum/rpm seems to be broken.
1215883678 M * arachnist daniel_hozac: could it be that my host isn't yum/rpm-based?
1215883696 M * daniel_hozac that shouldn't matter as long as it works.
1215889423 J * docelic ~docelic@78.134.197.119
1215889459 Q * docelic 
1215890448 Q * fatgoose Ping timeout: 480 seconds
1215894224 M * Bertl_oO fosco: did you try with a mainline kernel (i.e. no patch)?
1215894680 M * fosco it compiles :)
1215894701 M * Bertl_oO ok, let me take a look at it .. will take a minute
1215894804 M * Bertl_oO looks like a hunk which got misapplied .. sec
1215894930 J * Piet ~piet@tor.noreply.org
1215895352 M * Bertl_oO fosco: okay, try vs2.3.0.34.13.1, there is a delta too in the usual location
1215895451 Q * Piet Ping timeout: 480 seconds
1215895757 M * fosco thank you :)
1215895779 M * fosco this part new compiles
1215895906 M * fosco and links
1215896048 J * Piet ~piet@tor.noreply.org
1215896081 M * Bertl_oO excellent, please let me know how it works, would be good to specifically test ptracing processes outside the current context
1215896097 M * Bertl_oO (should be handled, but you never know :)
1215896203 Q * dna Ping timeout: 480 seconds
1215896367 M * fosco the kernel is booting and my vservers are running
1215896481 M * RenOS well done!
1215896502 M * fosco (the "fatal: setrlimit: Operation not permitted" still present :)
1215896505 M * fosco yeah, thank you
1215896775 M * daniel_hozac what limit is it failing on? what utils are you using?
1215896792 M * fosco it's postfix with the VDA patch
1215896835 M * fosco (for quotas)
1215896870 M * fosco it's not that important, but I don't understand what I'm missing (I already have CAP_SYS_RESOURCE in the bcapabilities file)
1215896901 M * Bertl_oO daniel_hozac: seems to be file limits
1215896977 M * daniel_hozac and what does ulimit -HSf show? (in the shell executing the failing command)
1215897015 M * fosco the failing command is executed by postfix for the rcpt to validation
1215897237 M * fosco (I will be happy to strace it if Y knew how to :)
1215897306 M * fosco # grep setrlimit ./src/cleanup/cleanup.c | wc -l
1215897308 M * fosco 0
1215897317 M * fosco this one will be problematic
1215897366 M * daniel_hozac just strace -fF all of postfix.
1215897834 M * fosco strace -fF postfix start does not work :(
1215897897 Q * Blissex Remote host closed the connection
1215898126 M * daniel_hozac meaning?
1215898145 M * fosco meaning I can't "strace -fF all of postfix"
1215898329 M * daniel_hozac but in what way does it not work?
1215898779 Q * bonbons Quit: Leaving
1215898865 M * fosco like that http://paste.geeknode.org/kg06db-4228 :\
1215899349 M * fosco ok got it
1215899350 M * fosco setrlimit(RLIMIT_FSIZE, {rlim_cur=20480*1024, rlim_max=RLIM_INFINITY}) = -1 EPERM (Operation not permitted)
1215899351 Q * loddafnir Ping timeout: 480 seconds
1215899378 M * daniel_hozac so, what utils are you using?
1215899407 M * fosco a /usr/lib/postfix/strace.sh calling strace cleanup and used instead of cleanup in master.cf for service cleanup :)
1215899435 M * daniel_hozac what i meant was, what util-vserver version?
1215899514 M * fosco 0.30.212
1215899713 M * daniel_hozac that should do the right thing... but you might want to upgrade anyway.
1215899784 M * fosco maybe I missed a capability?
1215899893 Q * the_fafa Quit: the_fafa
1215901275 J * the_fafa ~fafa@p5496E8D0.dip.t-dialin.net
1215901277 J * ktwilight_ ~ktwilight@150.69-66-87.adsl-dyn.isp.belgacom.be
1215901552 Q * ktwilight Ping timeout: 480 seconds
1215901933 M * fosco no changes :)
1215901950 M * fosco I just removed the setrlimit call, for what it does... 
1215902112 M * fosco Bertl_oO: thank you for the sparc64 fix, really :)
1215902552 Q * RenOS Quit: later...
1215902665 J * Aiken ~james@ppp121-45-243-126.lns2.bne4.internode.on.net
1215903230 M * Bertl_oO fosco: my pleasure!
1215905095 Q * arthur Ping timeout: 480 seconds
1215905710 J * arthur ~arthur@pan.madism.org
1215906452 J * arthur_ ~arthur@pan.madism.org