1350521178 Q * grobie Ping timeout: 480 seconds
1350521333 J * grobie ~grobie@78.47.105.20
1350521520 J * macmaN ~chezburge@138.167.190.90.dyn.estpak.ee
1350521928 J * FireEgl FireEgl@2001:470:e5ad:1:1881:d60b:1207:dea1
1350522063 Q * Chlorek Ping timeout: 480 seconds
1350523622 Q * grobie Ping timeout: 480 seconds
1350523753 J * grobie ~grobie@78.47.105.20
1350524927 Q * eyck Read error: Connection reset by peer
1350524996 Q * grobie Ping timeout: 480 seconds
1350528059 Q * FireEgl Read error: Connection reset by peer
1350528940 J * FireEgl FireEgl@2001:470:e5ad:1:b437:b96b:afdd:bc1c
1350529911 J * fisted_ ~fisted@xdsl-87-78-186-121.netcologne.de
1350530279 Q * fisted Ping timeout: 480 seconds
1350531229 Q * clopez Ping timeout: 480 seconds
1350532076 J * clopez ~clopez@48.16.165.83.dynamic.mundo-r.com
1350533155 M * Bertl off to bed now ... have a good one everyone!
1350533159 N * Bertl Bertl_zZ
1350534514 J * sannes ~ace@cm-84.211.87.28.getinternet.no
1350535294 Q * clopez Ping timeout: 480 seconds
1350536414 Q * fisted_ Quit: brb
1350537329 J * fisted ~fisted@xdsl-87-78-186-121.netcologne.de
1350537991 Q * uranus Quit: Verlassend
1350538201 J * uranus ~uranus@HSI-KBW-078-042-157-029.hsi3.kabel-badenwuerttemberg.de
1350538920 Q * uranus Quit: Verlassend
1350539887 J * ghislain ~AQUEOS@adsl2.aqueos.com
1350541755 Q * ircuser-1 Quit: ircuser-1
1350543569 Q * ensc|w Remote host closed the connection
1350543579 J * ensc|w ~ensc@www.sigma-chemnitz.de
1350544190 J * uranus ~oli@HSI-KBW-078-042-157-029.hsi3.kabel-badenwuerttemberg.de
1350544504 J * vspas ~vspas@87.213.36.165
1350545427 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1350547533 Q * geos_one Quit: ChatZilla 0.9.89 [Firefox 15.0.1/20120920112759]
1350553136 Q * ncopa Quit: Leaving
1350553189 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no
1350553272 N * Bertl_zZ Bertl
1350553279 M * Bertl morning folks!
1350553937 M * BlackPanx morning
1350553938 M * BlackPanx :)
1350554169 Q * vspas Remote host closed the connection
1350554365 J * Harzilein ~harzi@harzilein.eu.org
1350554367 M * Harzilein hi
1350554375 M * Harzilein i wonder if there was ever an attempt at getting the cowbl filesystem bits from linux-vserver into mainline
1350554413 M * Bertl IIRC, there was at some point (many years ago)
1350554416 M * Harzilein (i don't know if more filesystem bits are needed, maybe to hide the attribute from the containers?)
1350554455 M * Harzilein or do containers not get extended attributes at all?
1350554688 M * Bertl we have a total of 3 flags currently used
1350554780 M * Bertl one for the barrier, which can probably be faded out ...
1350554813 M * Bertl one to mark a file as CoW
1350554856 M * Bertl and another one which does the 'immutable unlink inversion'
1350554870 M * Bertl (which is not really needed for CoW)
1350555270 M * Harzilein is there a sysfs/netlink interface or anything for those? i think some dynamic configurability would appease those who would not like one trick pony code in the kernel
1350555331 M * Bertl what do you mean by sysfs/netlink? those are filesystem attributes
1350555434 M * Harzilein i mean enabling/configuring their application to filesystem operations
1350555470 M * Bertl ah, you mean for 'mainline'
1350555472 M * Harzilein yes
1350555496 M * Bertl they are configureable at kernel build time
1350555504 M * Bertl but not at runtime atm
1350555514 M * Bertl but I guess it would be simple to add that
1350555591 Q * Deathtje Ping timeout: 480 seconds
1350555595 A * Harzilein should be honest: i share a dedicated server with some friends and we use vserver, at work we use openvz, and there can be a lot of nearly-identical staging containers -> would be perfect use for hashify-like functionality
1350555778 M * Bertl yeah, openvz is missing that (and some other stuff)
1350555844 M * Bertl but I think that is intentional, IIRC, they still have a commercial product :)
1350555854 M * Harzilein it would not really need to be integrated with openvz i think, just configurable enough that it can hide the attribute from cgroups
1350555870 M * Harzilein (or make it read-only, or whatever you do)
1350555898 M * Bertl you have all the code/source you need, start hacking :)
1350555903 M * Harzilein :D
1350556040 M * Harzilein apart from the link breaking OR immutable unlinkable files and hooking them into fs operations there is no special kernel support needed, right? (as the unification is done in userland)
1350556091 M * Bertl well, yes and no, you need to set/clear those flags somehow
1350556111 M * Bertl this is currently done via the Linux-VServer syscall command switch
1350556478 J * clopez ~clopez@fanzine.igalia.com
1350557434 M * sid3windr cowbell filesystem? :o
1350557489 M * daniel_hozac yes, based on teaching cows to ring their bells at different intervals.
1350557566 M * sid3windr doesn't sound very persistent :D
1350557586 M * Bertl ah, cows can be very persistent ...
1350557723 M * Harzilein meh, that naddress thing would be very useful for cgroups as well imho. currently when i use layer 2-interfaces in openvz, i cannot configure them from the host
1350557788 M * Bertl that's what I meant with missing features ... pardon the question, what is it that makes you use openvz in the first place?
1350557872 M * Harzilein Bertl: it's integrated with proxmox and my former boss liked the shiny interface of that (and the current boss likely would have "shiny interface" on his checklist as well)
1350557933 M * Bertl I talked with the proxmox folks a long time ago, and they said: it should be no problem to support Linux-VServer if there is interest ...
1350557977 M * Bertl and actually I think it shouldn't be that different from LXC or openvz (regarding proxmox)
1350558010 M * Bertl so maybe consider spending your time and effords there instead of trying to fix openvz :)
1350558067 M * Harzilein oh, they actually already started integrating lxc? (i'm quite behind with the updates)
1350558158 M * Harzilein when they have to support multiple isolation flavours in their utilities/web interface already, adding vserver should really be easy
1350558158 M * Bertl well, dietmar stated (september 2009) that they have an LXC prototype, but it will take one or two years to get it perfectly useable
1350558191 M * Bertl so I'd assume that by now it is already finished
1350558264 M * Harzilein Bertl: i think efforts at getting generic support for the unification scheme into mainline would not be wasted
1350558316 M * Bertl good luck with that
1350559240 M * Harzilein heh, cehteh (who runs the dedicated server i'm sharing) even appears in your faq :)
1350559703 M * BlackPanx http://linux-vserver.org/Networking_vserver_guests should dummy0 bridge eth0 or br0 whichever is external interface ?
1350559716 M * BlackPanx to be able to access outside network from guest
1350559740 M * Harzilein btw, do you know of any file system trickery that can force another uid/gid for bind-mounted sockets? (say, for sharing the mysql socket between systems where the mysql uid differs)
1350559945 M * daniel_hozac no
1350560129 M * Bertl BlackPanx: doesn't matter, it will not be used anyway
1350560363 Q * ircuser-1 Ping timeout: 480 seconds
1350560814 M * trippeh Harzilein: You could use a application level proxy like socat, but that adds some overhead
1350560881 M * Bertl or just use a network socket instead
1350560941 M * Harzilein Bertl: that's what we are doing now, i was just wondering if i'm missing something. sharing unix sockets would be nice.
1350560943 M * Jb_boin lxc isnt supported by proxmox at the interface level but it might be supported by is kernel
1350560946 M * trippeh At that point probably more efficient yes :)
1350560954 M * Jb_boin but i am not 100% sure
1350561039 M * Bertl Jb_boin: so the proxmox folks are lazy bastards or have a deal with the Parallels folks?
1350561040 M * Jb_boin Harzilein, you could make a group that have both uid in it and add rights for the group but it might induce a security risk
1350561099 M * Jb_boin Bertl, they are two separate entities if i am right
1350561159 M * Jb_boin Harzilein, another solution would be to put one of your sql on a container (lxc could be enough for this) with the same uid/gid mapping as on the other server
1350561248 M * Jb_boin as for lxc+vserver on the same kernel, at some point in the past it wasnt possible, is it still the case or not?
1350561258 M * Harzilein Jb_boin: yeah, those are basically all solutions that revolve around adapting the guests. i could add configuration management for that and make it very easy, i'd still be curious if there's some way to make it work transparently
1350561280 M * Bertl Jb_boin: not AFAIK, i.e. it is supposed to work fine 
1350561320 M * Bertl (and any problems with LXC on Linux-VServer patched kernels should be reported :)
1350561332 M * Jb_boin will give it a try if i got the motivation then
1350561377 M * Jb_boin Harzilein, anyway what is the use of having a mysql bind mounted on another container?
1350562027 M * Harzilein Jb_boin: as opposed to using a tcp socket? not requiring tcp while talking between local processes
1350562062 M * daniel_hozac do you compile your kernels without TCP?
1350562069 M * Harzilein no
1350562072 M * daniel_hozac so...
1350562082 M * daniel_hozac what are you hoping to achieve?
1350562148 M * Harzilein copying the data into tcp buffers, then into ip buffers, to the routing stuff in the kernel and back through another ip and tcp buffer presents unnecessary overhead
1350562183 M * daniel_hozac you realize it's the same for UNIX sockets, right?
1350562210 M * daniel_hozac you avoid the local lookup table, and instead use the UNIX socket lookup table, but all in all...
1350562213 M * Harzilein daniel_hozac: huh? no. there's no tcp/ip involved at the very least
1350562379 M * Harzilein i agree that the tcp/ip copying is likely better optimized than the mysql serialization, so it would likely not matter, but still, the "clean" solution in my view requires some way to "bind mount" (could be any other approach) sockets into the other vfs namespace
1350562423 M * daniel_hozac yes, use an ugly hack instead of a proper solution where you can migrate your guests around...
1350562430 M * Harzilein and control the access permission somehow in a way that is isolation-aware
1350563074 M * Bertl it is rather easy, just synchronize the uid/gid between guests if you control the superuser on all involved guests
1350563145 M * Bertl but as daniel_hozac already stated, I'm pretty sure that you won't gain any advantage over 'local' tcp sockets
1350563163 M * Bertl (unless you have a very complicated iptables setup filtering lo)
1350563859 M * Harzilein i don't understand how you conclude it's no advantage. it might be minor, but skipping two rounds of tcp/ip shouldn't be without impact
1350563864 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1350564043 J * vspas ~vspas@87.213.36.165
1350564194 J * kir ~kir@swsoft-msk-nat.sw.ru
1350564265 M * daniel_hozac Harzilein: i'd love to see your benchmarks.
1350564344 P * kir 
1350564827 M * Bertl Harzilein: packets on lo are not even copied, they are handed by reference
1350564887 M * Bertl filling the packet buffers is the same regardless of the socket type, so as daniel_hozac already stated, the only difference is in the lookup, which might even take longer on the filesystem based socket :)
1350564938 M * Harzilein Bertl: oh
1350564971 M * Bertl but of course, scheduling and other stuff can change that, so it really depends on the setup
1350565230 M * Harzilein Bertl: just for clarification, you are referring to ip packets, it would still need to go through the tcp motions with slow start and everything?
1350565257 M * Harzilein Bertl: or is that actually faked?
1350565291 M * Harzilein (which would appear strange, you could no longer test tcp on lo)
1350565484 M * Bertl I doubt there will be packet loss on lo, so congestion control should not affect the transfers
1350565555 M * Bertl but of course, you can defintely set TCP_NODELAY
1350565634 M * Bertl (to avoid buffer latencies, although I'm not sure what the buffer latencies are on unix sockets)
1350565691 M * Harzilein is there some other "network" socket that would allow a stream more along the lines of unix socket or pipe apis?
1350565722 M * daniel_hozac you've never been able to "test" TCP on LO.
1350565769 M * Harzilein daniel_hozac: i did not mean simulation
1350565772 M * daniel_hozac not on Linux.
1350565787 M * Harzilein daniel_hozac: so it _is_ faked?
1350565797 M * Harzilein that would be wonderful to hear :D
1350566149 M * Bertl if performance is really critical, I'd investigate pipes
1350566305 M * Harzilein Bertl: it would be "neat" to know we don't have higher database latency than necessary
1350566315 M * Bertl they should be one of the fastest IPC solutions besides shared memorz
1350566361 M * Harzilein Bertl: mysql does not support them and i have no clue what they would do between vfs namespaces
1350566396 M * Harzilein (so we are back to the socat suggestion from above)
1350566409 M * Harzilein regarding benchmarks, here is a slightly ancient one: http://scottmoonen.com/2008/04/05/a-performance-comparison-of-af_unix-with-loopback-on-linux/
1350566665 M * Bertl well, and it is on a distro kernel as well, which probably includes all kind of stuff (network wise)
1350566687 M * Harzilein ah, in solaris fake tcp connections on loopback are called "tcp fusion"
1350566726 M * Bertl but it might as well be that we are completely wrong here and AF_UNIX is indeed vastly superior to AF_INET over loopback on Linux
1350566752 M * Harzilein and here's an unanswered serverfault thread asking for this feature on linux: http://serverfault.com/questions/312866/tcp-fusion-on-linux
1350567051 M * Harzilein and yeah, the benchmark could be better, it does not mention if netfilter/iptables is loaded
1350567331 M * Bertl so IMHO you have to do some real world tests yourself :)
1350569327 M * BlackPanx is it possible to add more vservers to same dummy0 device (different local ip's) then forward on firewall with prerouting each port to other vserver ? meaning other local ip on dummy0 device... ?
1350569377 M * BlackPanx or i need each vserver on it's own dummy device ?
1350569381 M * BlackPanx probably not.
1350569399 M * Bertl put as many IPs on one dummy device as you like
1350569404 M * BlackPanx iptables -t nat -A PREROUTING ! -s 192.168.100.0/24 -m tcp -p tcp --dport $EXTPORT -j DNAT --to-destination $EXTIP:$INTPORT
1350569412 M * BlackPanx this is the line that covers prerouting
1350569415 M * BlackPanx on wiki
1350569471 M * BlackPanx is this a typo? 
1350569483 M * BlackPanx it should be --to-destionation $INTIP:$INTPORT
1350569485 M * BlackPanx ?
1350569735 M * BlackPanx yeap, it is.
1350569738 M * BlackPanx i'll fix it.
1350569830 M * BlackPanx nevermind it's properly written, just my stupidity.  thanks.
1350571609 M * Bertl np
1350571613 M * Bertl off for a nap .. bbl
1350571626 N * Bertl Bertl_zZ
1350574401 J * fisted_ ~fisted@xdsl-84-44-146-246.netcologne.de
1350574415 Q * fisted Read error: No route to host
1350575508 Q * FireEgl Remote host closed the connection
1350576308 J * FireEgl ~FireEgl@173-25-83-57.client.mchsi.com
1350576433 J * bonbons ~bonbons@2001:960:7ab:0:c0af:6f33:bcb2:6de8
1350579393 J * hijacker_ ~hijacker@cable-84-43-134-121.mnet.bg
1350580437 Q * vspas Ping timeout: 480 seconds
1350582120 N * Bertl_zZ Bertl
1350582123 M * Bertl back ...
1350582587 J * geos_one ~chatzilla@80.123.185.198
1350584217 Q * fisted_ Ping timeout: 480 seconds
1350586738 Q * clopez Ping timeout: 480 seconds
1350588400 J * fisted ~fisted@p5DE8FCC7.dip.t-dialin.net
1350589064 Q * hijacker_ Remote host closed the connection
1350589143 J * sweil ~stefan@p5086EFF2.dip.t-dialin.net
1350589306 Q * sweil Remote host closed the connection
1350591023 J * clopez ~clopez@48.16.165.83.dynamic.mundo-r.com
1350592473 Q * clopez Ping timeout: 480 seconds
1350593294 J * isAAAc ~isaaac@2a01:e35:8a4f:f60:c646:19ff:fe58:33e4
1350593775 Q * sannes Remote host closed the connection
1350594901 Q * bonbons Quit: Leaving
1350598192 Q * fisted Ping timeout: 480 seconds
1350599988 N * ensc Guest2304
1350599997 J * ensc ~irc-ensc@p54ADE25A.dip.t-dialin.net
1350600401 Q * Guest2304 Ping timeout: 480 seconds
1350600742 Q * ghislain Quit: Leaving.
1350601641 J * fisted ~fisted@xdsl-84-44-146-246.netcologne.de
1350602299 Q * isAAAc Quit: Konversation terminated!