1225325105 Q * dowdle Remote host closed the connection
1225325867 Q * yarihm Quit: Leaving
1225326466 M * Bertl daniel_hozac: any patches sitting on your shelf for 2.6.27.4 (over the .3 version I uploaded)?
1225326505 M * daniel_hozac yeah.
1225326524 M * Bertl good, hit me! :)
1225326539 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-fperm-clean05.diff http://people.linux-vserver.org/~dhozac/p/k/delta-barrier-dlc01.diff
1225326590 M * daniel_hozac actually, skip the first one. that's not the most recent version.
1225326615 M * Bertl okay, looks like we already have parts of that
1225326644 M * daniel_hozac not in the uploaded patch..
1225326695 M * Bertl hmm, why do you want to move back the barrier flags?
1225326712 M * daniel_hozac same reason as iunlink. no reason to break backwards compat.
1225326737 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-fperm-fix06.diff
1225326747 M * Bertl well, ext4 is getting new flags, we should keep some distance ther
1225326774 M * daniel_hozac that's fine, i don't think there are a lot of ext4 deployments yet.
1225326791 M * Bertl so I think it is a good idea to move the barrier and cow flags up
1225326830 M * Bertl the barrier is easily rebuilt, so no problem there
1225326869 M * daniel_hozac huge problem, IMHO.
1225326877 M * Bertl why?
1225326901 M * daniel_hozac all of a sudden people's deployments would be open to chroot escapes, just because their kernel got upgraded.
1225326952 M * Bertl same problem with changing from one kernel with 'older' flags to one with newer, no?
1225326965 M * daniel_hozac which is why i'm restoring them.
1225327078 M * daniel_hozac unless the older you're referring to is 2.4.
1225327616 M * Bertl so what do you propose to avoid having the xfs issue with ext3/4 in the very near future (with a devel/stable release)?
1225327748 M * daniel_hozac as i said, i'm fine with ext4 having other bits.
1225327782 M * daniel_hozac ext3 shouldn't be getting any new significant features, given ext4's presence.
1225327815 M * Bertl and you don't want to synchronize the flags across filesystems
1225327834 M * Bertl (which is what I did)
1225327857 Q * nenolod Read error: Connection reset by peer
1225327869 M * daniel_hozac what?
1225327961 M * Bertl *_BARRIER_FL = 0x10000000
1225328065 J * nenolod ~nenolod@ip70-189-74-62.ok.ok.cox.net
1225328083 M * daniel_hozac i really don't think that's a legitimate reason to break existing setups.
1225328142 M * Bertl so you think that the existing filesystems will not use up the flags in the near future, correct?
1225328157 M * Bertl (excluding ext4 now)
1225328191 M * daniel_hozac i think that's something we should handle then. if they don't, awesome. if they do, well, that sucks and we'll have to make a big announcement.
1225328322 Q * nenolod 
1225328413 M * Bertl IMHO we should (or should have done a long time ago, actually) add a check action/script/whatver to the tools to verify that things like the barrier are in place and more than that , are in the right place (remember I suggested that a year ago or so?)
1225328454 J * nenolod ~nenolod@ip70-189-74-62.ok.ok.cox.net
1225328480 M * Bertl but as we cannot travel in time, only the should part remains relevant :)
1225328584 M * Bertl anyway, I'm really curious how mainline solves the chroot barrier problem (or has laready solved it?)
1225328605 M * daniel_hozac from what i've gathered, they don't intend to use chroot.
1225328624 M * daniel_hozac pivot_root doesn't have the same problem.
1225328654 M * Bertl okay, so why don't we use that (wasn't that something I suggested _many_ years ago?)
1225328744 M * daniel_hozac only works on filesystems.
1225328777 M * Bertl so mainline is going for loop devices or what?
1225328853 M * daniel_hozac they're treating it as either virtual machines, or application virtualization (sharing mostly the same filesystem).
1225328856 M * Bertl but I think pivot_root should work on any vfs mount
1225328881 M * daniel_hozac yeah, i suppose that's true.
1225328882 M * Bertl (all it does is moving around vfs mounts)
1225328910 M * daniel_hozac the biggest problem with pivot_root is that the host's root becomes inaccessible in the guest's namespace.
1225328932 M * daniel_hozac so vnamespace -e <guest> ... is practically useless.
1225328932 M * Bertl which could be solved by introducing an intermediate namespace
1225329086 M * Bertl we preobably should rethink where we want to go here, and how the future 'chroot jail' will look like, no?
1225329181 M * Bertl if we stick to the barrier approach, I'd prefer to move the barrier flag out of reach of normal filesystem flags (for the foreseeable future)
1225329235 M * Bertl if we go for a more elaborate approach, based on vfs/namespace trickery, we should do that soon (but then I'm fine with fading out the barrier flag slowly)
1225332375 M * Bertl ah, well, let's continue tomorrow ...
1225332384 M * Bertl have a good one everyone ... off to bed now
1225332391 N * Bertl Bertl_zZ
1225332443 M * daniel_hozac good night!
1225340588 J * grobie` ~grobie@valgrind.schnuckelig.eu
1225340682 Q * grobie Read error: Connection reset by peer
1225341305 Q * Mojo1978 Read error: Connection reset by peer
1225344048 M * daniel_hozac Bertl_zZ: btw, i think we should merge https://lists.linux-foundation.org/pipermail/containers/2008-October/013823.html and https://lists.linux-foundation.org/pipermail/containers/2008-October/013825.html
1225344786 J * chigital ~chigital@tmo-100-177.customers.d1-online.com
1225345216 J * ntrs_ ~ntrs@77.29.10.1
1225345566 Q * chigital Ping timeout: 480 seconds
1225347426 J * mtg ~mtg@dialbs-088-079-143-204.static.arcor-ip.net
1225350149 Q * ntrs_ Ping timeout: 480 seconds
1225351196 Q * padde Read error: Connection reset by peer
1225351223 J * padde ~padde@patrick-nagel.net
1225351429 Q * sono Ping timeout: 480 seconds
1225351687 M * phedny Bertl_zZ: do you read the message sent to you when you're away?
1225351737 M * phedny Bertl_zZ: anyway, pivot_root works on anything indeed, I have used it to move a tmpfs to / in a separate namespace as part of a study exercise
1225351760 M * daniel_hozac any mount point.
1225351767 M * phedny yes
1225351817 M * phedny the exercise was to create a new namespace that was disjoint with the original one
1225352362 J * chigital ~chigital@services.mivitec.net
1225352404 J * argonius ~argonius@argonius.de
1225352408 M * argonius heyho
1225352494 M * argonius i am new to linux vserver. is there any chance to find out the hostname of the node, a vserver is hosted on?  I only have access to the vserver :(
1225353096 M * phedny I don't think it's reliably possible
1225353106 M * phedny but I'm not the best expert here ;)
1225353160 M * argonius hmm ok :(
1225353163 M * argonius thanks
1225353251 M * phedny one piece of information you could get is the mac address of the ethernet adapter
1225353271 M * argonius should it be the same?? 
1225353275 M * phedny /sbin/ifconfig | grep HWaddr
1225353283 M * phedny in my case it matches with the host
1225353288 M * argonius hmmmm
1225353308 M * argonius will try it 
1225353335 M * phedny than, if you have access to another machine on the network, you can try to find out which host ip matches the mac :)
1225353388 M * phedny owh wait, you don't even need that
1225353395 M * argonius i do not have access to another machine
1225353401 M * phedny if you know the IPs of all hosts, you can just ping them
1225353407 M * argonius yo tried it
1225353408 M * phedny and then run "arp -n" and find out which IP is missing
1225353415 M * argonius i already done this
1225353421 M * argonius but one host i do not get any mac 
1225353423 M * argonius *wondering*
1225353429 M * argonius the other one isn't the searched one
1225353438 M * phedny I just tried
1225353441 M * argonius me too :D
1225353449 M * phedny when I ping the host IP of the guest, it won't show up in arp -n
1225353456 M * phedny which is logical, because it doesn't need it
1225353463 M * argonius *donk*
1225353465 M * argonius argh
1225353467 M * argonius sigh!
1225353477 M * argonius thanks  of course ...
1225353507 M * argonius head -> table ....
1225353759 Q * larsivi Quit: Konversation terminated!
1225354101 J * davidkarban ~david@193.85.217.71
1225354994 J * ntrs_ ~ntrs@77.29.10.1
1225355599 J * ntrs__ ~ntrs@77.29.18.17
1225356013 Q * ntrs_ Ping timeout: 480 seconds
1225357163 Q * ntrs__ Ping timeout: 480 seconds
1225357997 J * larsivi ~larsivi@85.221.53.194
1225360381 Q * doener Ping timeout: 480 seconds
1225360578 J * doener ~doener@i577B8F8E.versanet.de
1225361994 J * ntrs__ ~ntrs@77.29.18.17
1225362119 Q * Guy- Ping timeout: 480 seconds
1225362672 Q * larsivi Remote host closed the connection
1225362894 J * larsivi ~larsivi@85.221.53.194
1225363353 Q * pisco Ping timeout: 480 seconds
1225363663 J * pisco ~pisco@tor-irc.dnsbl.oftc.net
1225364663 Q * ntrs__ Ping timeout: 480 seconds
1225364689 J * Guy- ~korn@elan.rulez.org
1225364969 Q * m_o_d Ping timeout: 480 seconds
1225365607 N * Bertl_zZ Bertl
1225365611 M * Bertl morning folks!
1225367295 Q * doener Ping timeout: 481 seconds
1225367488 J * doener ~doener@87.123.142.255
1225368030 J * slestak ~sromanow@63.91.142.226
1225368032 Q * weasel Quit: Reconnecting
1225368036 J * weasel ~weasel@anguilla.debian.or.at
1225368083 Q * weasel Quit: Reconnecting
1225368088 J * weasel ~weasel@anguilla.debian.or.at
1225368123 M * slestak i am investiating using vserver on my rhel 5.2 box for openvpn.  rhel 5 is on 2.6.18, but over at your wiki, 2.2.0.3 uses 19.7
1225368129 M * slestak am i sol for rhel?
1225368165 M * Bertl well, probably the best choice is to go for 2.6.22.x :)
1225368197 M * Bertl anyway, most distros do fine with a mainline kernel, so that shouldn't be a problem
1225368220 M * slestak but on rhel, arent you _supposed_ to stay on the same minor number so you dont experiecnce large anoumts of kernel module breakage?
1225368246 M * Bertl kernel modules usually come with the kernel, so there is no real breakage
1225368269 M * Bertl some distros have problems with userspace tools related to hardware setup though
1225368307 M * slestak i see this at lq.org.  http://www.linuxquestions.org/questions/linux-software-2/how-to-update-rhel-5-kernel-to-2.6.22-586547/
1225368334 M * slestak but that doesnt mean i get feature upgrades.
1225368343 J * dna ~dna@61-222-dsl.kielnet.net
1225368385 M * slestak i'll check over at #rhel
1225368387 M * slestak thx
1225368390 P * slestak 
1225369873 Q * bzed Quit: leaving
1225369884 J * bzed ~bzed@devel.recluse.de
1225370306 M * chigital hi
1225370342 M * chigital anyone know`s how i set swap space for a vserver
1225370391 M * chigital is /etc/vservers/vserver0/rlimits the right way, or is it only for memory
1225370452 M * Bertl basically you don't
1225370471 M * Bertl i.e. there is no real point in configuring swap for a guest, as swapping will happen on the host
1225370494 M * Bertl but, if you want to make a guest look like it has a certain swap space assigned (some apps need that :)
1225370506 M * chigital ah ok
1225370507 M * Bertl then you can do that with VIRT_MEM
1225370529 M * Bertl the difference between soft and hard rss limit (on recent kernels/patches) will be shown as swap
1225370628 M * chigital ok i have set a hard and soft limit but only memory is limited
1225370642 M * chigital looks like a kernel prob
1225370674 M * Bertl you don't get swap shown inside the guest? is VIRT_MEM set and what kernel/patch version?
1225370695 M * Bertl (older versions used the difference between AS and RSS
1225370725 M * chigital VIRT_MEM is set
1225370751 M * chigital i get swap in the guest from the host
1225370785 M * chigital i think that`s a debian kernel with a debian vserver patch
1225370815 M * Bertl which is a broad range :)
1225370908 M * chigital 2.6.18-4-vserver-amd64
1225371038 M * chigital shit happens
1225371061 M * chigital it isn`t necessary
1225371061 M * Bertl no idea what version that is, probably vs2.0 or vs2.2
1225371076 M * Bertl with vs2.2 you should be fine
1225371115 M * chigital vs2.2 kernel-patch???
1225371149 M * Bertl the Linux-VServer kernel patch, yes
1225371167 M * chigital ok i see on your page
1225371187 M * chigital thx for your help
1225371194 M * chigital i will test a little bit
1225371424 M * Bertl np
1225372405 Q * zbyniu Server closed connection
1225372407 J * zbyniu ~zbyniu@ip-62.181.188.13.static.crowley.pl
1225374162 Q * Aiken_ Remote host closed the connection
1225374887 J * TimG ~root@tor-irc.dnsbl.oftc.net
1225375594 Q * TimG Remote host closed the connection
1225375624 J * TimG ~root@tor-irc.dnsbl.oftc.net
1225376437 Q * Genghis Server closed connection
1225376468 J * Genghis ~Genghis@what.is.this.digitalcrap.org
1225376496 N * Genghis Guest798
1225376848 Q * mcp Read error: Connection reset by peer
1225376888 J * mcp ~mcp@wolk-project.de
1225377567 Q * davidkarban Quit: Ex-Chat
1225377648 M * Bertl nap attack ... bbl
1225377653 N * Bertl Bertl_zZ
1225377729 Q * argonius Quit: leaving
1225378365 J * ntrs__ ~ntrs@77.29.10.192
1225379136 N * Guest798 Genghis
1225379316 Q * larsivi Quit: Konversation terminated!
1225380230 J * dowdle ~dowdle@scott.coe.montana.edu
1225382355 Q * chigital Ping timeout: 480 seconds
1225382607 Q * ntrs__ Ping timeout: 480 seconds
1225382685 Q * kir Quit: Leaving.
1225382863 Q * micah Remote host closed the connection
1225382871 J * micah ~micah@micah.riseup.net
1225383180 J * onox ~onox@kalfjeslab.demon.nl
1225385587 J * chigital ~chigital@tmo-100-95.customers.d1-online.com
1225386374 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1225386535 Q * chigital Ping timeout: 480 seconds
1225388683 Q * _nono_ Quit: Leaving
1225388857 Q * micah Remote host closed the connection
1225388861 J * micah ~micah@micah.riseup.net
1225388997 J * micah_ ~micah@micah.riseup.net
1225389003 Q * micah_ 
1225389011 J * oconnect ~micah@micah.riseup.net
1225389011 Q * oconnect 
1225389616 J * larsivi ~larsivi@212251132182.customer.cdi.no
1225389620 Q * pmenier_off Quit: Konversation terminated!
1225390235 Q * larsivi Read error: Connection reset by peer
1225390247 J * larsivi ~larsivi@212251132182.customer.cdi.no
1225390660 J * larsivi_ ~larsivi@9.80-202-30.nextgentel.com
1225390729 Q * larsivi Ping timeout: 480 seconds
1225391150 Q * mtg Quit: Verlassend
1225391307 Q * pisco Quit: leaving
1225391519 J * cga ~weechat@94.36.121.222
1225392023 N * Bertl_zZ Bertl
1225392055 M * Bertl back now ...
1225392917 M * daniel_hozac Bertl: did you see the patches i pasted last night?
1225393834 Q * ktwilight__ Remote host closed the connection
1225393926 Q * TimG Remote host closed the connection
1225393974 J * TimG ~root@tor-irc.dnsbl.oftc.net
1225394023 J * ktwilight__ ~ktwilight@87.66.206.244
1225394044 Q * ktwilight__ Remote host closed the connection
1225394081 J * ktwilight__ ~ktwilight@87.66.206.244
1225394668 Q * dna Ping timeout: 480 seconds
1225395149 M * Bertl daniel_hozac: not yet
1225396235 Q * ktwilight__ Read error: Connection reset by peer
1225396272 J * ktwilight__ ~ktwilight@87.66.206.244
1225396770 Q * cga Quit: WeeChat 0.2.6
1225397526 J * Aiken ~Aiken@ppp118-208-9-204.lns1.bne1.internode.on.net
1225397526 Q * ktwilight__ Read error: Connection reset by peer
1225397709 J * ktwilight__ ~ktwilight@87.66.206.244
1225397735 M * daniel_hozac Bertl: and pivot_root will be fine, but the kernel will need to keep track of two filesystem namespaces.
1225397736 Q * ktwilight__ Read error: Connection reset by peer
1225397772 J * ktwilight__ ~ktwilight@87.66.206.244
1225398037 M * Bertl daniel_hozac: yeah, I expected that, but that is a change we can easily accomodate
1225399519 J * ktwilight_ ~ktwilight@4.109-66-87.adsl-dyn.isp.belgacom.be
1225399805 Q * ktwilight__ Ping timeout: 480 seconds
1225400179 J * JonB ~NoSuchUse@77.75.164.169
1225400428 Q * ag- Server closed connection
1225400443 J * ag- ~ag@fedaykin.roxor.cx
1225401064 J * ntrs ~ntrs@77.29.194.192
1225401138 Q * openblast Remote host closed the connection
1225401814 Q * JonB Quit: Leaving
1225401876 J * openblast ~quassel@static.230.173.47.78.clients.your-server.de
1225401948 M * micah daniel_hozac: nice work with the proofreading, I think you threw that person :)
1225402034 M * daniel_hozac hehe, probably.
1225402104 Q * openblast Remote host closed the connection
1225402799 Q * bonbons Quit: Leaving
1225402905 J * jescheng ~jescheng@proxy-sjc-1.cisco.com
1225403030 J * docelic ~docelic@78.134.204.99
1225403130 J * openblast ~quassel@static.226.173.47.78.clients.your-server.de
1225403580 J * Aiken_ ~Aiken@ppp118-208-49-170.lns4.bne1.internode.on.net
1225403893 Q * Aiken Ping timeout: 480 seconds
1225403918 Q * ktwilight_ Remote host closed the connection
1225403955 J * ktwilight_ ~ktwilight@4.109-66-87.adsl-dyn.isp.belgacom.be
1225404156 J * Nuls ~Nuls@p548E3017.dip.t-dialin.net
1225404273 M * Bertl welcome Nuls!
1225404324 J * dna ~dna@61-222-dsl.kielnet.net
1225404978 Q * ntrs Ping timeout: 480 seconds
1225405011 Q * dna Ping timeout: 480 seconds
1225405272 J * chigital ~chigital@tmo-100-181.customers.d1-online.com
1225406984 M * Bertl daniel_hozac: yeah, the suggested patches sound good to me .. do you know are they still up-to-date?
1225407033 M * daniel_hozac they are.
1225407116 M * Bertl excellent, so regarding the filesystem flags, we leave the barrier where it is now, and fade it out in favor of pivot_root, yes?
1225407207 M * Bertl for that to happen, we need to record two filesystem/vfs mount namespaces per guest, correct?
1225407228 M * daniel_hozac right.
1225407341 M * Bertl both settings will happen in the setup stage, I presume?
1225407375 M * daniel_hozac yes.
1225407404 M * Bertl and I guess we also need a 'guest mount' tool, to do the required mounts in both namespaces, if somebody wants to change anything on the fly?
1225407479 M * daniel_hozac i was thinking we'd use MS_SHARED for that.
1225407499 M * Bertl yeah, that would be nice
1225407509 Q * chigital Ping timeout: 480 seconds
1225407638 M * Bertl okay, how do we extend the API, a new set/enter_space command with an index?
1225407672 M * daniel_hozac couldn't we just use another bit?
1225407694 M * Bertl we probably need to record not just the namespace, no?
1225407732 M * daniel_hozac two other bits then.
1225407766 M * daniel_hozac the entire lowest byte is unused.
1225407775 M * Bertl from the kernel PoV we need to create an nsproxy anyways
1225407799 M * Bertl so those 'special' bits would very much complicate kernel side handling for no real gain, IMHO
1225407837 M * Bertl a new command with an additional index might be more flexible here, and we can map it to the old command by using index 0
1225407902 M * Bertl but if we use other bits for that, what would be the semantic?
1225407939 M * Bertl lower bits are transposed and merged to proxy 1, the rest goes to proxy 0
1225407958 M * Bertl (works for the set, but what about the enter?)
1225408035 M * Bertl micah: any news from your server?
1225408099 M * daniel_hozac why would we need an entire additional nsproxy?
1225408476 M * Bertl well, we don't want to put numerous special cases into the code, do we?
1225408499 M * Bertl so we already have the set (record) and enter (apply) code for nsproxy copies working
1225408554 M * Bertl if we do the index part, it's just a few lines of changes in a perfectly working code
1225408595 M * Bertl if we do the special flags, we get all kind of semantical issues (think both flags for namespace set, etc) and we need to special case them everywhere
1225408770 M * daniel_hozac okay, fine.
1225408783 M * daniel_hozac i don't really have a preference either way.
1225408794 M * Bertl okay, I'll wrap up a patch
1225409108 M * Bertl do we want to be able to extend the vhi/uts space handlers to that additional space too?
1225409147 M * daniel_hozac i don't see the point of doing so.
1225409165 M * Bertl okay, so I leave that at nsproxy[0] 
1225409438 Q * kiorky Ping timeout: 480 seconds
1225409454 M * micah Bertl: no, it rebooted again but i need to hook up a serial console to get better logging
1225409467 M * Bertl I thought you already had one?
1225409863 Q * dowdle Remote host closed the connection
1225410084 Q * onox Quit: leaving
1225410359 Q * Aiken_ Remote host closed the connection
1225410448 J * Aiken ~Aiken@ppp118-208-49-170.lns4.bne1.internode.on.net
1225410687 J * kiorky ~kiorky@cryptelium.net