1159142411 M * cehteh exclude the db  from backup but backup the dump
1159142424 M * cehteh if dumping is fast enough
1159142463 M * cehteh you just need to syncronize the backup with the finished of the dump
1159142484 M * ekc2 right. but I was hoping for something like vmware snapshot. which is why I asked about pausing the vserver.
1159142516 M * doener cehteh: hm, with locked MyISAM tables you can just copy the three files the table consists of
1159142533 M * cehteh or that .. well i dunno
1159142557 M * cehteh anyways you can use the device mapper for snapshots if you really need
1159142578 M * cehteh lvm and stuff .. but dont ask me about details .. 
1159142622 M * cehteh maybe some of this translucency filesystems too there are diffrent kinds of them
1159142689 M * ekc2 hmmm looks interesting. i have never used translucency
1159142710 A * cehteh neither dont blame me if there are problems
1159142736 M * ekc2 haha. yup. i will probably go with offline rdiff-backup
1159142795 M * cehteh as doener saied ... lock db, copy files, unlock db .. that likely gives the shortest possible interrupts
1159142828 M * cehteh similar things for other programs which have data which cant be hot-backuped ..
1159142850 M * cehteh and if these things are all finished send the backup server a notify that it can startup the backup
1159142903 M * cehteh well . with few changes in the data, rdiff backup is really fast 
1159142935 M * ekc2 makes sense. but in a general-case hosting environment where there's no control over what's running in a vserver, stopping the vserver seems like the only option
1159142946 M * cehteh but if you accidentally moved/altered much data it takes quite some time (meanding if u need to backup multiple GB of data)
1159143417 Q * ekc2 Ping timeout: 480 seconds
1159144300 J * mire ~mire@131-166-222-85.COOL.ADSL.VLine.verat.net
1159145009 J * adamm ~adamm@polaris.galacticasoftware.com
1159145636 Q * sladen Ping timeout: 480 seconds
1159146000 J * FireEgl FireEgl@Sebastian.Atlantica.US
1159146183 M * Bertl welcome adamm!
1159148100 Q * tso helium.oftc.net nova.oftc.net
1159148215 Q * mnemoc helium.oftc.net strange.oftc.net
1159148215 Q * litage helium.oftc.net strange.oftc.net
1159148215 Q * nebuchadnezzar helium.oftc.net strange.oftc.net
1159148487 J * nebuchadnezzar ~nebu@zion.asgardr.info
1159148487 J * mnemoc ~amery@kilo105.server4you.de
1159148487 J * litage ~nick@203.220.55.70
1159148553 Q * Johnnie charon.oftc.net helium.oftc.net
1159148553 Q * derjohn charon.oftc.net helium.oftc.net
1159148553 Q * Greek0 charon.oftc.net helium.oftc.net
1159148553 Q * harry charon.oftc.net helium.oftc.net
1159148553 Q * micah charon.oftc.net helium.oftc.net
1159148553 Q * Loki|muh charon.oftc.net helium.oftc.net
1159148553 Q * anonc charon.oftc.net helium.oftc.net
1159148553 Q * rob-84x^ charon.oftc.net helium.oftc.net
1159148553 Q * weeble charon.oftc.net helium.oftc.net
1159148553 Q * mugwump charon.oftc.net helium.oftc.net
1159148553 Q * ntrs charon.oftc.net helium.oftc.net
1159148553 Q * id23 charon.oftc.net helium.oftc.net
1159148553 Q * phedny_ charon.oftc.net helium.oftc.net
1159148553 Q * matti charon.oftc.net helium.oftc.net
1159148553 Q * Roey charon.oftc.net helium.oftc.net
1159148553 Q * mountie charon.oftc.net helium.oftc.net
1159148553 Q * _are_ charon.oftc.net helium.oftc.net
1159148553 Q * Hunger charon.oftc.net helium.oftc.net
1159148553 Q * eyck charon.oftc.net helium.oftc.net
1159148553 Q * ray6 charon.oftc.net helium.oftc.net
1159148553 Q * phreak`` charon.oftc.net helium.oftc.net
1159148553 Q * tanjix charon.oftc.net helium.oftc.net
1159148553 Q * MooingLemur charon.oftc.net helium.oftc.net
1159148553 Q * starlein charon.oftc.net helium.oftc.net
1159148553 Q * nayco charon.oftc.net helium.oftc.net
1159148553 Q * FloodServ charon.oftc.net helium.oftc.net
1159148553 Q * adamm charon.oftc.net helium.oftc.net
1159148553 Q * Aiken charon.oftc.net helium.oftc.net
1159148553 Q * soatola charon.oftc.net helium.oftc.net
1159148553 Q * cehteh charon.oftc.net helium.oftc.net
1159148553 Q * [PUPPETS]Gonzo charon.oftc.net helium.oftc.net
1159148553 Q * tokkee charon.oftc.net helium.oftc.net
1159148553 Q * bogus charon.oftc.net helium.oftc.net
1159148553 Q * cryptronic charon.oftc.net helium.oftc.net
1159148553 Q * nokoya charon.oftc.net helium.oftc.net
1159148553 Q * yang charon.oftc.net helium.oftc.net
1159148553 Q * samuel_ charon.oftc.net helium.oftc.net
1159148553 Q * mcp charon.oftc.net helium.oftc.net
1159148553 Q * mire Remote host closed the connection
1159148578 J * tso ~tso@196-019.adsl.pool.ew.hu
1159148578 J * adamm ~adamm@polaris.galacticasoftware.com
1159148578 J * Aiken ~james@tooax6-169.dialup.optusnet.com.au
1159148578 J * soatola ~soatola42@82.153.18.114
1159148578 J * id23 ~id@p5081271B.dip0.t-ipconnect.de
1159148578 J * cehteh ~ct@pipapo.org
1159148578 J * Johnnie ~jdlewis@jdlewis.org
1159148578 J * phedny_ ~mark@volcano.p-bierman.nl
1159148578 J * derjohn ~aj@dslb-084-058-195-087.pools.arcor-ip.net
1159148578 J * matti matti@linux.gentoo.pl
1159148578 J * Greek0 ~greek0@85.255.145.201
1159148578 J * harry ~harry@d54C2508C.access.telenet.be
1159148578 J * micah ~micah@micah.riseup.net
1159148578 J * bogus ~bogusano@fengor.net
1159148578 J * tokkee tokkee@casella.verplant.org
1159148578 J * FloodServ services@services.oftc.net
1159148578 J * ntrs ~ntrs@68-188-51-87.dhcp.stls.mo.charter.com
1159148578 J * nayco ~nayco@proxy2.laroche.univ-nantes.fr
1159148578 J * starlein star@fo0bar.de
1159148578 J * MooingLemur ~troy@shells200.pinchaser.com
1159148578 J * tanjix ~tanjix@office.star-hosting.de
1159148578 J * phreak`` ~phreak``@140.211.166.183
1159148578 J * [PUPPETS]Gonzo gonzo@langweiligneutral.deswahnsinns.de
1159148578 J * ray6 ~ray@194.126.159.45
1159148578 J * eyck eyck@195.242.124.71
1159148578 J * mugwump ~samv@watts.utsl.gen.nz
1159148578 J * weeble ~weeble@81.52.144.1
1159148578 J * cryptronic crypt@mail.openvcp.org
1159148578 J * mcp ~hightower@wolk-project.de
1159148578 J * nokoya young@hi-230-82.tm.net.org.my
1159148578 J * yang ~yang@cpe-213-157-253-172.dynamic.amis.net
1159148578 J * samuel_ ~samuel@jupe.quebectelephone.com
1159148578 J * _are_ ~are@62.112.159.81
1159148578 J * rob-84x^ rob@submarine.ath.cx
1159148578 J * Hunger Hunger.hu@213.163.11.138
1159148578 J * anonc ~anonc@staffnet.internode.com.au
1159148578 J * Loki|muh loki@satanix.de
1159148578 J * mountie ~mountie@69.196.162.198
1159148578 J * Roey ~katz@h-69-3-4-130.mclnva23.covad.net
1159148600 J * sladen paul@starsky.19inch.net
1159149444 J * gdm_ ~gdm@www.iteration.org
1159149444 Q * gdm Read error: Connection reset by peer
1159149913 Q * Aiken Ping timeout: 480 seconds
1159150349 M * Bertl okay, I'm off to bed now .. have a good one everyone! cya!
1159150358 N * Bertl Bertl_zZ
1159150388 Q * ensc Killed (NickServ (GHOST command used by ensc_))
1159150398 J * ensc ~irc-ensc@p54B4E6F7.dip.t-dialin.net
1159150482 J * Aiken ~james@tooax6-169.dialup.optusnet.com.au
1159150907 Q * Aiken Remote host closed the connection
1159150941 J * Aiken ~james@tooax6-169.dialup.optusnet.com.au
1159151363 J * vk4xjb ~james@tooax6-169.dialup.optusnet.com.au
1159151377 Q * vk4xjb 
1159151748 Q * Aiken Ping timeout: 480 seconds
1159153696 Q * id23 Ping timeout: 480 seconds
1159154224 J * id23 ~id@p508130BA.dip0.t-ipconnect.de
1159155165 Q * adamm Quit: adamm
1159156357 Q * VxJasonxV Read error: Connection reset by peer
1159156370 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1159159130 M * matti :)
1159159202 Q * Adrinael Ping timeout: 480 seconds
1159159726 J * Adrinael adrinael@hoasb-ff0edd00-43.dhcp.inet.fi
1159162836 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net
1159163570 J * coocoon ~coocoon@p54A051CE.dip.t-dialin.net
1159163618 M * coocoon morning
1159165263 J * derjohn2 ~aj@dslb-084-058-250-141.pools.arcor-ip.net
1159165705 Q * derjohn Ping timeout: 480 seconds
1159167313 J * meandtheshell ~markus@85-124-232-138.work.xdsl-line.inode.at
1159167951 J * dna_ ~naucki@118-239-dsl.kielnet.net
1159168177 J * Borg- ~borg@217.97.139.162
1159168329 Q * _are_ Quit: bbl
1159169433 M * cdrx morning
1159169885 M * daniel_hozac morning
1159170818 Q * shedi Quit: Leaving
1159171252 N * gdm_ gdm
1159172259 M * phreak`` morning
1159172289 J * prae ~Benjamin@5-63.206-83.static-ip.oleane.fr
1159173027 M * harry starlein: ?
1159173077 Q * brc_ Ping timeout: 480 seconds
1159173611 J * derjohn ~derjohn@80.69.37.19
1159175096 J * AndrewLee ~andrew@linux3.cc.ntu.edu.tw
1159176113 M * derjohn cohan_, EHLO ;)
1159176180 M * phreak`` meh, stupid /fastboot is finally gone :)
1159176210 M * doener /fastboot? Windows?
1159176247 M * phreak`` doener: nah, util-vserver and vps'es ;)
1159176294 M * doener Hm, IIRC I've only seen /fastboot in the windows boot process configuration thingy (years ago ;)
1159176413 M * doener phreak``: ah, /fastboot as a path, not an option, right?
1159176421 M * daniel_hozac yep :P
1159176423 M * phreak`` doener: yep :)
1159176432 M * phreak`` daniel_hozac: thanks by the way ;)
1159176438 M * phreak`` _rc2 works like a charm
1159176445 A * doener is sick so his brain is slow ;)
1159176483 M * cohan_ 250-cohan Hello derjohn, pleased to meet you
1159176484 M * daniel_hozac cool, i haven't found any bugs in it yet.
1159176507 M * derjohn cohan_, it's a small worls, as you mentioned :)
1159176511 M * derjohn *world
1159176550 M * AndrewLee Does anyone how to apply linux-patch-debian-2.6.17 to linux-source-2.6.17 if I want to rebuild a debian kernel image for vserver?
1159176557 M * derjohn phreak``, daniel_hozac, doener : off topic! I am scared ;)
1159176567 M * phreak`` derjohn: by what ? :P
1159176569 M * cohan_ definetly - did we also meet at this year's linuxday? i know i met herbert...
1159176579 M * doener derjohn: how is util-vserver off topic?
1159176596 M * phreak`` doener: nah, he is talking off-topic
1159176608 M * AndrewLee Seems it doesn't work that way which documented on http://kernel-handbook.alioth.debian.org/ch-common-tasks.html
1159176612 M * derjohn doener, /fastboot ? WTF is that in the utils ?
1159176624 M * doener derjohn: the tools create that in the vserver
1159176631 M * doener ... or used to do so
1159176633 M * cohan_ ah, linuxday... reminds me i still did not complete my keysignings... gna
1159176662 M * daniel_hozac hmm, still do, don't they?
1159176666 N * cohan_ cohan
1159176683 M * phreak`` derjohn: take a close look at the utils :P as doener just said a empty file named fastboot is created within the guests / on startup but is left around for ever (at least as long the guest is running)
1159176684 M * doener daniel_hozac: hu? phreak`` said that it's gone
1159176685 M * derjohn AndrewLee, hm, well I apply my patches manually to the kernel. Do you really want a Debian source or better a vanilla (which contains certain firmware blobs that Debian removed)?
1159176687 A * phreak`` runs 
1159176722 M * AndrewLee derjohn: I don't really want to maintain the security patches myself.
1159176730 M * phreak`` doener: well the file should be deleted after the guest is completly initialized :)
1159176750 M * AndrewLee s/security/security related/
1159176759 M * doener AndrewLee: hm, maybe --added-patches=vserver or sth. like that?
1159176773 M * daniel_hozac AndrewLee: what's wrong with the linux-image-vserver or whatever it's called?
1159176797 M * derjohn doener, AndrewLee at least in sid vserver is now a favlo(u)r of the std kernel, not an external patch
1159176827 M * doener derjohn: no idea to be honest, I always pull kernel.org kernels
1159176831 M * derjohn I remember the kernel packerls to be dpkg-buildpackage-able .....
1159176872 M * doener *LOL* packerls! where's gonzo? :)
1159176902 M * AndrewLee daniel_hozac: cause CONFIG_VSERVER_HARDCPU is not set
1159176911 M * derjohn AndrewLee, but adding a own build binary helps there? why dont you take the binary kernel debian already provides? It in good shaphe. waldi and micah are very active in putting  vserver to debian
1159176917 M * daniel_hozac AndrewLee: ah. poke waldi then and make him enable it ;)
1159176948 M * derjohn cohan, http://gallery.linux-vserver.org/main.php?g2_itemId=107 I am the one on the right ... 
1159176986 M * AndrewLee daniel_hozac: I did, but he said it's disabled by default.
1159177018 M * doener http://gallery.linux-vserver.org/main.php?g2_itemId=89 -- I'm the one on the right, who wasn't told that a picture was being taken ;)
1159177022 M * AndrewLee waldi: Could you please enable CONFIG_VSERVER_HARDCPU for debain vserver favlo?
1159177051 M * cohan derjohn: cool ;) don't know if i am on any photo on linuxtag - participated mainly in keysigning, openvz demo and vserver-"handson"
1159177061 M * phreak`` daniel_hozac: ok, to relieve you from the babel, the fix for the /fastboot file seems to be in baselayout-vserver :)
1159177093 M * daniel_hozac i.e. make the baselayout remove it?
1159177094 M * AndrewLee s/favlo/favlour
1159177108 M * cohan derjohn: anyway, i am on the road now - we'll keep in touch ;) you can leave a query anytime, in case pierre contacts you and i am not available
1159177127 M * phreak`` daniel_hozac: yeah, it does now :)
1159177157 M * daniel_hozac phreak``: ok, good :)
1159177165 M * daniel_hozac means i don't have do anything ;)
1159177206 M * phreak`` daniel_hozac: exactly :)
1159177221 M * AndrewLee I think I got it patched by this command: /usr/src/kernel-patches/all/apply/debian -f vserver -s 686 -a i386 -H /usr/src/kernel-patches/all/debian/
1159177300 M * derjohn AndrewLee, sure that this will _vserver_ patches? i might be true as the kernel-build infrastructure in sid was heavily changed.
1159177308 M * derjohn read: I dont know 
1159177364 M * AndrewLee derjohn: Yes, it's changed. Cause it doesn't match what document said on http://kernel-handbook.alioth.debian.org/ch-common-tasks.html
1159177463 Q * click Ping timeout: 480 seconds
1159177499 M * AndrewLee Ah, it's still not applied.
1159178172 J * mire_ ~mire@131-166-222-85.COOL.ADSL.VLine.verat.net
1159179465 M * AndrewLee andrew@zephyr:/usr/src/linux-source-2.6.17$ ../kernel-patches/all/apply/debian -H /usr/src/kernel-patches/all/debian/ -a i386 -f vserver -s 686 -R 9
1159179468 M * AndrewLee   (.) IGNORED   vserver-vs2.0.2.patch
1159179473 M * AndrewLee --> 9 fully applied.
1159179502 M * AndrewLee Does anyone know why it ignored vserver-vs2.0.2.patch?
1159179531 A * AndrewLee is thinking of allpy vserver-vs2.0.2.patch manually
1159179845 J * cuerva ~soatola42@82.153.18.114
1159180178 Q * soatola Ping timeout: 480 seconds
1159180335 J * lilalinux ~plasma@dslb-084-058-213-057.pools.arcor-ip.net
1159180440 J * brc_ ~bruce@200.97.68.21
1159181179 Q * mnemoc oxygen.oftc.net strange.oftc.net
1159181179 Q * litage oxygen.oftc.net strange.oftc.net
1159181179 Q * nebuchadnezzar oxygen.oftc.net strange.oftc.net
1159181285 J * nebuchadnezzar ~nebu@zion.asgardr.info
1159181285 J * mnemoc ~amery@kilo105.server4you.de
1159181285 J * litage ~nick@203.220.55.70
1159182457 N * AndrewLee AndrewLee2
1159182596 P * AndrewLee2 
1159182673 J * AndrewLee ~andrew@tnlug.linux.org.tw
1159183775 Q * cdrx Ping timeout: 480 seconds
1159184581 J * yarihm ~yarihm@84-74-17-70.dclient.hispeed.ch
1159186120 J * cdrx ~legoater@242.32.96-84.rev.gaoland.net
1159186163 Q * rob-84x^ Remote host closed the connection
1159186654 N * Bertl_zZ Bertl
1159186666 M * Bertl morning folks!
1159186674 M * daniel_hozac morning Bertl!
1159186699 M * Bertl AndrewLee: debian should have up-to date patches, but if you need to apply anything manually, I'd go for the 2.0.2.1 patch ...
1159186781 M * daniel_hozac but then you have to solve the conflicts yourself ;)
1159186859 M * Bertl hmm, shouldn't the 2.6.17 branch include all the changes/fixes from the sucker tree too?
1159186884 M * Bertl (somehow I got the feeling this was the sole purpose :)
1159186940 M * daniel_hozac what?
1159186972 M * Bertl to provide a base for distros to keep up with stability/security changes
1159187467 M * doener anyone interested in a flu?
1159187475 M * daniel_hozac haha, no!
1159187564 M * doener daniel_hozac: ok, back to business then... any idea how to integrate the two-namespace concept into util-vserver?
1159187605 M * doener I added some nasty patches to allow vnamespace and vcontext to access two namespaces stored in vx_info
1159187629 M * doener but I still don't see where I could/would add the namespace changes in the scripts
1159187690 M * daniel_hozac vnamespace doesn't have any other options, so i guess you'd just have to patch all of the invocations.
1159187734 M * doener I added a "-a" option (Alternate namespace)
1159187773 M * doener the C part should be done, but the scripts...
1159187821 M * daniel_hozac how is it supposed to work?
1159187831 M * doener (both, kernel and util-vserver changes are just PoC and quite ugly)
1159187894 M * doener I'd need to clone the hostnamespace as it is done now, store that etc. Then, as described in the proposal, I need to clone a second namespace and store that as well
1159188036 M * doener it's probably even easy to do, but I'm lost in the scripts
1159188134 M * daniel_hozac well, the cloning is done before the start script is executed.
1159188136 M * daniel_hozac you just have to store it.
1159188155 M * doener it is stored
1159188165 M * id23 2.6.18+vs look good so far - no troubles
1159188183 M * doener daniel_hozac: in the loooong line, there's a vnamespace -s call
1159188186 M * daniel_hozac right.
1159188279 M * daniel_hozac so i guess after that you'd need another vnamespace -n call and after that a vnamespace -a?
1159188301 J * Piet hiddenserv@tor.noreply.org
1159188366 Q * id23 Quit: Leaving
1159188409 M * doener the -a option is used in conjuction with -s or -e
1159188473 M * doener -s stores ns 1, -s -a stores ns 2, same for -e
1159188517 M * doener so if I don't hack the ns cleanup into vcontext, I need to return to the first namespace, because the tools aren't available in ns2
1159188532 M * daniel_hozac ah, ok.
1159188563 M * doener hm, maybe I can just make the cleanup tool fork and store a new ns
1159188610 M * doener then I'd just need to run that while inside the context and have the final vcontext call switch to ns2
1159188681 M * doener the cleanup hack is just a 5 line C program anyway... if I add two more lines, that's not sooo bad ;)
1159188693 M * doener and someone else can care about a clean implementation
1159189711 J * harti ~hw@83-215-237-5.seek.stat.salzburg-online.at
1159189717 M * Bertl welcome harti!
1159189719 M * harti hello
1159190513 Q * harti Quit: Leaving
1159190557 M * daniel_hozac doener: that does sound really ugly... will be hard to get that clean unless we make util-vserver more vserver-utils like, i.e. setup the context from the outside.
1159190773 M * doener daniel_hozac: we could probably do sth. like "vnamespace -n vnamespace -a -s /path/to/clean_namespace"
1159190804 M * daniel_hozac hmm, yeah...
1159190833 M * doener the only requirement is that we call it while we are in the context, and IIRC we start with enough caps to do the mount/pivot_root stuff
1159190904 M * Bertl sidenote: we could disable the caps in devel kernel completely until the setup is finished
1159190931 M * Bertl (the cap mask that is)
1159191136 M * derjohn 2.6.18 are still not devel ?
1159191143 M * daniel_hozac nope.
1159191359 M * Bertl .o( _still_not_ how this sounds ... :)
1159191561 Q * sladen Ping timeout: 480 seconds
1159191750 T * harry http://linux-vserver.org/ <- new and shiny | latest stable 2.02.1, 1.2.10, 1.2.11-rc1, devel 2.1.0, exp 2.1.1-rc35, stable+grsec 2.0.2.1 | 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 ;)
1159191780 M * Bertl excellent!
1159191781 M * daniel_hozac 2.6.18?
1159191783 M * harry new grsec + vserver patch online!!!!!
1159191788 M * harry nono
1159191793 M * harry 2.6.17.13 ;)
1159191796 M * daniel_hozac ok.
1159191831 M * harry spender found 30+ nullpointer dereferences in 2.6.18 by an automated check...
1159191839 M * harry i'll wait for some bugfix releases first...
1159191855 M * harry i did, however, more advanced patching on binfmt_elf
1159191871 M * doener actual derefs or just possible derefs?
1159191876 M * harry which i will test now... shouldn't be a problem, but off course... one can never be sure enough
1159191883 M * harry doener: possible ;)
1159191901 M * doener where "possible" as usual means "as far as the script can tell", right?
1159191904 M * harry i just looked @ the diffs of 2.6.18... it's huge
1159191910 M * harry ==> huge amount of errors ;)
1159191930 M * harry doener: haven't questioned him to the bone about it :)
1159191932 M * doener your vserver+grsec patch is quite big
1159191941 M * doener => quite a lot of errors ;)
1159191943 M * doener SCNR
1159191955 M * harry it's just vserver + grsec... both about 700k :)
1159191966 M * harry ==> errors in grsec , pax and vserver put together! :)
1159191988 M * harry hell... pax makes a lot of randomizations... so good luck on regular overflowing/malloc'ing/..
1159191999 M * harry ;)
1159192012 M * harry but... you're right, more patches, more possible errors :)
1159192027 M * harry so lets all run minix! ;)
1159192050 M * harry or qnx! (really small microkernel... but BUGGED AS HELL!)
1159192062 M * harry at least, it was bugged as hell 3 to 4 years ago :)
1159192069 M * harry when i did my final about it
1159192109 J * id23 ~id@p508130BA.dip0.t-ipconnect.de
1159192220 M * sid3windr DOS >*
1159192221 M * sid3windr ;)
1159192578 M * ex hi, VCD is working with vserver >2.1.X only?
1159192593 M * harry PM: Writing back config space on device 0000:02:00.1 at offset b (was 164814e4, writing 14a1028)
1159192598 M * harry what does this mean?
1159192654 M * harry Linux spare 2.6.17.13-grsec2.1.9-vs2.0.2.1 #1 SMP Mon Sep 25 15:39:10 CEST 2006 i686 GNU/Linux
1159192657 M * harry tadaaaaaaaa
1159192663 M * harry :)
1159192680 M * sid3windr *crash* ;>
1159192709 Q * weeble Quit: Leaving
1159192997 J * click click@ti511110a080-5416.bb.online.no
1159193073 M * harry hhee... naaaaah ;)
1159193167 J * sladen paul@starsky.19inch.net
1159193619 Q * FireEgl Quit: Bye...
1159193870 M * Bertl ex: yes, I assume so
1159194669 M * ex ok, thx... i want to use it for cacti (i dont like idea with ssh connecting etc)
1159194679 M * ex will have to wait untill next stable release
1159195192 J * FireEgl FireEgl@Sebastian.Atlantica.US
1159195333 Q * mnemoc oxygen.oftc.net iridium.oftc.net
1159195333 Q * litage oxygen.oftc.net iridium.oftc.net
1159195333 Q * nebuchadnezzar oxygen.oftc.net iridium.oftc.net
1159195333 Q * Loki|muh oxygen.oftc.net iridium.oftc.net
1159195333 Q * anonc oxygen.oftc.net iridium.oftc.net
1159195333 Q * mugwump oxygen.oftc.net iridium.oftc.net
1159195333 Q * ntrs oxygen.oftc.net iridium.oftc.net
1159195333 Q * micah oxygen.oftc.net iridium.oftc.net
1159195333 Q * harry oxygen.oftc.net iridium.oftc.net
1159195333 Q * Greek0 oxygen.oftc.net iridium.oftc.net
1159195333 Q * Johnnie oxygen.oftc.net iridium.oftc.net
1159195333 Q * tso oxygen.oftc.net iridium.oftc.net
1159195333 Q * FireEgl oxygen.oftc.net iridium.oftc.net
1159195333 Q * sladen oxygen.oftc.net iridium.oftc.net
1159195333 Q * id23 oxygen.oftc.net iridium.oftc.net
1159195333 Q * Piet oxygen.oftc.net iridium.oftc.net
1159195333 Q * yarihm oxygen.oftc.net iridium.oftc.net
1159195333 Q * AndrewLee oxygen.oftc.net iridium.oftc.net
1159195333 Q * Roey oxygen.oftc.net iridium.oftc.net
1159195333 Q * mountie oxygen.oftc.net iridium.oftc.net
1159195333 Q * matti oxygen.oftc.net iridium.oftc.net
1159195333 Q * phedny_ oxygen.oftc.net iridium.oftc.net
1159195333 Q * Hunger oxygen.oftc.net iridium.oftc.net
1159195333 Q * eyck oxygen.oftc.net iridium.oftc.net
1159195333 Q * ray6 oxygen.oftc.net iridium.oftc.net
1159195333 Q * phreak`` oxygen.oftc.net iridium.oftc.net
1159195333 Q * tanjix oxygen.oftc.net iridium.oftc.net
1159195333 Q * MooingLemur oxygen.oftc.net iridium.oftc.net
1159195333 Q * starlein oxygen.oftc.net iridium.oftc.net
1159195333 Q * nayco oxygen.oftc.net iridium.oftc.net
1159195333 Q * FloodServ oxygen.oftc.net iridium.oftc.net
1159195333 Q * cuerva oxygen.oftc.net iridium.oftc.net
1159195333 Q * prae oxygen.oftc.net iridium.oftc.net
1159195333 Q * Borg- oxygen.oftc.net iridium.oftc.net
1159195333 Q * ensc oxygen.oftc.net iridium.oftc.net
1159195333 Q * yang oxygen.oftc.net iridium.oftc.net
1159195333 Q * nokoya oxygen.oftc.net iridium.oftc.net
1159195333 Q * mcp oxygen.oftc.net iridium.oftc.net
1159195333 Q * cryptronic oxygen.oftc.net iridium.oftc.net
1159195333 Q * [PUPPETS]Gonzo oxygen.oftc.net iridium.oftc.net
1159195333 Q * tokkee oxygen.oftc.net iridium.oftc.net
1159195333 Q * bogus oxygen.oftc.net iridium.oftc.net
1159195333 Q * cehteh oxygen.oftc.net iridium.oftc.net
1159195333 Q * samuel_ oxygen.oftc.net iridium.oftc.net
1159195368 J * FireEgl FireEgl@Sebastian.Atlantica.US
1159195368 J * sladen paul@starsky.19inch.net
1159195368 J * id23 ~id@p508130BA.dip0.t-ipconnect.de
1159195368 J * Piet hiddenserv@tor.noreply.org
1159195368 J * yarihm ~yarihm@84-74-17-70.dclient.hispeed.ch
1159195368 J * AndrewLee ~andrew@tnlug.linux.org.tw
1159195368 J * cuerva ~soatola42@82.153.18.114
1159195368 J * prae ~Benjamin@5-63.206-83.static-ip.oleane.fr
1159195368 J * Borg- ~borg@217.97.139.162
1159195368 J * ensc ~irc-ensc@p54B4E6F7.dip.t-dialin.net
1159195368 J * tso ~tso@196-019.adsl.pool.ew.hu
1159195368 J * cehteh ~ct@pipapo.org
1159195368 J * Johnnie ~jdlewis@jdlewis.org
1159195368 J * phedny_ ~mark@volcano.p-bierman.nl
1159195368 J * matti matti@linux.gentoo.pl
1159195368 J * Greek0 ~greek0@85.255.145.201
1159195368 J * harry ~harry@d54C2508C.access.telenet.be
1159195368 J * micah ~micah@micah.riseup.net
1159195368 J * Roey ~katz@h-69-3-4-130.mclnva23.covad.net
1159195368 J * mountie ~mountie@69.196.162.198
1159195368 J * Loki|muh loki@satanix.de
1159195368 J * anonc ~anonc@staffnet.internode.com.au
1159195368 J * Hunger Hunger.hu@213.163.11.138
1159195368 J * samuel_ ~samuel@jupe.quebectelephone.com
1159195368 J * yang ~yang@cpe-213-157-253-172.dynamic.amis.net
1159195368 J * nokoya young@hi-230-82.tm.net.org.my
1159195368 J * mcp ~hightower@wolk-project.de
1159195368 J * cryptronic crypt@mail.openvcp.org
1159195368 J * mugwump ~samv@watts.utsl.gen.nz
1159195368 J * eyck eyck@195.242.124.71
1159195368 J * ray6 ~ray@194.126.159.45
1159195368 J * [PUPPETS]Gonzo gonzo@langweiligneutral.deswahnsinns.de
1159195368 J * phreak`` ~phreak``@140.211.166.183
1159195368 J * tanjix ~tanjix@office.star-hosting.de
1159195368 J * MooingLemur ~troy@shells200.pinchaser.com
1159195368 J * starlein star@fo0bar.de
1159195368 J * nayco ~nayco@proxy2.laroche.univ-nantes.fr
1159195368 J * ntrs ~ntrs@68-188-51-87.dhcp.stls.mo.charter.com
1159195368 J * FloodServ services@services.oftc.net
1159195368 J * tokkee tokkee@casella.verplant.org
1159195368 J * bogus ~bogusano@fengor.net
1159195382 J * nebuchadnezzar ~nebu@zion.asgardr.info
1159195382 J * mnemoc ~amery@kilo105.server4you.de
1159195382 J * litage ~nick@203.220.55.70
1159196997 Q * Borg- Quit: leaving
1159197281 Q * Piet Ping timeout: 480 seconds
1159197749 J * soatolaEspera ~soatola42@82.153.18.114
1159197930 J * stefani ~stefani@tsipoor.banerian.org
1159197947 M * Bertl welcome soatolaEspera! stefani!
1159197955 M * stefani hola
1159197988 Q * cuerva Ping timeout: 480 seconds
1159198106 J * rob_ ~rob@Q72d4.q.strato-dslnet.de
1159198126 M * Bertl welcome rob_!
1159199139 M * essobi_ Howdy
1159199257 Q * id23 Quit: Leaving
1159199262 M * Bertl hey essobi_!
1159199702 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1159199747 A * harry done well!
1159199808 A * harry just booted a quad dualcore hyperthreaded (==> 16 cpu's) 16GB ram machine with the new 2.6.17.13 kernel :)
1159199816 M * harry had to enable bigsmp for it tough... :)
1159199872 M * harry lets see how we can run vservers on that one ):
1159200025 M * Bertl make that
1159201094 M * trippeh 16 "cpu"'s :)
1159201106 J * bonbons ~bonbons@83.222.36.111
1159201115 M * trippeh I hope you are running a 64bit kernel on it.
1159201128 M * trippeh PAE is just plain evilness
1159201149 M * Bertl welcome bonbons!
1159201255 M * bonbons Hey Bertl!
1159202272 M * harry nono... 32 bit kernel :s
1159202277 M * harry that's the sucky part
1159202277 M * harry ;)
1159202313 M * harry PAE sucks indeed...
1159202434 Q * prae Quit: Quitte
1159202600 Q * cdrx Ping timeout: 480 seconds
1159202959 M * daniel_hozac ensc: http://people.linux-vserver.org/~dhozac/p/m/yum-2.9.6-chroot.patch does it look fine to you? i really don't know yum well enough to say. (just two conflicts from the 2.6.0 patch, and they were quite obvious)
1159203113 J * gerrit_ ~gerrit@c-67-160-146-170.hsd1.or.comcast.net
1159203179 J * Zaki ~Zaki@212.118.109.243
1159203395 Q * fosco Remote host closed the connection
1159204676 Q * FireEgl Ping timeout: 480 seconds
1159204711 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net
1159204864 M * Bertl wb cdrx! Zaki!
1159204881 M * Zaki Bertl, thx :)  
1159204884 M * Zaki cdrx ==?
1159204899 M * Bertl cdrx == cdrx :)
1159204910 M * Zaki hmm
1159204916 M * Zaki let me guess
1159204932 M * Bertl well, similar to Zaki == Zaki :)
1159204936 M * Zaki oh it's cdrx hehe the nick name
1159204960 M * Zaki sorry it has happened for the second time :$ (not an MSN fan but i don't know how to express a shy smilie hehe)
1159204995 M * Zaki Bertl, :$ (not an MSN fan but i don't know how to express a shy smilie hehe)
1159205014 M * Zaki Bertl, it has happened for the second time, the previous time i was confused too =)
1159205054 M * Zaki Bertl, btw, i need you for some work, can we talk privately?
1159205098 M * Zaki Bertl, please
1159205154 M * Bertl hmm, need as in 'you need my services for something which cannot be discussed publicly'?
1159205238 J * rob-84x^ rob@submarine.ath.cx
1159205244 M * Bertl wb rob-84x^!
1159205756 M * Zaki Bertl, because it has some "negotiations"
1159205795 M * Bertl well, okay, let's hear ...
1159206212 J * Belu B.Lukas@mail.openvcp.org
1159207149 M * yang Bertl: any improvement on Indigo ?
1159207215 M * Bertl yang: nope, nothing yet
1159207229 M * Bertl yang: it seems that almost all mips developers do not build natively
1159207247 M * Bertl yang: so the way to go is to find a box (i.e. x86 or so) to build the kernel there
1159207261 M * yang oh damn, complicated
1159207270 M * Bertl it especially seems that the kernel is not able to be built on a native mips system
1159207285 M * Bertl s/able/prepared/
1159207321 M * Bertl I have the required cross compilers, so no real problem, but I have to setup something to compile the kernel with the proper configs
1159207329 M * Bertl (so it is on my todo list)
1159207432 M * yang ok...I will be moving the server inside the apartment in october
1159207448 M * yang so there will be some downtime (1 day)
1159207527 M * Bertl np, just drop me a note
1159208206 Q * rob_ Quit: Verlassend
1159208777 M * Zaki Bertl,  CE(S)T == GMT+1 ?
1159208789 J * s0undt3ch_ ~s0undt3ch@82.155.69.211
1159208796 M * Bertl Zaki: yep
1159208802 M * Zaki k thx
1159208884 Q * lilalinux Remote host closed the connection
1159209029 M * daniel_hozac hmm, isn't it +2 with DST?
1159209057 M * Bertl CEST yes, CET no, IIRC
1159209074 M * daniel_hozac well, right, CEST is CET with DST, isn't it?
1159209098 M * Bertl yes, I tried to answer CET above
1159209111 M * daniel_hozac heh, ok.
1159209230 Q * s0undt3ch Ping timeout: 480 seconds
1159209230 N * s0undt3ch_ s0undt3ch
1159210123 M * Snow-Man Aren't you supposed to chattr to base directory of the vservers for some reason?
1159210462 M * Bertl the directory above the servers should get a --barrier
1159210491 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.18-vs2.1.1-rc35-t1.diff
1159210644 M * cdrx re hi. special one to bertl and zaki. 
1159210663 M * Zaki cdrx, :)
1159210808 M * cdrx Bertl, thanks for your patches.
1159210828 M * Bertl which ones?
1159210976 M * cdrx the kthread
1159211007 M * Bertl ah, np .. still have the nfs stuff on my todo, and still waiting for any feedback from the maintainer(s)
1159211041 M * cdrx yep I have a few on the waiting list
1159211062 M * cdrx how do you feel about using the namespace qhen they get merged in 2.6.19 ? 
1159211108 M * Bertl well, we will try to adapt Linux-VServer to the namespaces soon (i.e. using the patch base, assumed it is updated)
1159211135 M * Bertl I think the main work will be in userspace, so we should ask daniel_hozac about that :)
1159211169 M * Bertl cdrx: any decisions regarding sys_clone2() or similar yet?
1159211220 M * cdrx well, i've been maintaining a rather large patchset of stuff including resource management and a new syscall to
1159211241 M * cdrx make experiments. I called it unshare_ns though
1159211249 M * Bertl resource management as in?
1159211288 M * cdrx i've used the containers, beancounters, beancounters++, etc.
1159211317 M * cdrx it's interesting but not converging
1159211330 M * Bertl aha, so low performance, generalized resource management ala ckrm 
1159211340 M * cdrx yes :)
1159211356 M * cdrx but he, it's also a price to pay. 
1159211372 M * Bertl yeah, sure, np with that ...
1159211406 M * cdrx I'm convinced by light weight though, daniel is doing a lot of work on network for that net namespace
1159211426 M * cdrx so namespace, do you think we should change things ? 
1159211436 M * cdrx ipc and utsname ? 
1159211463 M * Bertl utsname is basically what already is in Linux-VServer, it's just 'used' slightly different
1159211479 M * cdrx ok good
1159211482 M * Bertl so I'm pretty confident that we will be able to use that out of the box
1159211507 M * Bertl about ipc I'm not 100% sure yet, because it also interacts with resource accounting and limits
1159211528 M * cdrx yes, locked memory and so
1159211537 M * Bertl of course, we have to adjust the existing kernel interfaces to allow to change the uts info 
1159211559 M * Bertl cdrx: mostly shared memory, semaphores and such
1159211600 M * cdrx uts: the /proc is not good enough for vserver ? 
1159211622 M * Bertl we allow to configure the entire uts values from outside
1159211645 M * cdrx through the vserver syscall ? 
1159211650 M * Bertl i.e. there are existing API calls for that, we have to map those to the new namespace
1159211653 M * Bertl yes, exactly
1159211698 M * cdrx ok. no big issue but still a patch.
1159211728 M * cdrx unshare is not good enough ?
1159211739 M * Bertl yeah, well, not really a problem, I actually expect most of the settings to need support from the kernel for some time
1159211773 M * Bertl the problem I see with the unshare itself is the permission problem (which still is unresolved IMHO)
1159211791 M * Bertl i.e. let's say you create a new uts namespace
1159211811 M * Bertl now you want to change some values, like the architecture (just for fun)
1159211828 M * Bertl you have to have certain capabilites to do so, right?
1159211834 M * cdrx yes 
1159211841 M * cdrx now its admin cap
1159211851 M * Bertl so you change those, and drop the capabilities, as you don't want the guest to have them, correct?
1159211864 M * cdrx yep
1159211880 M * Bertl now the guest is running, and you decide to change those values again, how to proceed on that?
1159211902 M * cdrx you need super capabilities :) 
1159211930 M * Bertl aha, well, I assume you have those on the host, but, how to access the uts namespace?
1159211931 M * cdrx it's always the same question: can you use the namespace without some sort of container 
1159211974 M * cdrx ok ok
1159211988 M * cdrx so user api still sucks
1159212046 M * cdrx we will have to fix that in 2.6.20 hopefully
1159212074 M * cdrx now ipc: same status ?  
1159212100 M * cdrx (apart from resource management ...)
1159212101 M * Bertl with ipc it's not a real issue, i.e. we do not change ipc namespaces atm
1159212116 M * Bertl so it would simply be a separate namespace and that's it
1159212150 M * Bertl so here 'only' the resource management and accounting has to be adjusted
1159212194 M * Bertl we actually prepared the pid namespace too, so once that is done, we can basically integrate it without too many issues
1159212203 M * cdrx :)
1159212203 M * Bertl s/the/for the/
1159212207 M * cdrx so did we
1159212223 M * Bertl what I expect to give problems there is the init less case
1159212232 M * cdrx difficult to get right though
1159212235 M * cdrx yes
1159212259 M * cdrx i specially like that one becaus it's very useful 
1159212302 M * Zaki Bertl, so linux-vservers is always released as patches to the plain kernel?
1159212312 M * cdrx i'm glad we are all preparing for it in some sense. we will have feedback when it's ready
1159212408 M * Bertl Zaki: yes, but most distros have packages too
1159212445 M * Zaki Bertl, is there pkgs for rhel4 ?
1159212471 M * Bertl cdrx: is there some testing planned performance and compatibility wise?
1159212496 M * cdrx performance, always. compatibility ? 
1159212506 M * Bertl Zaki: isn't that already discontinued? no idea if there are packages, maybe daniel_hozac knows more
1159212521 M * Bertl cdrx: well, something like the linux kernel test suites
1159212535 M * Zaki Bertl, it seems, rhel4 is still new, it was based on fc3
1159212538 M * Bertl cdrx: should be easy to run them before and after inside and outside
1159212555 M * Zaki daniel_hozac, hi, are you there?
1159212579 M * cdrx you mean ltp in an out a namespace ? 
1159212592 M * cdrx if so, yes we do that 
1159212594 M * Bertl for example
1159212595 M * daniel_hozac yep.
1159212628 M * cdrx we're trying to build test cases for such
1159212646 M * cdrx it's kind of a new area for the kernel
1159212654 M * Bertl good to hear .. if you need specific ideas  ... just let me know
1159212662 M * cdrx ok thanks.
1159212687 M * Zaki Bertl, is it better for me to do everything manual for the first time i try to install vservers so that i learn about it better?
1159212693 M * cdrx bertl, i would like to get something useful in 2.6.19 so if it breaks vserver. scream.
1159212698 M * Zaki Bertl, manually*
1159212712 M * Bertl cdrx: I will do for sure >:)
1159212715 M * daniel_hozac Zaki: i don't know of any packages, and i haven't gotten around to setting up CentOS buildroots.
1159212729 M * cdrx many thanks :)
1159212772 M * Bertl Zaki: if you have rhel4 installed on the host already, then just download a vanilla kernel and adjust it to your hardware (can't hurt to get a feeling for that)
1159212797 M * Zaki daniel_hozac, which distro is best in adopting linux-vserver and provide ready kernels and everything and get updated continously in the long run
1159212799 M * Zaki ?
1159212800 M * Bertl Zaki: if, OTOH, you are in the process of choosing a distro, take one which already has vserver packages
1159212828 M * daniel_hozac Zaki: Debian probably, if you want long-time support.
1159212835 M * Zaki Bertl, well i'm having centos4 already installed
1159212850 M * Zaki Bertl, so i'm going to follow the howto for centos and do as you said
1159212936 M * Zaki daniel_hozac, what's the second to debian?
1159212969 M * daniel_hozac probably Fedora or Gentoo.
1159213004 M * Zaki daniel_hozac, ok which fedora version?
1159213019 M * Zaki daniel_hozac, to start with for testing
1159213028 M * daniel_hozac well, since FC5 is the only stable version that's still officially supported, that's what i'd go with.
1159213038 M * daniel_hozac but FC6 will be out in a few weeks.
1159213054 M * Zaki daniel_hozac, ok thanks alot 
1159213057 M * Zaki Bertl, thanks
1159213060 M * Bertl np
1159213084 M * daniel_hozac (http://oldwiki.linux-vserver.org/VServer+installation+Fedora+Core+5 in case you hadn't found it already)
1159213104 M * Zaki found thx
1159213318 M * Zaki which version of kernel is best to try for CentOS 4 (=RHEL4 / FC3)
1159213320 M * Zaki ?
1159213346 M * Zaki to download from www.kernel.org
1159213380 M * daniel_hozac the latest?
1159213397 M * daniel_hozac there may be some slight incompatibilities, but they really should be minimal.
1159213412 M * Zaki daniel_hozac, is it the best to start with (first time newbie) to go with the latest ?  2.6.18 ?
1159213431 M * Zaki daniel_hozac, i'd like the easiest one to start with 
1159213440 M * daniel_hozac well, maybe not 2.6.18 as it's still sort of in testing.
1159213448 M * daniel_hozac you could go with 2.6.17.13.
1159213453 M * Zaki daniel_hozac, ok
1159213483 M * Zaki daniel_hozac, btw, my current system is running 2.6.9 !
1159213510 M * Zaki daniel_hozac, isn't it better to go back to that version too?
1159213513 M * daniel_hozac yeah, that's what an enterprise distribution gets you ;)
1159213523 M * daniel_hozac then you'll end up with ancient patches....
1159213524 M * Zaki i know and that's what i prefer to use
1159213529 M * Zaki hehe
1159213530 M * daniel_hozac 2.0 was released for 2.6.12.
1159213538 M * daniel_hozac 2.0.1 for 2.6.14.
1159213547 M * Zaki ok, then i'll go for 2.6.17.13
1159213631 J * _are_ ~are@62.112.159.81
1159213732 M * Bertl wb _are_!
1159213798 M * _are_ hi
1159213861 M * Zaki while it's downloading i'll go to my sister to fix her laptop
1159213864 M * Zaki bye for now =)
1159213934 M * Bertl cya
1159214040 M * cdrx bertl: would rather have a clone like syscall or a unshare like specific to namespaces ? 
1159214095 M * Bertl well, both have their uses, but I think userspace will prefer the clone like interface, daniel_hozac?
1159214168 M * daniel_hozac it would probably be easier to adapt to, at least.
1159214382 M * cdrx hmm, is it because you want/need to do that in one syscall  rather than clone() && unshare_ns(some_flag) ? 
1159214584 Q * bonbons Quit: Leaving
1159215894 J * tatiane ~tatiane@201009056060.user.veloxzone.com.br
1159215918 Q * gerrit_ Ping timeout: 480 seconds
1159215978 M * Bertl welcome tatiane!
1159217191 M * daniel_hozac well, we're already using clone to get a new fs namespace.
1159217421 M * daniel_hozac so the changes would be really minimal.
1159217538 M * Bertl sidenote: would be nice to be able to test with and without uts/ipc namespaces too 
1159218023 M * cdrx bertl, daniel_hozac: we are reaching the limits of the clone flags so an idea is to use a syscall dedicated to namespaces, clone2 or unshare. my feeling is that a clone2 with a 64 bits flags is going to be as ugly as llseek. an unshare_ns seems easier.
1159218027 J * harti ~Hartmut@85-124-97-58.dynamic.xdsl-line.inode.at
1159218052 M * daniel_hozac well, i guess it doesn't really matter.
1159218056 M * cdrx and you will still need to call the vserver syscall 
1159218075 M * Bertl which one? :)
1159218208 M * cdrx bertl: do you see an issue with the test with and without namespaces ? what's the idea ?
1159218357 M * Bertl well, I think it might be a nice feature to have guests without the uts or ipc namespace (or with a shared namespace lateron)
1159218427 M * daniel_hozac shouldn't that just be a matter of not unsharing those?
1159218508 M * cdrx i guess so
1159218688 M * Bertl yeah, precisely
1159218708 M * Bertl well, it will become a little more complicated when you want to have two guests to share ipc
1159218726 M * Bertl (which again will require some 'handle' for the namespaces)
1159218737 M * daniel_hozac yeah.
1159218749 M * daniel_hozac handles will be required for entering too, no?
1159218786 M * daniel_hozac or is entering not supported at all?
1159218953 M * Bertl we will have to snapshot the namespaces with the context struct
1159219401 J * gerrit_ ~gerrit@bi01p1.co.us.ibm.com
1159219432 M * daniel_hozac yeah, like the fs namespace then.
1159219536 M * cdrx entering a namespace is something that has not been addressed yet 
1159219555 M * cdrx well, from a user space api POV
1159219639 M * cdrx unshare or clone would not be of any use here. 
1159219663 M * daniel_hozac right.
1159219919 M * Bertl personally I'd prefer to assign address ids to the namespaces
1159220041 Q * mire_ Quit: Leaving
1159220184 M * cdrx namespace ids that could be built on top of namespaces. a good id for the moment is the pid of the process that does the unshare
1159220200 M * Bertl well, not really
1159220216 M * cdrx i got you wrong then
1159220217 M * daniel_hozac would just be a random number for init-less guests.
1159220237 M * Bertl it might look like a good choice, but considering that many 'init' replacements go away after executing the runlevel scripts
1159220246 J * dna___ ~naucki@237-229-dsl.kielnet.net
1159220260 M * Bertl it would probably cause duplicates and other issues too
1159220293 M * Bertl IMHO the (virtual) memory address would be a good choice (for a Q&D solution)
1159220309 M * cdrx sure
1159220328 M * cdrx it's like the task_struct, best id of a process
1159220356 M * Bertl yep, although I doubt that lkml folks will accept exporting kernel addresses to userspace :)
1159220363 M * cdrx you need another layer to manage that
1159220376 M * cdrx associate a literal name with a unique id
1159220465 M * Bertl the question is, where and _when_ to associate those names with the id
1159220552 J * mire_ ~mire@142-166-222-85.COOL.ADSL.VLine.Verat.NET
1159220681 Q * dna_ Ping timeout: 480 seconds
1159220691 M * cdrx just an idea: you need a task to unshare some namespace, once that task has done the unshare it could bind the namespace to some name.
1159220709 M * cdrx which means another syscall bind_ns
1159220753 M * cdrx then the taks can die or stay, you don't care the namespace is bound and can be found
1159220763 M * cdrx if needed
1159220881 M * cdrx we could even connect to the bound namespace to enter it ? 
1159221352 Q * dna___ Quit: Verlassend
1159221354 M * cdrx I'll send an email on the topic tomorrow. until then, good night !
1159221363 M * Bertl have a good one!
1159221926 Q * tatiane Quit: Leaving
1159222378 Q * meandtheshell Quit: exit (0);
1159222616 A * Belu is away (iŽll be back later...)
1159222616 N * Belu Belu_zZz
1159223166 J * Aiken ~james@tooax6-135.dialup.optusnet.com.au
1159223636 M * Zaki how to apply a patch of the format .diff file?
1159223649 M * Zaki to the kernel souces
1159223660 M * mnemoc patch -p1 < foobar.diff
1159223667 J * tdjb ~tdjb@209.151.52.189
1159223676 M * Zaki while in the current directory is the root of the kernel sources?
1159223697 M * mnemoc look the ^--- lines on the patch
1159223718 M * mnemoc count how many levels you have to remove to apply considering where you are standing
1159223726 M * mnemoc and run patch -p<level>
1159223732 M * Zaki first cd to the kernel root directory of the sources right?
1159223756 M * mnemoc yes
1159223796 M * Zaki the .diff file should contain text right?
1159223808 M * Bertl yes
1159223853 M * mnemoc o.o
1159223870 M * Zaki links http://www.13thfloor.at/vserver/s_rel26/v2.02/patch-2.6.17.13-vs2.02.1.diff.gz
1159223871 M * mnemoc hi Bertl 
1159223882 M * mnemoc zcat | patch
1159223884 M * Zaki i have downloaded this 
1159223900 M * Zaki but after i gunzip it, i get a garbage .diff file :/
1159223978 M * Zaki it seems the gz  file is not downloaded fully
1159224026 M * Bertl let me check that
1159224036 M * Zaki i'm using wget now
1159224049 M * Zaki [root@linux src]# ll patch-2.6.17.13-vs2.02.1.diff.gz
1159224049 M * Zaki -rw-r--r--  1 root root 141901 Sep 13 19:48 patch-2.6.17.13-vs2.02.1.diff.gz
1159224054 M * Zaki is the size correct?
1159224066 M * Bertl 141901
1159224075 M * Bertl yep, I can provide an md5sum too
1159224079 M * Zaki i got it
1159224086 M * Zaki the reason was links !!!
1159224095 M * Bertl http://www.13thfloor.at/vserver/s_rel26/v2.02/patch-2.6.17.13-vs2.02.1.diff.gz.md5
1159224105 M * Bertl evil links!! :)
1159224109 M * Zaki for some strange unknown reason and probably it's first time happens to me
1159224113 M * Zaki hehe
1159224140 M * Zaki i love md5sums :)
1159224255 M * Zaki i should use FTP instead
1159224279 M * Zaki ok downloaded correctly now
1159225091 Q * harti Quit: Client exiting
1159225736 M * Bertl okay, I guess I'm off to bed now .. maybe back later ...
1159225748 M * Bertl have a good one everyone! cya!
1159225753 N * Bertl Bertl_zZ
1159225837 J * mire ~mire@142-166-222-85.COOL.ADSL.VLine.Verat.NET
1159226561 M * Zaki Belu_zZz, good night 
1159226574 P * stefani I'm Parting (the water)
1159227431 Q * mire Quit: Leaving
1159227432 Q * mire_ Quit: Leaving
1159228211 J * shedi ~siggi@inferno.lhi.is
1159228255 J * mire_ ~mire@97-167-222-85.COOL.ADSL.VLine.verat.net
1159228510 Q * gerrit_ Ping timeout: 480 seconds
1159228769 Q * mire_ Quit: Leaving