1142990190 M * brc Does the scheduller add overhead? If there is just one vserver "processing", will the schedule takes out it's performance? 
1142990848 Q * mkhl Quit: 
1142990899 Q * coocoon Ping timeout: 480 seconds
1142991550 J * coocoon ~coocoon@p54A06787.dip.t-dialin.net
1142992793 N * Bertl_oO Bertl
1142992797 M * Bertl back now ...
1142992862 M * Bertl mugwump: what's the problem?
1142993153 M * mugwump Bertl: the new 7-piece patchset got eaten again.  I tried sending it from my e-mail address this time...
1142993166 M * mugwump I can't find the function on the vger site to find out what ate it
1142993249 M * mugwump I think Dave has a point with the kref thing, though
1142993317 M * Bertl sure, just never change a running system without good reason :)
1142993359 M * Bertl I probably can name 20 different things which are _not_ according to 'current' coding style
1142993401 M * Bertl ad lkml, let me do a few simple checks first 
1142993437 M * mugwump Bertl: well, why not comment on your own patch then :).  On the next round, anyway.
1142993445 M * mugwump Or even now
1142993571 M * Bertl well, thought about that, maybe I will ...
1142993634 Q * michal` Ping timeout: 480 seconds
1142993649 M * mugwump but it would be better if people could see what you're commenting on :)
1142993662 Q * FaUl Read error: Operation timed out
1142993691 M * Bertl mugwump: definitely, your domain is violating RFC 974
1142993734 A * mugwump whimpers
1142993760 M * mugwump I don't understand why my normal posts get through from the same mail server
1142993761 M * Bertl also your reverse does not match
1142993775 M * Bertl Received: from mail.utsl.gen.nz (watts.utsl.gen.nz [202.78.240.73])
1142993824 M * Bertl I wonder why my mailer accepts those actually :)
1142993929 M * mugwump ok, I've changed my mailhost to use watts.utsl.gen.nz as its mailname.  what's the RFC974 about?
1142993972 M * Bertl that mail/MX entries must not use CNAME, basically
1142993992 A * mugwump guhs
1142994019 M * mugwump that's retarded.  OK, I'll sort that out for the next one I guess
1142994060 A * mugwump wonders if it's something simpler, like a Content-Type: header, etc
1142994092 J * michal` ~michal@www.rsbac.org
1142994189 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1142994190 M * Bertl mugwump: but I think the main issue is the missing MX entry for watts
1142994214 M * Bertl mail->watts (which has no MX)
1142994247 M * mugwump right
1142994353 M * Bertl also check those: http://vger.kernel.org/majordomo-taboos.txt
1142994364 M * mugwump yeah, checked those already
1142994545 M * mugwump I can't even set that up with my DNS provider.
1142994561 M * mugwump looks like I'll have to transfer
1142994704 M * Bertl hmm, no MX records?
1142994794 M * mugwump not on anything but @, it seems
1142994813 M * doener Bertl: hm, where does it say that the MX may not be a CNAME?
1142994857 M * mugwump RFC974?
1142994877 M * doener yeah, but where in that document?
1142994942 M * mugwump I think I'll try a binary search with that and what my normal mailer uses.  It's going through the same server, surely it's something simple...
1142995032 M * Bertl doener: well, I went through this some time ago, as far as I can remember it was something along those lines:
1142995064 M * Bertl if the mta gets an cname, then redo the MX query with the domain pointed to
1142995089 M * Bertl but if the MX entry basically is a cname, this is recursive
1142995093 M * doener ehrm, forget it, i've been confusing a lot of things...
1142995141 M * mugwump surely it's not resolving an MX by that point, though
1142995155 M * mugwump it's just looking up a host...
1142995160 M * Bertl no, but many spam filters do MX checks
1142995243 M * Bertl ah, I found where I started :) http://www.sendmail.org/~ca/email/setup1.html
1142995294 M * Bertl second paragraph under Please use MX Records :)
1142995471 M * doener yeah, my fault is best expressed by the fact that I said "MX may not be a CNAME"... of course a MX is not a CNAME, it just happens to look similar ;)
1142995705 M * doener Bertl: hm, about watts.... not having an MX record. that is only an issue if mail is addressed to foo@watts... isn't it?
1142995734 M * Bertl yep, that's why I said: 'many spam filters do MX checks'
1142995772 M * doener ah, ok... i'm still hanging in the first part of the discussion *g*
1142996428 M * doener anyway, I'm off to bed... good night!
1142996430 Q * doener Quit: leaving
1143001147 M * mugwump hmm, guess it was mailname thing
1143001193 M * Bertl well, said that last time, no?
1143001279 M * mugwump I tried it with a subscribed address this time...
1143001331 M * mugwump hopefully the next, kref-enabled, hash removed (was there another reason for the hashing?) patch will make it through
1143001337 M * mugwump after I finish it :^)
1143001358 M * Bertl which hashing?
1143001366 M * mugwump the vx_info objects
1143001379 M * Bertl well, how will you find them?
1143001423 M * mugwump I'll have to add them back in later when there is something that needs lookup by XID to be fast.
1143001429 M * Bertl (if you do not hash them)
1143001480 M * Bertl are you sure you understand what the purpose of the claim/release and hash/unhash stuff is?
1143001481 M * mugwump only stuff that gets it via the task_struct ,initially
1143001508 M * mugwump I tried to document my understanding as best I could
1143001522 M * mugwump claim/release is task refcount iirc
1143001531 M * mugwump put/get is normal refcnt
1143001537 M * mugwump (which will become kref)
1143001556 M * mugwump hashing means that it has been created and is ready to have processes put in it, and can be looked up by XID
1143001560 M * mugwump is that all right?
1143001569 M * Bertl yes, the important part here is that there can be several vx_info structs with the _same_ xid
1143001579 M * mugwump oh
1143001617 M * Bertl because the task reference controls the visibility, but certain structs could hold references for much longer
1143001674 M * mugwump so, can those processes that share a vx_info but not an XID, can they see each other's processes?
1143001714 M * Bertl that cannot happen in the current design
1143001732 M * Bertl look, it works like this:
1143001751 M * Bertl 1. context is created (maybe in setup state)
1143001770 M * Bertl   (only the setup process is part of the context and sees it)
1143001783 M * Bertl 2. after setup, the context becomes 'visible'
1143001806 M * Bertl 3. the context can be entered or manipulated
1143001822 M * Bertl 4. the last process dies, and it becomes _invisible_
1143001835 M * Bertl 5. the last reference is given up and it is disposed
1143001862 M * Bertl _all_ access to contexts happens via xids and requires visibility
1143001993 M * mugwump all access via syscalls?  internal kernel things can just follow ->vx_info, no?
1143002028 M * Bertl yes, but it is very important that nothing claims a vx_info once it is unhashed
1143002072 M * mugwump this is precisely what I need to know, I am currently kind of glossing over this
1143002102 A * mugwump waits for the "no kidding" response :)
1143002188 M * Bertl no kidding?! :)
1143002268 M * mugwump well, I didn't write tests for those parts yet, eg to check the destruction stuff works
1143002285 M * mugwump so my understanding is not yet as comprehensive as I like
1143002289 Q * lilo Quit: leaving
1143002295 M * mugwump I was hoping this wasn't too obvious :)
1143002307 J * lilo ~lilo@lilo.usercloak.oftc.net
1143002337 M * Bertl mugwump: well, it seems at least the ibm folks take you very serious :)
1143002356 M * mugwump also Kirill thanked me for CC'ing him
1143002369 M * mugwump and promised to comment
1143002407 M * Bertl I'm looking forward to those comments ...
1143002606 M * Bertl mugwump: btw, if you can provide patches against 2.1.1 to switch to kref/kobject I'm willing to test those and put them into the next devel release
1143002649 M * mugwump I guess that won't be hard once I've done and tested it
1143002679 M * Bertl just wanted to let you know ...
1143002801 M * mugwump care to be the first (other than myself) to pick from my selection of 'vx_info' alternatives?
1143002878 M * mugwump dev_: if you're around, can you also pick your favourites?  http://lkml.org/lkml/2006/3/21/457
1143002878 M * Bertl nah, I like vx_info :) maybe vx_space lateron :)
1143002900 M * mugwump I have to agree with Dave that "vx" doesn't offer any meaning, though
1143002925 M * Bertl yeah, but virtual context is much too long :)
1143002946 M * mugwump I especially like family_adopt_task
1143002965 Q * lilo arion.oftc.net testlink1.oftc.net
1143002965 Q * mountie arion.oftc.net testlink1.oftc.net
1143002965 Q * gerrit arion.oftc.net testlink1.oftc.net
1143002965 Q * click arion.oftc.net testlink1.oftc.net
1143002965 Q * alexx arion.oftc.net testlink1.oftc.net
1143002965 Q * yang arion.oftc.net testlink1.oftc.net
1143002965 Q * Wonka arion.oftc.net testlink1.oftc.net
1143002965 Q * k3mper arion.oftc.net testlink1.oftc.net
1143002965 Q * cehteh arion.oftc.net testlink1.oftc.net
1143002965 Q * lonewolff arion.oftc.net testlink1.oftc.net
1143002965 Q * SNy arion.oftc.net testlink1.oftc.net
1143002965 Q * Greek0 arion.oftc.net testlink1.oftc.net
1143002975 J * derjohn ~derjohn@80.69.37.19
1143002977 M * Bertl well, vx_info is not just task related ...
1143003004 J * click click@ti511110a080-3151.bb.online.no
1143003060 J * lilo ~lilo@lilo.usercloak.oftc.net
1143003060 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1143003060 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net
1143003060 J * cehteh foobar@cehteh.homeunix.org
1143003060 J * lonewolff lonewolff@adleman.lonewolff.info
1143003060 J * Greek0 ~greek0@85.255.145.201
1143003060 J * yang ~yang@cpe-213-157-253-172.dynamic.amis.net
1143003060 J * alexx ~alexx@proxy.ikse.net
1143003060 T * xenon.oftc.net http://linux-vserver.org/ | latest stable 2.01, 1.2.10, 1.2.11-rc1, devel 2.1.0, exp 2.{0.2,1.1}-rc13 | util-vserver-0.30.210 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;)
1143003063 Q * yang Ping timeout: 480 seconds
1143003084 Q * alexx Ping timeout: 480 seconds
1143003098 Q * gerrit Ping timeout: 480 seconds
1143003188 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net
1143003207 J * alexx ~alexx@proxy.ikse.net
1143003286 J * k3mper ~maio@mail.progamers.cz
1143003320 M * Bertl mugwump: btw, the VCI is not legacy, it's almost brand new :)
1143003324 J * yang ~yang@cpe-213-157-253-172.dynamic.amis.net
1143003390 M * mugwump yes of course, the design is - but I was surprised at the stort name
1143003394 Q * cehteh Ping timeout: 480 seconds
1143003404 M * mugwump the VCI_ prefix
1143003445 J * Snoop w00w00@ool-45789464.dyn.optonline.net
1143003446 J * SNy 5fed69e165@bmx-chemnitz.de
1143003449 P * Snoop 
1143003490 J * Wonka produziert@chaos.in-kiel.de
1143003500 M * Bertl well, there are certain cases where I simply chose to reduce the number of chars in an abbreviation
1143003575 M * Bertl especially when VX would meet XYZ or so
1143003668 M * mugwump Well, I'll leave the constants in that file as is until someone specifically objects, I guess
1143003683 M * mugwump or maybe it doesn't matter?
1143003712 M * mugwump they're just symbols after all.  Heck, the names of the include files will change so there's not a problem
1143003748 M * mugwump libvserver et al will need to autoconf those and use #ifdef's, but that's a small price to pay for merging
1143003780 M * Bertl well, the vx_ doesn't mean anything reply makes me wonder if vfs_ has more meaning :)
1143003841 M * mugwump I don't like the container term.  it makes it sound like we stole their feature :)
1143003897 M * Bertl well, Eric suggested space as general term and *_space as specific term
1143003922 M * mugwump space ... not bad, nice and short
1143003931 M * Bertl so filling in the '*' would be a good idea, keeping it short, even better
1143003933 Q * lonewolff arion.oftc.net testlink1.oftc.net
1143003933 Q * mountie arion.oftc.net testlink1.oftc.net
1143003933 Q * Greek0 arion.oftc.net testlink1.oftc.net
1143003933 Q * lilo arion.oftc.net testlink1.oftc.net
1143003965 M * Bertl not that I really care about the names, never did ...
1143004112 M * mugwump I don't think it works.
1143004121 M * mugwump eg, create_space()
1143004124 M * mugwump lookup_space()
1143004130 M * mugwump would have to be, perhaps
1143004134 M * mugwump create_task_space()
1143004428 M * mugwump actually create_space() looks OK
1143004629 J * lilo ~lilo@lilo.usercloak.oftc.net
1143004629 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1143004629 J * lonewolff lonewolff@adleman.lonewolff.info
1143004629 J * Greek0 ~greek0@85.255.145.201
1143004993 Q * lonewolff arion.oftc.net testlink1.oftc.net
1143004993 Q * mountie arion.oftc.net testlink1.oftc.net
1143004993 Q * Greek0 arion.oftc.net testlink1.oftc.net
1143004993 Q * lilo arion.oftc.net testlink1.oftc.net
1143005239 J * lilo ~lilo@lilo.usercloak.oftc.net
1143005391 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1143005391 J * lonewolff lonewolff@adleman.lonewolff.info
1143005391 J * Greek0 ~greek0@85.255.145.201
1143005925 J * cehteh foobar@cehteh.homeunix.org
1143006039 Q * lonewolff arion.oftc.net testlink1.oftc.net
1143006039 Q * mountie arion.oftc.net testlink1.oftc.net
1143006039 Q * Greek0 arion.oftc.net testlink1.oftc.net
1143006183 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1143006183 J * lonewolff lonewolff@adleman.lonewolff.info
1143006183 J * Greek0 ~greek0@85.255.145.201
1143008352 M * Bertl k, I'm off to bed now ... back tomorrow!
1143008360 M * Bertl have a good one everyone!
1143008364 N * Bertl Bertl_zZ
1143008421 J * coocoon ~coocoon@p54A062BB.dip.t-dialin.net
1143008429 M * coocoon morning to all
1143009337 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1143010089 J * coocoon ~coocoon@p54A062BB.dip.t-dialin.net
1143011452 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1143011804 Q * ddlp Quit: leaving
1143012056 J * ddlp ~ddlp@sarayi.kariva.org
1143012144 Q * lilo Quit: bbiab
1143012715 J * lilo ~lilo@lilo.usercloak.oftc.net
1143012760 Q * harry Ping timeout: 480 seconds
1143014054 J * NET NET@194.141.50.197
1143014060 M * NET morning all
1143014558 J * harry ~harry@d54C2508C.access.telenet.be
1143014654 Q * yang Ping timeout: 480 seconds
1143015347 J * coocoon ~coocoon@p54A062BB.dip.t-dialin.net
1143015397 Q * shedi Quit: Leaving
1143015676 M * dev_ mugwump, Bertl: what is the reason to use krefs? :) this sucks :)))
1143016378 M * coocoon dev_:  openVZ will now everytime have the latest kernel or only u have implemented it because of I20 issue
1143016552 M * dev_ coocoon: which i2o issue? we do support i2o and update drivers for it even in 2.6.8. latest kernel? I'm not sure... when we select another kernel for stabilization, it can be freezed
1143016560 J * Dr4g ~Dr4g@82-40-44-47.cable.ubr06.uddi.blueyonder.co.uk
1143016647 J * cryo ~say@psoft.user.matrix.farlep.net
1143016707 M * coocoon dev_: i have read this therefore i am asking http://forum.openvz.org/index.php?t=rview&goto=2135&th=374#msg_2135
1143016965 M * Hollow Bertl_zZ: could you please update VCI_VERSION in 2.1.*?
1143016984 M * dev_ "I just realized that CONFIG_SCSI_DPT_I2O was not compiled into the openvz kernel while it was compiled into the running kernel - might have been my own stupidity all along."
1143017011 M * dev_ coocoon: i2o is working in 2.6.8. we have the same driver as in RHEL4
1143017033 M * coocoon dev_: ah ok, have never had problems with that, what could happen?
1143017104 M * dev_ what do you mean by what? a guy just recompiled our kernel without I2O config option :)
1143017140 M * coocoon dev_: oh aha "shit happens"
1143017147 M * coocoon ;-)
1143017365 Q * NET Quit: Leaving
1143017535 M * dev_ sure :) it is possible to make shit in many other ways. e.g. compile w/o elf support :)
1143017802 M * harry anyone into networking/advanced routing with iproute2 ?
1143017903 M * harry         ip route add default via 134.58.10.63 dev eth0 table 134.58.10-net
1143017915 M * harry RTNETLINK answers: Network is unreachable
1143017921 M * harry which... off course, is normal
1143017943 M * harry since that interface does not have an ip on that network on that interface
1143017977 M * harry but i do not care!!! i just want that, IF i have an ip there, it will be routed to that gw
1143018023 M * harry so IF i have an ip in 134.58.10.0/26 defined on eth0, it should be routed to 134.58.10.63 if it wants out
1143018025 M * coocoon harry: mayybe this http://linux-vserver.org/Linux-Vserver+FAQ on 10 will help
1143018099 M * harry coocoon: how will that help?
1143018108 M * harry i don't have any vservers running atm
1143018124 M * harry i just want all routing to be good, for when i start/add vserver instances
1143018129 M * coocoon harry: oh i thought which distribution redhat
1143018145 M * coocoon ?
1143018156 M * harry what's a distribution got to do with routing???
1143018176 M * coocoon with the ror message
1143018231 M * harry ???????
1143018328 M * Hollow harry: so, you want to set a default gateway, right?
1143018334 Q * eyck Ping timeout: 480 seconds
1143018339 M * harry Hollow: i want to set more default gw's
1143018374 M * Hollow well, default implies only one
1143018384 M * harry no it doesn't
1143018393 M * harry not in advanced routing :)
1143018400 M * Hollow well, you can't have two defaults
1143018405 M * harry yes you can :)
1143018411 M * harry let me explain :)
1143018433 M * Hollow maybe you can have two gateways, but just language-wise, default implies one ;)
1143018437 M * harry if i have a vps with an ip in the range: 134.58.10.0/26, i want its default gw to be 134.58.10.63 on eth0
1143018452 M * harry if i have a vps with an ip in the range: 10.33.113.0/24, i want its default gw to be 10.33.113.254 on eth0
1143018468 M * harry if i have a vps with an ip in the range: 192.168.28.0/23, i want its default gw to be 192.168.29.254 on eth0
1143018472 M * harry if i have a vps with an ip in the range: 192.168.28.0/23, i want its default gw to be 192.168.29.254 on eth1
1143018475 M * harry sry :)
1143018494 M * Hollow yeah, but you still have one gateway... (per subnet)
1143018505 M * harry one default gw per subnet, yes
1143018520 M * harry there can only be 1 default per subnet :)
1143018522 M * Hollow that's what i wanted to say ;)
1143018529 M * harry then say that :)
1143018534 M * harry :p
1143018550 M * harry BUT, the problem is, the host only has 1 real ip, on eth1 in 192.168.28.0/23
1143018558 M * harry the others are only for vps'es
1143018578 M * harry so there is not always a route....... damn you fucking lag!
1143018583 M * Hollow well, you manage all adresses on the host anyway, they network stck is not virtualized
1143018586 M * harry ah, we're back :)
1143018595 M * harry true
1143018615 M * harry but , if the vps is down, the interface (virtualized) should go down
1143018626 M * Hollow which interface? eth0?
1143018630 M * harry but if that one goes UP again, the routing should still work
1143018647 A * harry uploads his routing script... sec...
1143018670 M * Hollow why would any interface go down on vps stop?
1143018674 M * Hollow sounds strange
1143018687 M * harry http://pastebin.com/615799
1143018693 M * harry Hollow: it doesn't
1143018700 M * harry just read the start part of the script...
1143018738 M * harry like i said: the virtualized interface should go down (so the alias removed)
1143018766 M * Hollow oh, you're using aliases
1143018769 M * Hollow Bad Thing (tm)
1143018773 M * harry ahm... 
1143018777 M * harry vserver uses aliases
1143018787 M * harry don't you use vserver?
1143018788 M * Hollow no, util-vserver uses it unfortunately
1143018808 M * harry is there another way?
1143018810 M * Hollow as a workaround for broken ifconfig
1143018812 M * Hollow yep
1143018835 M * harry ah?
1143018836 M * Hollow use the iproute2 method for util-vserver (i.e. don't configure name in /etc/vservers/foo/interfaces/X/)
1143018847 M * Hollow => no aliases will be created
1143018858 M * harry then what will be created?
1143018866 M * Hollow the ip will just get added to eth0 like "ip addr add ... dev eth0"
1143018883 M * Hollow it now is a secondary address for eth0
1143018912 M * harry gandalf:/usr/local/etc/vservers/ftpserv/interfaces/0# for i in *; do echo $i; cat $i; done
1143018915 M * harry dev
1143018918 M * harry eth0
1143018920 M * harry ip
1143018923 M * harry 10.33.113.203
1143018925 M * harry prefix
1143018928 M * harry 24
1143018931 M * harry smth like that?
1143018936 M * Hollow yep
1143018957 M * harry that's how i do it, yes :)
1143018959 M * Hollow i even prefer to configure all IPs statically on the host and echo > interfaces/0/nodev
1143018982 M * harry Hollow: fyi: > interfaces/0/nodev
1143018982 M * Hollow so, util-vserver does nothing but limit the configured subset of ipadresses
1143018984 M * harry it's shorter ;)
1143018990 M * Hollow wayne :p
1143019020 M * harry Hollow: what if the vps goes down?
1143019037 M * harry what will happen with the secondary addresses?
1143019037 M * Hollow nothing happens to the ip configuration => very good :D
1143019046 M * harry so it will still be "up" ?
1143019073 A * harry doesn't want that, if i shut down a vps, it should be down :)
1143019084 M * harry and stay down! :)
1143019098 M * Hollow i always have configured all ip adresses on the host, no matter if the vps is up or not
1143019098 M * Hollow so my init scripts on the host take care of everything, and not util-vsevrer *bah*
1143019114 M * Hollow well, it makes no difference
1143019129 M * Hollow there is nothing to listen on that ip, so why should i care
1143019133 M * harry that's what i want too... but i want vserver to put the ip addresses up or down if the vps goes up/down
1143019138 M * harry but routing should allways be good
1143019142 M * Hollow then skip nodev
1143019156 M * Hollow and skip name as well
1143019157 M * harry i will :) but i still need to get this routing shit working :)
1143019159 M * Hollow should be fine then
1143019183 M * harry e.g. now, i don't have any addresses on eth0 in 134.58.10.0/23
1143019189 M * Hollow well, if you configure the routing on eth0 which will always be up, the routing should not get lost
1143019191 M * harry so         ip route add default via 134.58.10.63 dev eth0 table 134.58.10-net
1143019194 M * harry gives me:
1143019201 M * harry RTNETLINK answers: Network is unreachable
1143019208 M * harry which is normal
1143019209 M * Hollow well, i guess you have to give the host an adress in the network too
1143019217 M * harry i don't want that :)
1143019230 M * Hollow hm, then your routs get lost i guess
1143019240 M * harry i don't want that either :)
1143019266 M * Hollow you cannot always get what you want :P
1143019279 M * Hollow you should have learned that in the age of 2-6 :P
1143019283 M * harry i just don't care if there is an ip on that interface, just, IF there is a packet arriving on that if, with source there, it should be routed to ....
1143019295 M * harry Hollow: it's linux... i can get what i want ):
1143019295 M * harry ;)
1143019308 M * harry just have to figure out how :)
1143019313 M * Hollow i'm not a routing expert, maybe there are ways to do it..
1143019354 M * coocoon harry: me too, sorry for my diffuse try
1143019400 M * harry hm... /me looks further, tnx anyway all :)
1143019506 J * shedi ~siggi@tolvudeild-198.lhi.is
1143019883 J * EKC ~EKC@netblock-66-245-252-180.dslextreme.com
1143020093 M * EKC Hi, I've got a question about getting testme.sh to work
1143020096 M * EKC When I run testme.sh on a fresh install of Vserver 2.1.1-rc13 on a 2.6.16 kernel, I keep getting: "chcontext failed!";
1143020125 M * EKC I've been recompiling the kernel with different .config options, and I can't seem to get testme.sh to work.
1143020191 Q * cryo Read error: Connection reset by peer
1143020236 M * coocoon EKC: hm maybe dynamic context enabled in the lernel, u have tried it with deactivating this option in the kernel
1143020249 M * coocoon -l +k
1143020300 M * EKC yup, I have vserver_dynamic_ids=y. I will disable it and recompile. Good call.
1143020319 M * daniel_hozac that will not make testme _fail_.
1143020350 M * daniel_hozac what utils are you using?
1143020373 M * EKC I'm using util-vserver-0.30.210
1143020429 M * EKC My testme.sh output is: Linux-VServer Test [V0.04] (C) 2003-2004 H.Poetzl;   chcontext failed!;   chbind is working.
1143020443 M * EKC ipv4root is now 127.0.0.1 ipv4root: 0100007f/00ffffff ipv4root_bcast: ffffffff
1143020450 M * daniel_hozac you might want to update to the latest testme.
1143020450 M * EKC Linux 2.6.16-rc5-vs2.1.1-rc13 i686// [J]
1143020460 M * daniel_hozac version 0.15.
1143020496 J * eyck eyck@195.242.124.71
1143020517 M * EKC oh! I thought I was using the latest. oops. I'll try that now.
1143020711 M * EKC Can't seem to find testme.sh 0.15. Where is it kept?
1143020802 M * daniel_hozac http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh
1143020819 M * daniel_hozac http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh-0.15 to be exact.
1143020835 M * EKC Nevermind. Got it at http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh; and it's working; thanks for helping
1143020862 M * EKC yup
1143020884 Q * michal` Ping timeout: 480 seconds
1143020909 M * EKC One more thing. I created a new vserver using debootstrap. It starts and runs fine. 
1143020968 M * EKC I used vhashify on that vserver. Then, I used vcopy to clone it. When I try to start the clone, I get: "No command given... An error occured while executing the vserver starup sequence"
1143021013 M * EKC error message continues: "it's very likely that the init-script() failed" "common causes are: /etc/rc.d/rc on Fedora Core 1 and RH9 fails always"
1143021026 M * EKC however, I'm running debian (both on the host and in the vserver)
1143021092 M * daniel_hozac does the new guest have /etc/rc.d/rc or /etc/init.d/rc?
1143021312 J * michal` ~michal@www.rsbac.org
1143021528 M * EKC No, you're right. The new guest is missing /etc/rc.d/. It seems vhashfiy or vcopy excluded the startup scripts.
1143021702 M * EKC Ok. Problem solved. I was using 'vcopy --strict'. It's working now when I remove '--strict'. I was trying to use vcopy to copy onto a vserver skeleton
1143021784 M * EKC thanks again.
1143022374 Q * cehteh Remote host closed the connection
1143022839 Q * EKC Ping timeout: 480 seconds
1143023106 J * EKC ~EKC@netblock-66-245-252-180.dslextreme.com
1143023321 J * cehteh foobar@cehteh.homeunix.org
1143023785 Q * EKC Ping timeout: 480 seconds
1143023816 J * EKC ~EKC@netblock-66-245-252-180.dslextreme.com
1143024378 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl
1143024829 Q * EKC Ping timeout: 480 seconds
1143026269 J * lilalinux ~plasma@dslb-084-058-203-082.pools.arcor-ip.net
1143027455 J * Smutje_ ~Smutje@xdsl-87-78-7-13.netcologne.de
1143027564 Q * Smutje Ping timeout: 480 seconds
1143027564 N * Smutje_ Smutje
1143028119 Q * Aiken Ping timeout: 480 seconds
1143028211 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1143028376 J * coocoon ~coocoon@p54A062BB.dip.t-dialin.net
1143028925 Q * eyck Ping timeout: 480 seconds
1143029730 J * eyck eyck@195.242.124.71
1143030157 J * cryo ~say@psoft.user.matrix.farlep.net
1143031673 J * Balu ~Derersdee@dslb-084-056-130-032.pools.arcor-ip.net
1143031691 M * Balu servus
1143031918 Q * Balu Quit: Verlassend
1143032711 M * brc does anyone know if da, cpanel or plesk would work on linuix-vserver (kernel 2.6) ?
1143032780 A * phedny only knows he's working on his own control panel with vserver support :)
1143033705 M * Hollow no, doesn't work
1143033721 M * Hollow phedny: interesting, we're planing such a thing too, anything to look at
1143033766 M * brc Hollow: none of them ? :(
1143033774 M * Hollow brc: right
1143033780 M * brc Well there is already SYSCP which works on linux-vserver
1143033787 M * Hollow hm
1143033793 M * brc i've read someowhere that plesk works on virutozzo which has much more limitations, so i though it would work
1143033822 M * Hollow much more limitations?
1143033861 M * brc i've read somewhere. never used virtuzzo so i dunno
1143033866 M * phedny Hollow: primarilly it's a project for my new (and small) hosting company, but I might consider releasing parts of it somehow
1143033874 M * Hollow hm.. i can't find anything about syscp with vserver support
1143033889 M * phedny Hollow: at the moment it's only a design and a first bit of code
1143033896 M * brc it does not need ot have vserver support, it is just a hosting contorl panel that works on linux-vserver
1143033906 M * phedny Hollow: it is however designed for flexibility, security and scalability
1143033910 M * Hollow well, yeah..
1143033918 M * Hollow we're talking about different things then i guess
1143033923 M * brc sure
1143033925 M * brc do you know cpanel ?
1143033934 M * brc hosting controle panel: cpanel, plesk, directadmin
1143033946 M * Hollow no, i don't use any of them
1143033948 M * brc that is what i am talking about. and i think that phedny is talking about that too :)
1143033954 M * Hollow i do administration via ssh
1143033965 M * brc clients can't do administration via ssh :)
1143033975 M * Hollow that's why they get vservers, haha
1143034002 M * Hollow ok, just trolling..
1143034038 M * phreak`` Bertl_zZ: I've finshed that changes needed for current git, you'll find a patch (http://dev.gentoo.org/~phreak/vserver/2.6.17-git/vs2.0.2-rc13-incr.diff) and the output of testme.sh & testfs.sh (both logs are in http://dev.gentoo.org/~phreak/vserver/2.6.17-git/)
1143034086 M * daniel_hozac god damn. i think i'll have to disable Xen kernels for future builds.
1143034094 J * _mcp ~hightower@wolk-project.de
1143034095 M * daniel_hozac 16 hours per kernel build just doesn't work for me.
1143034102 M * Hollow heh
1143034109 M * phedny Hollow: then what were you talking about?
1143034118 M * phreak`` daniel_hozac: *shrug* yeah, would be better disabling it ;)
1143034127 M * phedny brc: if you're interested in my project, I can inform you when I've got something you may look at
1143034151 M * Hollow i was talking about a webinterface to manage vservers, brc was talking about a webinterface to manage a LAMP or similar on a vserver
1143034160 M * brc phedny: do you have a demo or screenshots ? have you tried commercial contorl panels inside vserver ?
1143034180 M * phedny brc: owh, you mean a control panel *inside* a vserver?
1143034188 M * brc Hollow: that's it! Btw, i am creating some webinterface to manage vservers
1143034197 M * brc it's used in my "isp"
1143034201 M * brc already works
1143034204 M * brc in production
1143034221 M * Hollow great that everyone does his own thing, and noone consolidates with each other...
1143034221 A * phedny is working on a system that is able to both manage vservers and services offered inside these vservers
1143034224 M * Hollow </irnoy>
1143034229 M * Hollow irony even
1143034233 M * brc hehhe
1143034241 M * brc will be consolidated when it gets time
1143034247 M * daniel_hozac yeah, everyone seems to be making their own interface and noone is releasing it..
1143034248 M * phedny so client can start / stop / reboot vservers from the same control panel they use to create mailboxes and register domains
1143034254 M * brc not ready yet 
1143034258 Q * mcp Read error: Connection reset by peer
1143034262 M * Hollow daniel_hozac: exactly... that's now how open-source works imo
1143034266 M * brc phedny: that would be nice
1143034267 M * daniel_hozac release early, release often.
1143034271 M * Hollow *nod*
1143034280 M * phedny I have nothing to release
1143034303 M * phedny only a small program that may accept commands from the Management Server, but doesn't implement any command yet
1143034328 M * daniel_hozac FYI, i'm working on patches to util-vserver to make the configuration easier to change/create etc.
1143034345 M * Hollow reading tip: http://www.samspublishing.com/articles/article.asp?p=23200&seqNum=3
1143034352 M * Hollow about open development and such
1143034358 M * Hollow daniel_hozac: interesting..?
1143034406 M * daniel_hozac i've had to put that on a hold a bit though, with FC5 getting released.
1143034432 M * Hollow i mean.. what do the patches?
1143034494 M * daniel_hozac well, the current patches just let you do vserver ... config <any options available to build>.
1143034495 M * Hollow daniel_hozac: btw, i removed all the diet stuff from v-u so the user can decide whether to use diet or not
1143034506 M * Hollow ah, that sounds nice
1143034520 M * daniel_hozac it also has a rename capability.
1143034572 M * daniel_hozac but i talked to Enrico, and he wanted me to change a few things, so i'll do that first.
1143034591 M * daniel_hozac (http://daniel.hozac.com/vserver/vserver-config.functions)
1143034628 Q * cehteh Remote host closed the connection
1143034681 J * cehteh foobar@cehteh.homeunix.org
1143035475 M * coocoon Hollow: daniel_hozac: why not making such a projekt where to administer linux-vserver, maybe inside webmin
1143035485 M * Hollow uah
1143035487 M * Hollow webmin
1143035488 M * Hollow :)
1143035495 M * coocoon it is open source
1143035510 M * coocoon no design must be done
1143035511 M * daniel_hozac just because it's open source doesn't mean you want to touch it :)
1143035525 M * daniel_hozac or even poke it with a stick.
1143035528 M * Hollow well, if we do it (and i already have 3 people doing it for vserver-utils this year) it should be usable for customers as well
1143035532 M * Hollow and webmin is not that
1143035543 M * coocoon oh aha
1143035615 M * coocoon but which language suggest for managing util-ververs
1143035620 M * Hollow we'll have a meeting next month or so, i'll announce it, since it's request by many users
1143035629 M * Hollow it will be xmlrpc
1143035673 M * Hollow and don't confuse util-vserver with vserver-utils..
1143035706 M * daniel_hozac Hollow: weren't you doing pluggable configuration modules for vserver-utils?
1143035739 M * Hollow well, the code for the commands does not change that much
1143035834 M * coocoon hollow: have i make the confusion or what do u mean witht that "and don't confuse util-vserver with vserver-utils"
1143035856 M * Hollow <coocoon> but which language suggest for managing util-ververs
1143035862 M * Hollow i am talking about vsevrer-utils
1143035866 M * Hollow *vserver-utils
1143035903 M * coocoon oh sory i meant util-vserver but better is linux-vserver right?
1143035975 M * Hollow linux-vserver is the name of the project
1143035984 M * Hollow the other two are userspace implementations
1143035986 M * Hollow for the kernel api
1143036031 M * coocoon yes i meant linux-vserver, sorry for confusing
1143036033 M * coocoon ;-)
1143036071 M * daniel_hozac Hollow: what language are you going to write it in?
1143036082 M * Hollow what exactly?
1143036112 M * daniel_hozac the management interface.
1143036119 M * Hollow php?
1143036136 M * daniel_hozac ah.
1143036804 M * brc lemmeask my doubt again now that we have lot of ppl here. does anyone know if cpanel or da or plesk worn inside linux-vserver ?
1143036812 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1143037175 M * coocoon hollow: which experiences have the people make. is webmin to complexly for normal users
1143037268 M * coocoon made
1143037344 J * serving ~serving@194.165.154.16
1143037430 M * phedny brc: I see no reason why it wouldn't work. You might want to request a demo version to try out yourself
1143037435 Q * serving- Ping timeout: 480 seconds
1143037541 J * Roey ~katz@h-69-3-4-130.mclnva23.covad.net
1143037727 M * brc phedny: that is what i am doing. it wont work if they use quota's or need iptables to monitor traffic usage
1143037792 Q * daniel_hozac Quit: vserver kernel
1143037811 N * Bertl_zZ Bertl
1143037816 M * Bertl morning folks!
1143037852 M * coocoon morning bertl
1143038011 M * Soekris monring
1143038155 M * Roey Bertl:  so what's new with vserver since last we spoke?
1143038165 M * Roey Bertl:  btw, good morning!
1143038222 M * Bertl Roey: hmm, wasn't that yesterday or so? :)
1143038279 M * Roey perhaps :)?
1143038343 M * Bertl well, maybe the 2.6.16 version is new for you :)
1143038478 M * Hollow morning Bertl!
1143038484 M * Roey Bertl:  aye!
1143038563 J * daniel_hozac ~daniel@c-2d1472d5.010-230-73746f22.cust.bredbandsbolaget.se
1143038599 M * brc BERTL! Good morning :)
1143038740 J * doener ~doener@i5387DC60.versanet.de
1143038818 M * Roey daniel, doener, hi!
1143038838 M * doener morning #vserver
1143038848 M * coocoon hello doener
1143039571 M * daniel_hozac # vserver test build -m yum --context 7000 --hostname test.local --interface eth0:192.168.101.170/24 -- -d fc5
1143039571 M * daniel_hozac rpm-fake.so: vc_set_vhi_name(): Function not implemented
1143039573 M * daniel_hozac ideas?
1143039635 M * daniel_hozac vuname works fine, testme succeeds.
1143039701 M * Hollow daniel_hozac: maybe you call it inside a context?
1143039706 M * Hollow or it is called..
1143039707 M * Hollow however
1143039752 M * coocoon got yesterday the same error
1143039770 M * coocoon but my fault was not setting context
1143039787 M * daniel_hozac i haven't touched rpm-fake*, and it works fine on FC4.
1143040065 M * daniel_hozac and if it's called inside a context, it should get EPERM, no?
1143040393 M * Bertl daniel_hozac: arch?
1143040403 M * daniel_hozac i686.
1143040432 M * coocoon maybe the servers has too much traffic???????
1143040440 M * daniel_hozac which servers?
1143040452 M * coocoon u do not use repo
1143040467 M * coocoon s
1143040496 M * daniel_hozac i have a local mirror.
1143040516 M * daniel_hozac but the error happens way before any of that gets involved.
1143040517 M * coocoon oh ok
1143040638 M * Bertl daniel_hozac: 2.1.1 or 2.0.2?
1143040654 M * daniel_hozac 2.6.16-1.2064_FC5.vs2.0.2.0.rc13.1
1143041079 M * Bertl syscall number is correct, I presume?
1143041117 M * daniel_hozac yep.
1143041130 M * Bertl well, the kernel does not return that ...
1143041139 M * daniel_hozac i agree.
1143041147 M * Bertl would be interesting to enable debugging and turn on the switch debug
1143042305 Q * teukka Read error: Connection reset by peer
1143042384 J * teukka ~tmatilai@backport.ri.fi
1143042601 M * Bertl wb teukka!
1143043176 M * Bertl okay, back later ... have fun!
1143043181 N * Bertl Bertl_oO
1143043217 Q * shedi Quit: Leaving
1143043936 P * ddlp 
1143044732 J * KLFMANiK ~mann@people.uvt.tuke.sk
1143044915 M * KLFMANiK Hello ... i'm using quota on single partition and it works fine (kernel 2.6.15.6 + vserver 2.0.x) ... i have partition /dev/sdaX ... but now i'm trying to setup quota on another machine with SW RAID ... and if i want to run vrsetup /dev/vroot0 /dev/md2, then i get error "ioctl(): Device or resource busy" .... so how solve this problem?
1143045096 Q * independence Quit: reboot
1143045120 M * daniel_hozac are you sure you didn't already run vrsetup on /dev/vroot0 on that system?
1143045419 M * KLFMANiK i'm sure ... i just trying this on /dev/md2 - which is /tmp  .... first i tried this on /dev/md8 ..it's /vservers/blabla_guest
1143045491 M * daniel_hozac could you try with vroot1 instead?
1143045499 M * KLFMANiK but probably vroot0 is used ... how remove "vrestup" setting? restart?
1143045528 M * KLFMANiK yes, i tried vroot1 ... it works ;-)
1143045598 Q * KLFMANiK Quit: [BX] If idiots could fly, IRC would be an airport
1143045867 J * KLFMANiK ~mann@people.uvt.tuke.sk
1143046064 Q * KLFMANiK Quit: 
1143046328 Q * Dr4g Quit: Leaving
1143046534 J * Dr4g ~Dr4g@82-40-44-47.cable.ubr06.uddi.blueyonder.co.uk
1143046892 N * _mcp mcp
1143046944 J * Viper0482 ~Viper0482@p549767A2.dip.t-dialin.net
1143046995 M * doener hm, nice... gpl-wars on savannah... they won't accept gpl v2-only projects (anymore?)
1143047146 M * [PUPPETS]Gonzo savannah?
1143047205 M * blizz doener, gpl v3 now?
1143047215 M * blizz [PUPPETS]Gonzo, gnu's sourceforge i think
1143047215 Q * ||Cobra|| Remote host closed the connection
1143047223 M * [PUPPETS]Gonzo ah, thanks
1143047235 M * doener blizz: no, as it is not out yet, but only "v2 or later"
1143047237 M * [PUPPETS]Gonzo I hate it, when they use "real life" names :)
1143047244 M * blizz oh, okay
1143047257 M * doener http://savannah.gnu.org/task/?func=detailitem&item_id=5204
1143047449 J * bonbons ~bonbons@83.222.39.180
1143047455 Q * Viper0482 Remote host closed the connection
1143047537 M * blizz how can i get a /dev/initctl on guests?
1143047539 Q * gerrit Ping timeout: 480 seconds
1143047548 M * blizz does it need the CAP_SYS_BOOT capability? :P dont hink so..
1143047565 M * doener blizz: you need an init process
1143047572 M * blizz got one inside the guest
1143047575 M * doener ie. plain init style
1143047577 M * blizz yep
1143047594 M * blizz root         1  0.0  0.0   1476   524 ?        S    18:04   0:00 init [2]  
1143047606 M * daniel_hozac and that's not the blend-through host init?
1143047620 M * blizz i dont think so :P can i check that? ;-)
1143047625 M * blizz kill 1 as root *lol*
1143047643 M * doener vps -A | grep init -c
1143047656 M * blizz ough
1143047656 M * blizz zero
1143047665 M * doener zero?
1143047670 M * blizz INFO_INIT flag
1143047671 M * blizz 0
1143047722 M * doener uhm, drop the -c from grep...
1143047728 M * blizz zero lines output
1143047736 M * blizz vps shows no init
1143047749 M * daniel_hozac what does it show as pid 1?
1143047765 M * blizz theres only bash, vps and ps running
1143047772 M * blizz nothing with pid 1
1143047777 M * daniel_hozac ...
1143047780 M * daniel_hozac are you in the vserver?
1143047782 M * doener seems you missed the "-A"
1143047798 M * daniel_hozac or maybe the ps doesn't understand -A?
1143047808 M * blizz ew
1143047812 M * blizz -A not -a
1143047830 M * blizz sorry. yes, init running with pid 1
1143047838 M * daniel_hozac and how many inits?
1143047839 M * doener ok, any more inits?
1143047852 M * blizz no, only the one from MAIN context
1143047878 M * doener then you aren't using plain init style
1143047888 M * blizz its sysvinit
1143047913 M * daniel_hozac sysv == initless.
1143047930 M * doener i'm refering to the vserver configuration, not the style of your runlevel configuration ;)
1143047941 M * blizz both have sysvinit
1143047942 M * blizz host and guest
1143047978 M * daniel_hozac again, irrelevant. what's interesting is the contents of /etc/vservers/<name>/apps/init/style.
1143048000 M * blizz "sysv"
1143048020 M * blizz thats what i changed yesterday
1143048023 M * doener that needs to be "plain" for an init process to be spawned
1143048067 M * doener but what is the reason you want a /dev/initctl for?
1143048096 M * blizz reboot/halt
1143048112 M * doener reboot -f
1143048117 M * blizz mh, and style is plain i cannot stop the server anymore
1143048132 M * doener you should only change that when the vserver is stopped
1143048132 M * blizz i just got a 2.4 server somewhere else running and it has /dev/initctl
1143048138 M * blizz doener, i did
1143048230 M * blizz do i have to set the path to init then?
1143048236 M * blizz cmd.start is the rc script atm
1143048287 M * blizz damn, i would read the docs but its very very weird and i find it hard to find any infos :/
1143048324 M * daniel_hozac if you have set cmd.*, then the default actions will not be used for the ones you have specified.
1143048730 M * blizz ohkay, so i killed the cmd.* scripts and set init style to plain
1143048748 M * blizz seems to work, thanks. now i need to get some doc which tells me what initstyles mean on vserver level :;P
1143048810 M * blizz thanks alot ;)
1143048814 M * blizz im too confused..
1143048897 J * FireEgl Atlantica@Atlantica.Tcldrop.Org
1143048936 M * blizz works freakin' great. i only thought i need to set style to sysv because the distro uses sysvinit and not something else however..
1143049925 P * Roey Leaving
1143049967 J * gerrit ~gerrit@bi01p1.co.us.ibm.com
1143051020 P * Dr4g Leaving
1143051215 J * dos000 ~dos000@toronto-HSE-ppp4238349.sympatico.ca
1143051219 M * dos000 howdy
1143051303 M * dos000 the documnetation for multiple ip per vser seem to all point to the old way. do i just add one more to /etc/vservers/vname/interface ?
1143051334 M * daniel_hozac yes, add a another directory and set ip, dev and prefix as you normally would.
1143054043 J * chirp ~chirp@202-169-194-76.megapass.world-net.co.nz
1143054582 J * _are_ ~are@dslb-084-057-162-047.pools.arcor-ip.net
1143054778 M * _are_ hi
1143056130 Q * chirp Quit: Leaving
1143056312 Q * Loki|muh Quit: leaving
1143056764 M * doener i'm fine...
1143056771 M * doener sorry, wrong window
1143056979 J * shedi ~siggi@inferno.lhi.is
1143058654 Q * serving Ping timeout: 480 seconds
1143058839 J * serving ~serving@86.108.27.191
1143059038 Q * doener Quit: leaving
1143060552 Q * michal` Remote host closed the connection
1143060695 J * Aiken ~james@tooax6-118.dialup.optusnet.com.au
1143061496 Q * bonbons Quit: Leaving
1143065093 J * id23 ~id@p54A03239.dip0.t-ipconnect.de
1143065098 M * id23 aloha
1143065139 M * daniel_hozac hey
1143065176 N * Bertl_oO Bertl
1143065180 M * Bertl evening folks!
1143065183 M * daniel_hozac evening Bertl!
1143065216 M * coocoon hello
1143065271 M * Aiken 2.6.16 finally runs on my alpha
1143065295 M * Aiken 2.6.16-vs2.1.1-rc13 #3 Wed Mar 22 16:58:59 EST
1143065378 M * Aiken running the performance test the guest is still 3 minutes slower than the host
1143065457 Q * id23 Quit: Leaving
1143065467 M * Bertl Aiken: great!
1143065478 M * Bertl Aiken: (not the slower part :)
1143065518 M * Aiken I replaced all the packages that were coming up 
1143065522 M * Aiken 'no symbols
1143065532 M * Aiken in the profiling report
1143065553 M * Aiken now getting a far better system profile of those runs
1143065644 M * tokkee Hi everybody ;-)
1143065660 M * tokkee How do I set the context id for a vserver?
1143065693 M * daniel_hozac echo <number> > /etc/vservers/<name>/context
1143065706 M * tokkee thx
1143065718 M * tokkee which are allowed numbers?
1143065720 M * daniel_hozac or use --context on the vserver ... build command line.
1143065722 M * daniel_hozac 2-49151.
1143065746 M * tokkee Does this number have any special meaning or is it simply an ID?
1143065755 M * Bertl unique ID
1143065756 M * Aiken some of the profile data http://pastebin.com/616998
1143065770 M * tokkee daniel_hozac, Bertl: thx
1143065775 M * Bertl tokkee: i.e. same xid/context same guest
1143065788 M * tokkee got it ;-)
1143066155 M * tokkee How do I set a vserver to be of type "default"?
1143066185 M * daniel_hozac you mean have a mark of default?
1143066195 M * daniel_hozac meaning it will be started on boot by the default scripts?
1143066211 M * tokkee ack
1143066240 M * Bertl .../apps/init/mark IIRC
1143066255 M * daniel_hozac yep.
1143066304 M * tokkee Jup... that's it... thx
1143066933 M * tokkee none on /var/lib/collectd/vservers/42097 type unionfs (ro,dirs=/var/lib/vservers/users/var/lib/collectd)
1143066940 M * tokkee Is something like that a bad idea?
1143066951 M * tokkee When trying for the first time, I got a kernel oops :-/
1143066960 M * daniel_hozac what are you trying to do?
1143066991 M * tokkee "Mounting" a directory to the outside of a vserver...
1143067003 M * tokkee D'oh... why ain't I using hardlinks?
1143067017 M * daniel_hozac ... or using bind mounts...
1143067044 M * tokkee Well... I think unionfs is somewhat more advanced than bind mounts...
1143067070 M * tokkee I'm not sure yet, if I'm gonna need any of the unionfs features... :-/
1143067111 M * tokkee .oO( unionfs does provide a way to make the dir read-only, which a hardlink could not provide )
1143067128 M * daniel_hozac but a bind mount does, with vserver patches.
1143067157 M * tokkee Don't I need vserver testing for this to work?=
1143067167 M * daniel_hozac what do you mean?
1143067184 M * tokkee vserver 2.1 or something like that...
1143067196 M * daniel_hozac BME got integrated into the stable series for 2.0.2.
1143067203 M * tokkee I've got 2.0.1
1143067208 M * tokkee iirc
1143067211 M * daniel_hozac then you're screwed :)
1143067224 M * tokkee Well... I got unionfs ;-)
1143067234 M * tokkee unionfs rocks...
1143067258 M * tokkee ... most of the time at least ;-)
1143067266 M * daniel_hozac i wasn't aware it was in the kernel.
1143067267 M * tokkee I never had problems before...
1143067278 M * tokkee It's not in a vanilla kernel...
1143067311 M * daniel_hozac oh, so you merged the patches?
1143067324 M * tokkee No.... I just compiled the module...
1143067364 M * tokkee Well.. the kernel seems to run fine now...
1143067421 M * tokkee ... I guess it's gonna break again as soon as I leave to go home ;-)
1143071053 J * Smutje_ ~Smutje@xdsl-87-78-5-31.netcologne.de
1143071104 Q * matta Ping timeout: 480 seconds
1143071179 Q * Smutje Ping timeout: 480 seconds
1143071179 N * Smutje_ Smutje
1143071721 M * Bertl hah! that's a funny one ...
1143071744 M * Bertl http://vserver.13thfloor.at/Experimental/delta-ioprio-fix01.diff
1143071898 M * mugwump Bertl, did you see ebiederm's LKML responses?
1143071968 M * Bertl I saw and read one, which one do you refer to :)