1311640436 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1311641093 Q * puck Ping timeout: 480 seconds
1311644713 Q * ccxCZ Ping timeout: 480 seconds
1311645751 J * ccxCZ ~ccxCZ@193.209.forpsi.net
1311646079 Q * hparker Quit: Quit
1311649754 Q * Eruquen Ping timeout: 480 seconds
1311650683 J * Janno Janno@server3.raumopol.de
1311654736 J * sannes ~ace@cm-84.209.106.118.getinternet.no
1311657603 J * puck ~puck@leibniz.catalyst.net.nz
1311660751 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no
1311661599 Q * derjohn_mob Ping timeout: 480 seconds
1311662513 J * ghislain ~AQUEOS@adsl2.aqueos.com
1311662966 M * padde the issue I had yesterday was actually a problem with the router configuration after all... had double checked it, but still missed the mistake - this morning it occurred to me while in the shower. should always sleep over this kind of issues ;)
1311663021 J * derjohn_mob ~aj@213.238.45.2
1311664539 J * kir ~kir@swsoft-msk-nat.sw.ru
1311668260 J * ncopa_ ~ncopa@ti0143a340-0173.bb.online.no
1311668718 Q * ncopa Ping timeout: 480 seconds
1311668737 M * SwenTjuln daniel_hozac: Just for the record: Yesterday I complained that your kernel does not work with recent util-vserver - I was wrong. It was clean install of CentOS6 and I forgot to disable SELinux. So it was SELinux preventing util-vserver to work properly.
1311668828 M * daniel_hozac yeah, that'll do it.
1311669107 M * SwenTjuln so now i have RPMs for working 2.6.38.8 with VServer patch for EL6 if anyone interested
1311669120 M * SwenTjuln (kernel taken from Fedora 15)
1311670864 J * clopez ~clopez@155.99.117.91.static.mundo-r.com
1311671907 Q * ntrs Ping timeout: 480 seconds
1311672374 J * ntrs ~ntrs@vault08.rosehosting.com
1311672905 M * DelTree \_o< ~ Coin ~ >o_/
1311674240 N * Bertl_zZ Bertl
1311674244 M * Bertl morning folks!
1311674733 M * SwenTjuln morning
1311674796 M * SwenTjuln Bertl: arn't you from Austria? Little late to be morning here :D
1311675059 M * Bertl it's morning when I wake up :)
1311677093 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com
1311677526 M * SwenTjuln :D
1311677572 M * SwenTjuln true that...a Einstein once said: "Everything is relative"
1311677578 M * SwenTjuln *as
1311677719 P * kir Leaving.
1311680072 Q * mike Ping timeout: 480 seconds
1311684564 Q * clopez Ping timeout: 480 seconds
1311685227 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1311687851 J * yang yang@yang.netrep.oftc.net
1311687900 M * yang hi is there a big problem of moving i686 guests on an amd64 virtualised server?
1311687935 M * yang what should i read about it
1311687953 M * Bertl not really, just set the personality correctly
1311687987 M * yang any url for the hint
1311688046 M * Bertl http://linux-vserver.org/Frequently_Asked_Questions#32_vs_64_Bit.3F_What_should_I_take.3F
1311688082 M * yang thanks bertl
1311688628 J * ryker ~Adium@c-76-16-115-27.hsd1.in.comcast.net
1311688697 M * Bertl np
1311689759 J * SkyNet2000 ~SkyNet200@71-81-25-51.dhcp.gwnt.ga.charter.com
1311690261 M * Guy- yang: in my experience, not even setting the personality is required, it just works
1311690284 M * Guy- I have dozens of i386 guests on amd64 (with an amd64 kernel), no problems
1311690312 M * pmjdebruijn we have amd64 guests on amd64, but the guests are running some i386 apps though
1311690360 M * Bertl yes, usually it works, but apps checking for the architecture will get the wrong information without setting the personality
1311690393 M * Bertl 'uname -a' vs 'linux32 uname -a' for example
1311690488 M * Guy- sure, but such apps are apparently very rare
1311691002 J * clopez ~clopez@155.99.117.91.static.mundo-r.com
1311692488 J * dowdle ~dowdle@scott.coe.montana.edu
1311693484 Q * ntrs Ping timeout: 480 seconds
1311693973 J * ntrs ~ntrs@vault08.rosehosting.com
1311696882 J * bonbons ~bonbons@2001:960:7ab:0:8579:63f9:4237:440c
1311697274 A * jamieson is back
1311697283 M * jamieson sorry about the away msg, will fix my nick from now on ;-)
1311697295 M * jamieson Is it still necessary to set barrier?
1311697329 M * jamieson I.e http://linux-vserver.org/Secure_chroot_Barrier#Solution:_Secure_Barrier
1311697347 M * jamieson do we still need to setattr barrier on vserver basedir?
1311697412 M * jamieson @Bertl, is this still needed? Talk: http://linux-vserver.org/Talk:Secure_chroot_Barrier indicates that Linux 2.6 isn't really necessary..
1311697439 M * jamieson s/Lin.*2.6/on & it/
1311697500 M * jamieson Ah Bertle, this is IRC not twitter
1311697584 Q * ncopa_ Quit: Leaving
1311697825 J * tnkflx ~laurens@static.70.47.40.188.clients.your-server.de
1311697827 M * tnkflx evenin'
1311698017 M * tnkflx I heard that some people here where able to set up vserver with network namespaces, but didn't write it down somewhere? Can someone enlighten me on how to do this?
1311698327 M * Bertl jamieson: with recent kernels, it's not strictly necessary to set the barrier, but it's usually a good idea to set it anyway (increased security)
1311698413 Q * clopez Ping timeout: 480 seconds
1311698420 M * Bertl off for now .. bbl
1311698425 N * Bertl Bertl_oO
1311698562 M * arekm tnkflx: http://www.pld-linux.org/Docs/Vserver#head-23617c6842424b1f0ff988634b39000b6137f60c
1311698750 M * arekm tnkflx: unfortunately no real support in util-vserver for that
1311699121 M * tnkflx aha, I'll have a look at that
1311699123 M * tnkflx ty
1311699212 Q * derjohn_mob Ping timeout: 480 seconds
1311700162 M * jamieson Bertl_oO: ah ok thanks!
1311700767 Q * hparker reticulum.oftc.net resistance.oftc.net
1311700767 Q * nkukard reticulum.oftc.net resistance.oftc.net
1311700767 Q * AndrewLee reticulum.oftc.net resistance.oftc.net
1311700767 Q * MooingLemur reticulum.oftc.net resistance.oftc.net
1311700767 Q * disposable reticulum.oftc.net resistance.oftc.net
1311700767 Q * ser reticulum.oftc.net resistance.oftc.net
1311700767 Q * glen reticulum.oftc.net resistance.oftc.net
1311700767 Q * minecraftfan reticulum.oftc.net resistance.oftc.net
1311700767 Q * FloodServ reticulum.oftc.net resistance.oftc.net
1311700767 Q * jamieson reticulum.oftc.net resistance.oftc.net
1311700767 Q * ircuser-1 reticulum.oftc.net resistance.oftc.net
1311700767 Q * brc reticulum.oftc.net resistance.oftc.net
1311700767 Q * quasisane reticulum.oftc.net resistance.oftc.net
1311700767 Q * tam reticulum.oftc.net resistance.oftc.net
1311700767 Q * jrayhawk reticulum.oftc.net resistance.oftc.net
1311700767 Q * tty234 reticulum.oftc.net resistance.oftc.net
1311700767 Q * SkyNet2000 reticulum.oftc.net resistance.oftc.net
1311700767 Q * ghislain reticulum.oftc.net resistance.oftc.net
1311700767 Q * thal reticulum.oftc.net resistance.oftc.net
1311700767 Q * DreamerC reticulum.oftc.net resistance.oftc.net
1311700767 Q * ntrs reticulum.oftc.net resistance.oftc.net
1311700767 Q * dowdle reticulum.oftc.net resistance.oftc.net
1311700767 Q * ryker reticulum.oftc.net resistance.oftc.net
1311700767 Q * FIChTe reticulum.oftc.net resistance.oftc.net
1311700767 Q * click reticulum.oftc.net resistance.oftc.net
1311700767 Q * nicholi reticulum.oftc.net resistance.oftc.net
1311700767 Q * FireEgl reticulum.oftc.net resistance.oftc.net
1311700767 Q * kshannon reticulum.oftc.net resistance.oftc.net
1311700767 Q * tolkor reticulum.oftc.net resistance.oftc.net
1311700767 Q * micah reticulum.oftc.net resistance.oftc.net
1311700807 J * tty234 telex@anapnea.net
1311700807 J * tam ~tam@says.screwallofyoubitches.com
1311700807 J * jrayhawk ~jrayhawk@nursie.omgwallhack.org
1311700807 J * quasisane ~sanep@c-76-24-80-97.hsd1.nh.comcast.net
1311700807 J * thal ~thalunil@walledcity.de
1311700807 J * DreamerC ~DreamerC@122-116-181-118.HINET-IP.hinet.net
1311700807 J * ghislain ~AQUEOS@adsl2.aqueos.com
1311700807 J * SkyNet2000 ~SkyNet200@71-81-25-51.dhcp.gwnt.ga.charter.com
1311700807 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1311700807 J * nkukard ~nkukard@41-133-248-130.dsl.mweb.co.za
1311700807 J * AndrewLee ~andrew@n201.enc.hlc.edu.tw
1311700807 J * MooingLemur ~troy@ipv4.pinchaser.com
1311700807 J * disposable disposable@shell2.vps.websupport.sk
1311700807 J * glen ~glen@scratchy.delfi.ee
1311700807 J * minecraftfan ~minecraft@74.63.212.88
1311700807 J * ser ~ser@host1.tldp.ibiblio.org
1311700807 J * FloodServ services@services.oftc.net
1311700948 J * ntrs ~ntrs@vault08.rosehosting.com
1311700948 J * dowdle ~dowdle@scott.coe.montana.edu
1311700948 J * ryker ~Adium@c-76-16-115-27.hsd1.in.comcast.net
1311700948 J * FIChTe ~fichte@bashpipe.de
1311700948 J * click click@ti0127a340-0054.bb.online.no
1311700948 J * nicholi ~nicholi@12.232.116.66
1311700948 J * FireEgl ~FireEgl@173-16-9-3.client.mchsi.com
1311700948 J * kshannon ~kris@122.252.14.166
1311700948 J * tolkor ~rj@tdream.lly.earlham.edu
1311700948 J * micah ~micah@micah.riseup.net
1311701048 J * jamieson ~jamieson@71.11.175.78
1311701048 J * ircuser-1 ~ircuser-1@025.205-93-216-nokia-dsl.dynamic.surewest.net
1311701048 J * brc ~bruce@72.20.27.65
1311701759 J * manana ~mayday090@178.162.120.195
1311703756 J * eyck ~eyck@77.79.198.66
1311705514 N * Bertl_oO Bertl
1311705517 M * Bertl back now ...
1311705538 M * Bertl arekm: patches are welcome IIRC
1311705589 M * arekm yes, I welcome such patches, too
1311705615 M * Bertl you win today :)
1311705958 Q * hparker Quit: Quit
1311706003 Q * ensc Ping timeout: 480 seconds
1311707007 Q * manana Remote host closed the connection
1311707174 J * manana ~mayday090@178.162.120.195
1311707377 M * tnkflx arekm: That's all I need to do so that each guest has its own ip?
1311707414 M * tnkflx arekm: suppose that all guests have a different subnet from the host. But either are public addresses, everything will work?
1311707616 M * arekm tnkflx: that's pld specific. It creates pair of "connected" network devices. One end is on host, one in guest. You can configure whatever you like treating these as normal devices
1311707835 M * tnkflx arekm: Hmmm, ok. I'm on Slackware. Just trying to configure each guest with its own public ip as well as the host...
1311707938 M * Bertl tnkflx: no need for network namespaces for that, as I already explained
1311708045 M * tnkflx Bertl: You said it was 1 of the possibilities ;-) So just let the host act as a gateway then?
1311708089 M * Bertl no, as I already pointed out, there is no routing involved
1311708133 M * Bertl you simply configure all the public IPs on the host, and then assign them to the appropriate guests
1311708176 M * tnkflx ah ok, sorry, I might have misread something...
1311708205 M * tnkflx Bertl: assigning to host with ip addr etc?
1311708238 M * Bertl what is your concrete setup, feel free to replace IPs with placeholders
1311708249 M * Bertl i.e. what IPs, what guests ...
1311708253 M * tnkflx Bertl: ok, sec
1311708316 M * tnkflx Suppose I have something like this:
1311708320 M * tnkflx Host: 10.0.0.1, gw: 10.0.0.254
1311708324 M * tnkflx Guest1: 192.168.0.1, 192.168.0.254
1311708328 M * tnkflx Guest2: 192.168.0.2, 192.168.0.254
1311708339 M * tnkflx Guest3: etc :)
1311708419 M * tnkflx But all of them are routable via eth0 of the host
1311708740 M * Bertl okay, so far no public IP, yes?
1311709090 M * tnkflx well, I could replace the IPs with placeholders :)
1311709096 M * tnkflx sec, I'll change it ;)
1311709262 M * tnkflx Host: 2.2.2.70, gw 2.2.2.65
1311709266 M * tnkflx Guest 1: 1.1.1.193, gw: 1.1.1.192
1311709271 M * tnkflx Guest 2: 1.1.1.194, gw: 1.1.1.192
1311709289 M * tnkflx The 1.1.1 en 2.2.2 are in place of the real octets 
1311709368 M * tnkflx Does that make it clearer?
1311709379 M * Bertl so all of them are public now?
1311709401 M * tnkflx Yes, all ip addresses, host + guests, are public
1311709408 M * Bertl okay
1311709416 M * Bertl so that setup is rather simple then
1311709440 M * Bertl either configure all IPs on the host, or let util-vserver bring the guest IPs up/down
1311709469 M * Bertl then create two routing tables, one for the host only IPs 2.2.2.x and one for the guest IPs 1.1.1.x
1311709490 M * Bertl assign the packets based on source IP to the according routing table
1311709493 M * Bertl that's it
1311709658 M * tnkflx the routing tables should be created on the host right?
1311710034 M * Bertl yep
1311710107 M * Bertl http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/
1311710142 M * tnkflx Bertl: Heh, was looking at that, thanks :)
1311710961 Q * sannes Remote host closed the connection
1311711615 M * tnkflx Bertl, the routing table for the host can just be the 'normal' table right?
1311711661 M * tnkflx I mean the main routing table
1311711762 M * Bertl yep
1311712266 M * tnkflx Hmmm, made an error in my previous example. The gateway of the guest subnet is statically routed on the host IP address
1311712303 M * tnkflx IN the routing tables: make sure the gw of the new ip subnet is het gateway of the host?
1311712309 M * daniel_hozac no
1311712314 M * daniel_hozac that makes no sense.
1311712620 M * tnkflx what exactly?
1311712669 M * daniel_hozac the host cannot be its own gateway.
1311712715 M * tnkflx No no, the host has a different gateway. But the other subnet is statically routed to the host.
1311712782 M * daniel_hozac how?
1311712833 J * cuba33ci_ ~cuba33ci@111-240-166-14.dynamic.hinet.net
1311713007 J * ksn ~ksn@197.169.19.195
1311713068 M * tnkflx I do not know the specifics, this is a rented server...
1311713074 M * tnkflx http://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen/en
1311713146 M * tnkflx I guess on the hoster setup, they route the ip addresses of the other subnet directly to the host ip address...
1311713188 Q * cuba33ci Ping timeout: 480 seconds
1311713196 N * cuba33ci_ cuba33ci
1311713221 Q * bonbons Quit: Leaving
1311713236 M * Bertl well, how you set up the IPs on the host doesn't matter for Linux-VServer 
1311713259 M * Bertl i.e. set it up without even thinking about or using Linux-VServer specifics
1311713291 M * Bertl once all the IPs you want to use (for hosts and guests) work, Linux-VServer comes into play
1311713811 Q * BenG Remote host closed the connection
1311714236 Q * ksn Quit: leaving
1311714382 M * tnkflx Bertl: That's the thing, the host would only have 1 ip, and the guests the other subnet...
1311714429 M * Bertl well, if you or your hoster insists on this setup, you have to use network namespaces
1311714513 M * tnkflx Which brings us back to my initial mail about that :)  Or am I missing something?
1311714544 M * Bertl for me it looks like the IPs are just staticall routed to the host IP
1311714561 M * Bertl so if the host actually uses those IPs, everything should be fine IMHo
1311715034 M * tnkflx Yes, they are. The host itself doesn't use them, but the guests do. But that's ok then?
1311715198 M * Bertl sure, that's the idea ...
1311715222 M * tnkflx Ok, gonna go to bed now, will try again in the morning. No idea what I did wrong then :)
1311715229 M * tnkflx Thanks for the help and patience ;)
1311715439 J * derjohn_mob aj@tmo-041-64.customers.d1-online.com
1311715638 M * Bertl you're welcome!
1311717334 Q * manana Remote host closed the connection
1311719605 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1311722646 Q * ghislain Quit: Leaving.
1311723417 Q * dowdle Remote host closed the connection
1311723863 Q * PowerKe Ping timeout: 480 seconds
1311724148 Q * hparker Quit: Quit