1355190966 M * Bertl off to bed now ... have a good one everyone! 1355190978 N * Bertl Bertl_zZ 1355194349 Q * nou Remote host closed the connection 1355194514 J * nou Chaton@causse.larzac.fr.eu.org 1355205419 Q * nicholi Ping timeout: 480 seconds 1355205700 J * nicholi ~nicholi@rrcs-76-79-196-34.west.biz.rr.com 1355207105 Q * nou Ping timeout: 480 seconds 1355207114 J * nou Chaton@causse.larzac.fr.eu.org 1355207799 Q * geos_one Remote host closed the connection 1355208572 Q * nkukard Quit: Leaving 1355209110 J * thierryp ~thierry@home.parmentelat.net 1355210375 J * Ghislain ~aqueos@adsl1.aqueos.com 1355211842 Q * nou Ping timeout: 480 seconds 1355213879 J * geos_one ~chatzilla@80.123.185.198 1355215041 Q * thierryp Remote host closed the connection 1355215763 J * fleischergesell ~fleischer@p5B0A2356.dip.t-dialin.net 1355215812 M * fleischergesell Morning folks 1355216026 M * fleischergesell Since we're just about to configure a new host, we were wondering whether there is any "best practice" for setting up the interfaces for the guests. We always used to create a new dummyXX device for each guest, but this gets tedious after a while and I'm not sure if we actually benefit there in any way. How do you guys do this? Just using the standard eth0 device that is also connected to the outer world? Or would you rather setup O 1355216706 M * Guy- fleischergesell: fwiw, I use a single dummy0 interface and give each guest an IP on that 1355216720 M * Guy- fleischergesell: however, Bertl seems to think this is somehow wrong 1355216836 M * fleischergesell Do you know why he thinks so? 1355217018 Q * geos_one Quit: ChatZilla 0.9.89 [Firefox 17.0/20121127214048] 1355217166 M * ard I put the ip's on lo 1355217176 M * ard for each network I have a seperate network namespace 1355217188 M * fleischergesell what do you mean by network namespace? 1355217242 M * ard we usually have 1 or more server per vlan. We create a vlan on the interface, migrate that to a vserver with seperate network namespace, solely for the purpose of holding the interface 1355217269 M * ard and share that network namespace with the vservers that are going to do real stuff in that network 1355217313 M * ard to create a network namespace holder we create a vserver with an empty /etc/vservers//spaces/net 1355217342 M * ard after that one has started (post start) we create the interface on the host, and migrate that to that vserver 1355217360 M * ard real vservers will have the spaces/net file set to the name of the holder 1355217386 M * fleischergesell wow, that sounds rather complicated. Is that just for securty purposes? 1355217388 M * ard a network namespace is a single IP stack 1355217415 M * ard we do firewalling in another box dedicated to firewalling... nobody can get on the box 1355217422 Q * ensc|w Remote host closed the connection 1355217432 J * ensc|w ~ensc@www.sigma-chemnitz.de 1355217444 M * ard with network namespaces each DMZ has it's own ip stack, all routing to the firewall 1355217473 M * ard if you have a database vserver and a webapp vserver all in different network namespaces, the traffic will go through the firewall 1355217504 M * ard the database vserver and webapp vserver cannot reach eachother in any other way (except by means of a kernel exploit) 1355217545 M * fleischergesell you're talking about guests sharing the same hosts, do you? 1355217561 M * ard This makes things easy: the host doesn't need firewalling, since it has its own namespace, the guests have their seperate namespaces 1355217563 M * ard yes 1355217565 M * ard same iron 1355217600 M * fleischergesell well, that all sounds very well thought through, thank you 1355217607 M * ard If you have external firewalls (because of scale) that's the way to go 1355217623 M * ard you might need some patches for util-vserver though ;-) 1355217629 M * ard 3 lines or so 1355217692 M * fleischergesell well, we do not have this particular "problem" and are normally perfectly fine having the guests on one single hosts beeng able to reach each other directly 1355217719 M * fleischergesell no guest gets an external ip anyway, we nat anything 1355217786 M * ard we do too, but we have > 130 networks ;-) 1355217795 M * ard you can't firewall that sanely :-) 1355217804 M * fleischergesell Hehe, we're (luckily) not that big, yet ;-) 1355217808 M * ard or you can't firewall that, and keep your sanity :-) 1355217864 M * ard for my hobby company I do not use network namespaces (yet), but I am planning to do so... 1355217870 M * fleischergesell So for our little setup, do you think it is adviseable to have a single virtual interface for all guests? or rather assign each guest an individual inteface? 1355217875 M * ard you can have seperate firewall rulesets in a network namespace 1355217907 M * ard If I do not seperate namespaces I put all IP's on lo 1355217910 M * daniel_hozac assigning each guest a dummyX interface is just a waste. 1355217923 M * ard what daniel_hozac said 1355217930 M * daniel_hozac in general, interfaces matter very little to the Linux kernel. 1355217952 M * ard you need a dummy interface if you have software that uses mac addresses for licensing, like zend-platform 1355217970 M * fleischergesell well, we do not have that, fortunately 1355217976 M * ard for ipv6 you need them though, or you need to have a network routed to your host 1355218022 M * ard for zend platform I used to create a dummy with mac address 00:00:00:00:00:01, buy enough licenses, and install only 1 :-) 1355218033 M * fleischergesell hehe 1355218041 M * ard fortunately we have phased out zend-platform 1355218050 J * thierryp_ ~thierry@zankai.inria.fr 1355218063 M * ard all scripts are 0777 and must be run by root.... 1355218066 M * fleischergesell I think we have an ipv6 /56 or something routed to the host, so that should be no problem. Guess we're going with one single dummy interface for all hosts 1355218074 M * ard you don't want a security exploit like that 1355218082 N * Bertl_zZ Bertl 1355218086 M * Bertl morning folks! 1355218089 M * fleischergesell morning 1355218106 M * ard Bertl : it's time to sleep! It's way to early for you! :-) 1355218131 A * ard didn't have any real sleep due to force feeding a cat 1355218140 M * fleischergesell Berlt: Guy- said that you dislike the idea of having one single virtual interface (like dummy0) for all guests on one host - could you elaborate why? 1355218148 J * bonbons ~bonbons@2001:960:7ab:0:70ac:447c:3743:4b36 1355218204 M * ard IPv4 doesn't really think in interfaces, there is a single ip stack with addresses on it, for arp related purposes you can bind addresses and networks to an interface 1355218247 M * ard there is one exception though: putting 10.0.0.0/8 on your lo will make your host think that he has 16M ip addresses... lo doesn't work with networks... 1355218293 M * fleischergesell I must say I'm not really sold on using lo for all this anyway 1355218309 M * ard IPv6 is a different problem since it needs the ip and network on the right interface due to neighbour discovery... 1355218320 M * ard well, it's easy: 1355218366 M * Bertl it's fine to put guest IPs on dummy0 if you prefer that over using eth0 or lo, but do not assume that anything will actually _use_ that interface 1355218375 M * ard echo $vservername > interfaces/0/name;echo 32 > interfaces/0/mask;echo lo > interfaces/0/dev;echo $ip > interfaces/0/ip 1355218396 M * Guy- fleischergesell: I think I remember now what one of the problems was 1355218421 M * Bertl the common misconception that dummy0 'is used' for the guest(s) is what I primarily dislike about 'using' dummy interfaces 1355218430 M * Guy- in certain patch versions (or with certain settings?) the guests were unable to send over eth0 if they had only been assigned IPs on dummy0 1355218471 M * ard you can make some routing booboo's if you are going to use dummy0 1355218510 M * Guy- Bertl: I only started using dummy0 to avoid shooting myself in the foot - with eth0, if the host and a guest share the primary IP of eth0, and you take the guest down, it's too easy to take eth0 down with it 1355218535 M * fleischergesell I think we like the dummy interfaces because when we once had a guest with NET_ADMIN using eth0... well you can guess what happend when we shutdowned it ;-) 1355218537 M * ard That's why I use lo, and label the ip's accordingly 1355218560 M * Guy- after this happened once, I decided to eliminate the possibility of making this particular mistake 1355218580 Q * thierryp_ Read error: Connection reset by peer 1355218581 M * fleischergesell so did we and thats why we started to assign each guest an individual interface 1355218634 M * ard if you do not have to many guests you can always assing them a macvlan, but I don't know if util-vserver support is up to par with the latest and greatest features 1355218731 M * ard In those cases that I need a vserver with extra capabilities, I actually use veth, a bridge and put them in a seperate network namespace 1355218766 M * ard unless they will be completely alone, then they can have the full vlan device 1355218785 M * ard but instead of a bridge and a veth, giving them a macvlan in bridge mode ought to work too 1355218811 M * ard I use these things for dhcp servers 1355218845 M * ard (and a wireless network backbone) 1355218894 M * Bertl Guy-: that's what 'promote secondaries' is for :) 1355218900 J * thierryp ~thierry@eduroam-246a.sophia.inria.fr 1355218916 M * Guy- Bertl: that's a good workaround as long as there are secondaries to promote :) 1355218935 M * daniel_hozac if you're sharing the main IP, you shouldn't have given it to the guest entirely. 1355218944 M * Guy- daniel_hozac: I know 1355218944 M * daniel_hozac you should have set it as nodev. 1355218949 M * ard But most of them have the described setup: a vlan holder vserver with a single "dummy" process, and normal vservers sharing the namespace of the vlanholder vserver, and having a seperate network context. 1355218960 M * Guy- it was a mistake that was easy to make, so I'm trying to avoid it 1355218997 M * Bertl as I said, dummy0 is fine, as long as you do not assume that it is actually used for anything except 'holding' the IP 1355219045 M * ard But if you assign it a network on dummy0, you will not be able to reach anything outside the host within that network... 1355219065 M * ard because it will be routed to dummy0 ;-) 1355219082 M * fleischergesell As I said, we nat things to and from outside anyway 1355219097 M * fleischergesell no guest can talk to outside without some nat rules 1355219105 M * ard for me the outside is on the other side of the firewall ;-) 1355219111 M * fleischergesell hehe 1355219125 M * Bertl ard: yes, that is the 'normal' routing behaviour 1355219265 M * ard But on a single host setup, the firewalling is on the host. I have that too. And I block everything going out unless somebody can specify why it should be open. And then I block it again after they have some extra irc client helpers running (website exploited etc...) 1355219292 M * ard I even have outgoing port 80 go to an outbound-proxy vserver with squid3 installed 1355219384 A * ard is going to look again to the chistmas present Bertl gave us last week.. 1355219419 M * fleischergesell Thank you very much for all the advise and discussion folks, very helpful. 1355220559 P * fleischergesell 1355220730 J * nkukard ~nkukard@41-133-139-74.dsl.mweb.co.za 1355221516 J * clopez ~clopez@fanzine.igalia.com 1355222160 Q * thierryp Remote host closed the connection 1355222210 J * thierryp ~thierry@zankai.inria.fr 1355222309 Q * imachine Quit: Reconnecting 1355222311 J * imachine ~imachine@ip-178-216-200-235.e24cloud.com 1355222349 Q * imachine 1355222356 J * imachine ~imachine@ip-178-216-200-235.e24cloud.com 1355222375 M * imachine ;( no revdns updates on irc yet 1355223113 M * sid3windr tom@magic:~$ host ip-178-216-200-235.e24cloud.com 1355223113 M * sid3windr ip-178-216-200-235.e24cloud.com has address 178.216.200.235 1355223113 M * sid3windr tom@magic:~$ host 178.216.200.235 1355223113 M * sid3windr 235.200.216.178.in-addr.arpa domain name pointer ip-178-216-200-235.e24cloud.com. 1355223126 M * sid3windr looks like it's right where it's supposed to be on irc ;) 1355223353 J * thierryp_ ~thierry@zankai.inria.fr 1355223353 Q * thierryp Read error: Connection reset by peer 1355223602 Q * fisted Remote host closed the connection 1355223663 J * fisted ~fisted@xdsl-78-35-80-95.netcologne.de 1355225976 Q * ircuser-1 Ping timeout: 480 seconds 1355227657 J * nou Chaton@causse.larzac.fr.eu.org 1355227896 M * Bertl off for now .. bbl 1355227902 N * Bertl Bertl_oO 1355228972 Q * Wonka Read error: Connection reset by peer 1355229863 J * Wonka produziert@chaos.in-kiel.de 1355230505 Q * Aiken Remote host closed the connection 1355232797 J * Ghislain1 ~aqueos@adsl1.aqueos.com 1355232797 Q * Ghislain Read error: Connection reset by peer 1355232901 Q * imachine Quit: leaving 1355232903 Q * Ghislain1 Read error: Connection reset by peer 1355232923 Q * fback Ping timeout: 480 seconds 1355232951 J * Ghislain ~aqueos@adsl1.aqueos.com 1355236018 M * Guy- Bertl: does xfs cow work again with patch-3.6.9-vs2.3.4.4.diff? if so, woot! 1355236065 M * Bertl_oO yes, it is supposed to be completely functional 1355236099 M * Guy- \o/ 1355236107 M * Bertl_oO but you might want to go with patch-3.6.10-vs2.3.4.5.diff 1355236129 M * Guy- can't see that in Experimental yet 1355236138 M * Bertl_oO look again 1355236158 M * Guy- ah, just arrived :) 1355236201 A * Guy- hugs the new patch 1355236719 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net 1355238505 Q * clopez Read error: Operation timed out 1355238580 N * Bertl_oO Bertl 1355239202 J * fback fback@red.fback.net 1355240399 M * ard But where is the 3.7 patch? :-) 1355240498 M * Bertl on the way ... but testing is required :) 1355240575 M * Ghislain testing is so ninety's, jsut roll out ! :p 1355240599 M * Bertl like the no* patches for 3.6, right? 1355240615 M * Ghislain i think that you should not spend time on 3.7 as 3.8 will be here by tomorow morning anyway ^^ 1355240621 M * Ghislain yes lol 1355241017 M * Ghislain just call bug features, that what we do :) 1355241031 M * Ghislain evry SERIOUS software company does it 1355241068 Q * ensc Remote host closed the connection 1355241069 M * Bertl how lucky for you that we are not a software company :) 1355241381 J * ensc ~irc-ensc@p54ADEA42.dip.t-dialin.net 1355243765 M * Ghislain you'rrree dam right ! :) 1355244231 M * Bertl arrrr! :) 1355244309 J * clopez ~clopez@242.17.60.213.dynamic.mundo-r.com 1355245488 Q * mcp Quit: ZNC - http://znc.sourceforge.net 1355246096 J * mcp ~mcp@wolk-project.de 1355246697 Q * thierryp_ Remote host closed the connection 1355250815 Q * fisted Quit: leaving 1355255453 J * hijacker_ ~hijacker@cable-84-43-134-121.mnet.bg 1355257682 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1355257736 J * Walex ~Walex@78-86-80-54.zone2.bethere.co.uk 1355258177 J * cuba33ci_ ~cuba33ci@114-25-203-78.dynamic.hinet.net 1355258530 Q * cuba33ci Ping timeout: 480 seconds 1355258535 N * cuba33ci_ cuba33ci 1355259478 J * geos_one ~chatzilla@80.123.185.198 1355263034 J * thierryp ~thierry@home.parmentelat.net 1355263495 Q * hijacker_ Quit: Leaving 1355263558 Q * clopez Ping timeout: 480 seconds 1355266001 J * imachine ~imachine@178.216.200.235 1355267200 J * fisted ~fisted@xdsl-87-78-186-180.netcologne.de 1355267614 Q * nicholi Quit: leaving 1355267925 Q * _urbee Ping timeout: 480 seconds 1355267937 J * trippeh_ atomt@t-1000.ugh.no 1355267974 Q * trippeh Read error: No route to host 1355268210 M * Bertl ard: let me know how the 3.7 patch does, will'ya? :)