1241399159 J * _gh_ ~gerrit@c-71-193-204-84.hsd1.or.comcast.net
1241399461 Q * FireEgl Remote host closed the connection
1241400314 J * FireEgl Proteus@2001:470:e056:1:4::
1241405137 J * scientes ~scientes@97-113-122-26.tukw.qwest.net
1241406982 Q * Guest1435 Ping timeout: 480 seconds
1241407162 J * Mooo ~troy@shells195.pinchaser.com
1241410401 Q * scientes Remote host closed the connection
1241411105 J * geb ~geb@earth.gebura.eu.org
1241412117 J * scientes ~scientes@97-113-122-26.tukw.qwest.net
1241413934 J * scientes_ ~scientes@97-113-122-26.tukw.qwest.net
1241413944 Q * scientes_ Read error: Connection reset by peer
1241413945 J * scientes_ ~scientes@97-113-122-26.tukw.qwest.net
1241414438 Q * geb Ping timeout: 480 seconds
1241414711 Q * scientes_ Quit: scientes_
1241415264 J * sharkjaw ~gab@149-240-82.oke2-bras6.adsl.tele2.no
1241415790 J * dna ~dna@186-204-103-86.dynamic.dsl.tng.de
1241416354 Q * zbyniu Quit: leaving
1241416495 Q * sharkjaw Remote host closed the connection
1241416765 J * sharkjaw ~gab@149-240-82.oke2-bras6.adsl.tele2.no
1241417236 J * zbyniu ~zbyniu@ip-62.181.188.13.static.crowley.pl
1241418164 J * davidkarban ~david@193.85.217.71
1241418420 J * cluk ~cluk@p5B17F731.dip.t-dialin.net
1241419077 J * ousado_ ~johnny@frnk-5f744ef5.pool.einsundeins.de
1241419479 J * balbir_ ~balbir@59.145.136.1
1241419576 Q * scientes Ping timeout: 480 seconds
1241422749 Q * yarihm Quit: Leaving
1241423165 J * harobed ~harobed@pda57-1-82-231-115-1.fbx.proxad.net
1241424460 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1241424990 J * cga ~weechat@62.196.2.6
1241425732 J * ktwilight_ ~ktwilight@21.240-64-87.adsl-dyn.isp.belgacom.be
1241425835 N * Bertl_zZ Bertl
1241425843 M * Bertl morning folks!
1241426012 Q * ktwilight__ Ping timeout: 480 seconds
1241426308 M * pmjdebruijn oh sweet
1241426320 M * pmjdebruijn 2.6.29.2-vs2.3.0.36.10 is out :)
1241426436 M * Bertl it is? :)
1241426474 M * Wonka .oO( should I upgrade to that one from 2.6.22.9-vs2.3.0.26.4 ? )
1241426527 M * Bertl well, at least updating to 2.6.22.19 plus latest patch would be advised :)
1241426558 J * Pazzo ~ugelt@reserved-225136.rol.raiffeisen.net
1241426559 M * Bertl but if you go for the 2.6.29.2-vs2.3.0.36.10, don't forget the delta from three days ago
1241426705 M * Wonka hm, where's that?
1241426740 M * sid3windr 2 blocks down the road, turn left at the coffee shop, straight on to the gas station, ask again there
1241426787 M * Wonka do you mean this one? http://vserver.13thfloor.at/Experimental/delta-ptimer-fix01.diff
1241426849 M * Bertl yep, right below the patch
1241426861 M * Bertl (or above, if you use the reverse sorted listing)
1241426999 J * pmenier ~pme@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr
1241427362 M * Wonka 'k, will try in some days, maybe
1241427396 J * kir ~kir@swsoft-msk-nat.sw.ru
1241427498 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net
1241427724 J * friendly ~friendly@ppp118-208-246-80.lns10.mel6.internode.on.net
1241427751 M * pmjdebruijn Bertl: oh... 
1241427783 Q * balbir_ Ping timeout: 480 seconds
1241427968 A * pmjdebruijn will be testing 2.9.29.2-vs2.3.0.36.10 for as bit as well
1241428341 Q * ktwilight_ Remote host closed the connection
1241428588 J * balbir_ ~balbir@59.145.136.1
1241429338 J * ktwilight ~ktwilight@21.240-64-87.adsl-dyn.isp.belgacom.be
1241431153 Q * balbir_ Ping timeout: 480 seconds
1241431657 J * geb ~geb@earth.gebura.eu.org
1241431825 M * geb hi
1241431832 M * Bertl hey! :)
1241431959 J * balbir_ ~balbir@59.145.136.1
1241432117 M * geb how are u ? :)
1241432183 Q * cga Quit: got a DELL??? update you BIOS with http://github.com/cga/dellbiosupdate.sh/tree/master ;)
1241432447 J * cga ~weechat@62.196.2.6
1241433744 Q * geb Quit: Quitte
1241434198 J * geb ~geb@earth.gebura.eu.org
1241435646 Q * geb Remote host closed the connection
1241435891 J * geb ~geb@AOrleans-253-1-14-55.w92-140.abo.wanadoo.fr
1241436122 J * Keeper longhorn40@94.50.32.192
1241436189 Q * geb 
1241436194 M * Bertl nap attack ... bbl
1241436204 N * Bertl Bertl_zZ
1241436349 Q * Keeper 
1241436928 J * morphium ~morphium@morphium.user.oftc.net
1241436929 M * morphium Hi there
1241437012 M * morphium I want to setup my ha environment for https
1241437026 M * morphium http is working fine, https isn't
1241437058 M * morphium ldirectord-checks appear in the apache logs for the https entry
1241437068 M * morphium and ipvsadm shows the hosts with weight 1
1241437098 M * morphium if i connect directly to one of the https-servers, that works, too. but not through the heartbeat managed loadbalancer
1241437118 M * morphium http works, though
1241437222 M * mnemoc morphium: you probably want to talk at linux-vs's (ipvs) channel
1241437299 M * mnemoc (if there is any)
1241437333 M * mnemoc #linux-ha on irc.freenode.net may be a good place for that
1241437423 M * morphium thanks
1241439586 J * jrdnyquist ~jrdnyquis@slayer.caro.net
1241440674 Q * friendly Quit: Leaving.
1241441136 J * Piet ~piet@tor-irc.dnsbl.oftc.net
1241442793 Q * balbir_ Ping timeout: 480 seconds
1241444111 J * thierryp ~thierry@vis192b.inria.fr
1241445602 Q * sharkjaw Remote host closed the connection
1241445618 Q * dwery Read error: Connection reset by peer
1241445702 J * dwery ~dwery@93-39-57-60.ip74.fastwebnet.it
1241447446 Q * bonbons Ping timeout: 480 seconds
1241448068 N * Bertl_zZ Bertl
1241448107 M * Bertl morphium: while this channel is dedicated to Linux-VServer (not LVS) it might as well be useful for your HA setup at some point ...
1241448181 M * Bertl FYI: Linux-VServer is an isolation solution/mechanism to put several servers/virtual guests on the same physical machine (more details @ linux-vserver.org)
1241448510 J * scientes ~scientes@97-113-122-26.tukw.qwest.net
1241448645 J * geb ~geb@AOrleans-253-1-14-55.w92-140.abo.wanadoo.fr
1241448763 Q * SauLus Quit: Changing server
1241448806 J * saulus ~saulus@c193123.adsl.hansenet.de
1241448945 Q * nenolod Read error: Operation timed out
1241449077 Q * cga Quit: got a DELL??? update you BIOS with http://github.com/cga/dellbiosupdate.sh/tree/master ;)
1241449233 J * Keeper longhorn40@94.50.32.192
1241449280 M * Keeper Hi
1241449318 J * cga ~weechat@62.196.2.6
1241449319 M * Bertl hey!
1241449423 M * Keeper Bertl: How are you?
1241449494 M * Bertl fine, thanks! and you?
1241449612 M * Bertl Keeper: you had a question about changing the cpuinfo last time, which wasn't understood as it seems ... basically all you have to do is to --bind mount a file onto the /proc entry in the guest namespace
1241449645 M * Bertl (the only problem right now is, that the secure mount feature of util-vserver doesn't support file type --bind mounts yet)
1241449694 M * Keeper Bertl: fine, so I want to mount
1241449740 M * Keeper Bertl: But it is not so important...
1241449741 Q * saulus Quit: leaving
1241449764 J * saulus ~saulus@c193123.adsl.hansenet.de
1241449805 Q * saulus 
1241449811 M * Keeper Bertl: I am now keen on testing new patches for the new kernel
1241449846 M * Bertl go ahead, get the latest one for 2.6.29.2 and the delta right below and you should be fine
1241449876 J * saulus ~saulus@c193123.adsl.hansenet.de
1241449967 M * Keeper I have Gentoo Kernel 2.6.28.9 + Vserver Patch = Excellent work
1241449990 M * Bertl fine too, but not the latest kernel :)
1241450219 M * Keeper Bertl: But this is the last stable kernel in Gentoo, decided that the best way ... I am so pleased with everything .. But there is one problem ... util-vserver-0.30.215-r3 not build
1241450229 J * hparker ~hparker@2001:470:1f0f:32c:290:96ff:fe50:40fa
1241450329 M * Bertl Keeper: maybe contact Hollow and ask him to update util-vserver (to a 0.30.216pre) or maybe just some unmasking is required ...
1241450467 J * nenolod nenolod@petrie.dereferenced.org
1241450620 M * Keeper Bertl: I am not against the test in your spare time, so it would be good if Gentoo will be available to new versions. I corrected the ebuild for util-vserver-0.30.215-r3, and saw that now there is not a mistake that I was prevented.
1241450735 M * Keeper Hollow: Hi
1241451000 M * Keeper Hollow: 	Fix please, ebuild for util-vserver-0.30.215-r3, it does not work, but the problems associated with the ebuild, I am transferring it to the Operlay and it works very well, I think it can be considered stable. If you have an opportunity to make a new ebuild for the new kernels
1241451085 M * Keeper Thanks to everyone who develops and supports this project
1241451115 Q * thierryp Remote host closed the connection
1241451286 M * Keeper Bertl: What would have worked Standard non-shared quota necessarily need to use LVM?
1241451548 Q * doener_ Ping timeout: 480 seconds
1241451873 J * giovanni ~giovanni@143.225.229.142
1241451883 M * giovanni hi everyone
1241451891 M * giovanni do you support a vserver Ubuntu 9.04?
1241452000 M * Keeper giovanni: http://linux-vserver.org/Installation_on_Ubuntu
1241452064 M * Keeper giovanni: If this will not help you, you can compile your own kernel
1241452335 M * Bertl giovanni: should be fine as guest and host system
1241452407 M * Bertl Keeper: for non-shared quota (as the name suggests) you need a separate partition for each quota domain (guest). that can be an lvm volume or a partition or even a loop mount
1241452462 M * giovanni ok, thanks guys
1241452520 Q * giovanni Quit: Sto andando via
1241452551 M * Keeper Bertl: It was thought that the loop will help but decided to clarify... thanks
1241452689 M * Keeper Bertl: good luck, thank you for the answers
1241452709 M * Bertl thanks, u2! and you're welcome!
1241452764 Q * cga Quit: got a DELL??? update you BIOS with http://github.com/cga/dellbiosupdate.sh/tree/master ;)
1241452808 Q * Keeper Quit: Keeper
1241453065 J * siretart ~siretart@apollon.tauware.de
1241453083 J * dowdle ~dowdle@scott.coe.montana.edu
1241453187 M * siretart hi. - quick question, how is linux vserver developed? is there a public git or svn or something so one can track the development?
1241454045 M * pmenier Hello
1241454127 M * pmenier is it safe to use patch-2.6.27.21 with kernel-2.6.27.22 . I try it and got just a few Hunk Succeeded http://paste.linux-vserver.org/12907
1241454351 M * Bertl pmenier: should be fine, just adjust the version in the Makefile
1241454373 M * pmenier ok, thanks a lot, Bertl.
1241454421 M * Bertl siretart: Linux-VServer is developed similar to the kernel, but we do not maintain a git repository, but upload the patches and deltas
1241454503 M * Bertl (see http://vserver.13thfloor.at/Experimental/)
1241454696 Q * harobed Ping timeout: 480 seconds
1241455007 Q * davidkarban Quit: Ex-Chat
1241455273 M * siretart Bertl: I see. so one has to track the website to be notified about updates, right?
1241455324 J * balbir_ ~balbir@122.172.20.159
1241455505 Q * Hawq Quit: leaving
1241455528 M * Bertl siretart: yep, kind of, but usually updates happen with new kernel releases ..
1241456170 J * thierryp ~thierry@home.parmentelat.net
1241456200 Q * thierryp Remote host closed the connection
1241456331 J * kcodyjr ~kcodyjr@c-24-34-80-195.hsd1.ma.comcast.net
1241456391 M * kcodyjr any chance of the vs-2.2.0.7 applying to, or being ported to, a recent kernel?
1241456478 M * kcodyjr alternately, how invasive/ill-advised would it be to update a production server to run vs-2.3.x.x
1241456530 M * Bertl kcodyjr: porting the vs2.2 series to a recent kernel would be a bad idea, as a lot of virtualization related stuff changed and Linux-VServer has been adapted to that
1241456576 M * Bertl kcodyjr: many folks are running vs2.3.x in production (I do so myself) so it can be considered working
1241456623 M * Bertl in any case, you should make sure to use the latest patch for each kernel release, as minor issues are still being ironed out
1241456670 M * kcodyjr understood. i'll probably have to play with patchsets - i assume they won't just apply cleanly to a gentoo-sources or hardened-sources tree.
1241456673 N * DoberMann[ZZZzzz] DoberMann[PullA]
1241456702 M * kcodyjr if you were taking the issue to your supervisor, would you push for just living with the older kernel, or would you push running 2.3?
1241456725 M * Bertl depends on how much gentoo changes, the Linux-VServer patches are quite unintrusive and lean/clean, so there shouldn't be too much collisions with distro changes nowadays
1241456741 M * kcodyjr i do see that there's still a vserver+grsec patch
1241456780 M * Bertl depends on what you need, if you are happy with the current kernel, and everything works as expected, then I would suggest to stick with it, no need to change a running system
1241456832 M * Bertl if you need 'new' features from recent kernels, go for 2.6.29, it seems to be quite useful already
1241456867 M * kcodyjr i've got two causes for change, against a system that seems to be running just fine: current linux-headers is 2.6.27 and i'm running 2.6.22-vs2.2.07, and i'm running a non-hardened kernel with a hardened userspace. kinda puts it on the fence, as i see it
1241456921 M * kcodyjr the hardware has been in production 2-3 years, i don't see the need for newer kernel features, i just prefer to stick with stuff that's still being actively supported by the distro, for security patches and such
1241456956 M * Bertl no idea if gentoo still supports 2.6.22 kernels, but I doubt they have been updated/fixed recently
1241456975 M * kcodyjr it's only available as the vserver-sources tree, which seems to stick with stable vs patches
1241457059 M * kcodyjr but one of the big indicators with gentoo is the linux-headers version. glibc expects to be running the same kernel or newer as the one it was compiled against
1241457126 M * kcodyjr though i've never seen it visibly blow up because of violating that. presumably glibc is smart enough to check for features actually being present.
1241457152 M * Wonka just came across http://lxc.sourceforge.net
1241457169 M * Wonka where's the big difference between linux vservers and lxc?
1241457329 M * sid3windr lxc = NIH syndrome ? :P
1241457372 M * Wonka i thought people from here pushed some of the namespace stuff...
1241457428 M * pmjdebruijn probably maturity for one
1241457442 M * pmjdebruijn lxc is completely based on the new in kernel api's for namespaces in everything
1241457448 M * pmjdebruijn if I'm not mistaken
1241457456 M * pmjdebruijn so it's bit more limited I guess
1241457509 J * thierryp ~thierry@home.parmentelat.net
1241457514 Q * thierryp 
1241457575 M * Bertl Wonka: once lxc (the mainline reimplementation of Linux-VServer and similar) is finished, only userspace tools will be left from Linux-VServer 
1241457589 M * Wonka Bertl: ah, that's what i wanted to hear
1241457606 M * Wonka and it sounds good in my ears :)
1241457650 M * Bertl the ro bind mounts, and the uts spaces are basically from Linux-VServer, although they had many iterations done by the folks from IBM
1241457747 M * kcodyjr but, upshot, the feature of having vservers is on the mainline track? that is most excellent.
1241457787 M * Bertl yes, after 7+ years, mainline realized that OS-level virtualization is a good thing :)
1241457789 M * Wonka ack, kcodyjr
1241457829 M * Bertl but my guess would be that it takes at least two more years to make it useable ... but we'll see :)
1241457852 M * kcodyjr i'm sure you'll be ahead of the kvm project.
1241458020 M * Bertl actually kvm is quite useable and stable already, we use it for Linux-VServer kernel development
1241458072 M * kcodyjr i use it as well, for gentoo build hosts and winxp instances, but it's still a pain in the integration. though it seems that the kernel device api is finally stabilizing.
1241458105 M * kcodyjr but it still seems like they have a long way to go if they intend to fold it back into upstream qemu
1241458540 J * Slydder1 ~chuck@91-65-50-48-dynip.superkabel.de
1241458811 Q * Pazzo Quit: Ex-Chat
1241458883 J * cga ~weechat@82.84.190.35
1241460176 J * Mr_Smoke smokey@layla.lecoyote.org
1241460198 M * Mr_Smoke Hello there.
1241460213 M * Mr_Smoke I am currently running 2.2.0.7 with the grsec+IPv6 patch.
1241460225 M * Mr_Smoke I've got a problem while running unrealircd inside a vserver.
1241460248 M * Mr_Smoke The ircd cannot establish an IPv4 connection to the outside (Operation not permitted). When running outside of the vserver, it can.
1241460256 M * Mr_Smoke Where should I be looking for clues ?
1241460304 M * kcodyjr Mr_Smoke, disclaimer:amateur, i'd start looking under /etc/vservers/<vservername>/ccapabilities 
1241460315 M * kcodyjr and read the docs/wiki/etc for anything else that relates to capabilities restrictions
1241460344 M * daniel_hozac Mr_Smoke: did you assign your guest an IP address?
1241460350 M * Mr_Smoke Sure, a public one, too
1241460353 M * daniel_hozac Mr_Smoke: did you strace it to see what's going on?
1241460358 M * Mr_Smoke The odd thing is this
1241460377 M * Mr_Smoke When I login as the user running ircd, I *can* open an IPv4 connection to anywhere
1241460382 M * Mr_Smoke It's just unreal that can't
1241460397 M * kcodyjr ditto what daniel_hozac, if its a caps issue, you need to know what exactly it's trying to do that's not permitted
1241460409 M * Mr_Smoke So I'm wondering : are there two different ways to open a socket, one that would hit bcaps and one that wouldn't ?
1241460415 M * Mr_Smoke 'that would be silly but heh ...'
1241460424 M * kcodyjr server socket vs client socket, yes, and it's not silly, it's part of grsec as well
1241460440 M * Mr_Smoke Well in that case, incoming connections are all OK
1241460447 M * Mr_Smoke Both IPv4 and IPv6 btw.
1241460453 M * kcodyjr gotcha to look out for: find out what the noserversocket group is in grsec on your system and make sure there isn't an accidental collision
1241460467 M * Mr_Smoke I doubt that but I'll check, just a sec
1241460488 M * kcodyjr wait, your ircd-with-vserver-user can open server sockets, but unreal can't? probably unreal is trying to do something else as well then.
1241460506 M * kcodyjr you need an strace to find the op that fails
1241460509 M * daniel_hozac also, check your iptables rules.
1241460523 M * Mr_Smoke  CONFIG_GRKERNSEC_SOCKET_ALL is not set
1241460523 M * Mr_Smoke # CONFIG_GRKERNSEC_SOCKET_CLIENT is not set
1241460523 M * Mr_Smoke # CONFIG_GRKERNSEC_SOCKET_SERVER is not set
1241460531 M * Mr_Smoke iptables is not a factor here, I've double checked that.
1241460560 M * daniel_hozac so OUTPUT is empty and all traffic accepted?
1241460597 M * kcodyjr Mr_Smoke, cat /proc/sys/kernel/grsecurity/socket_server_gid
1241460616 M * kcodyjr any process running as a user which is a member of that specified gid, will be unable to open server sockets
1241460641 M * kcodyjr except get rid fo the _server_ part because you don't have the fine grained restriction, only the blanket socket restriction, and your user can open clients, so we know that's not it.
1241460649 M * Mr_Smoke No such file or directory.
1241460655 M * Mr_Smoke Huh
1241460659 M * kcodyjr there wouldn't be, you had it turned off, i pasted before reading.
1241460674 M * Mr_Smoke I am not enforcing it :)
1241460703 M * kcodyjr strace your unrealircd and pastebin the last 50 or so lines of output
1241460711 M * daniel_hozac you want more than that.
1241460858 M * Mr_Smoke Ok, let's make a few users unhappy ;) just a sec
1241460960 M * kcodyjr Mr_Smoke, emphasis: pastebin
1241461001 M * Mr_Smoke Oh sure, I'm not about to paste 500+lines ;)à
1241461010 J * thierryp ~thierry@home.parmentelat.net
1241461011 M * Mr_Smoke 3 is probably my max ;)
1241461026 Q * thierryp 
1241461088 M * kcodyjr just checking. wasn't sure what else would make users unhappy.
1241461093 M * kcodyjr oh, your irc users. nevermind.
1241461214 M * Mr_Smoke hehe
1241461246 J * scientes_ ~scientes@97-113-122-26.tukw.qwest.net
1241461800 M * Mr_Smoke Owkay
1241461803 M * Mr_Smoke Progress
1241461813 M * Mr_Smoke I'll pastebin the lines
1241461949 M * Mr_Smoke http://pastebin.com/m58c51fe6
1241461957 M * Mr_Smoke So the connect is obviously failing
1241461982 M * Mr_Smoke is the first argument of connect() and bind() a socket identifier perhaps ?
1241462001 M * daniel_hozac yes.
1241462009 M * Mr_Smoke Ok
1241462021 M * Mr_Smoke So unreal is obviously opening a socket FROM my IPv6 address
1241462028 M * daniel_hozac does the guest have an IPv6 address?
1241462030 M * Mr_Smoke And trying to connect to a 6in4 IPv4
1241462032 M * Mr_Smoke Yes
1241462045 M * Mr_Smoke The IPv6 is correct here
1241462054 M * Mr_Smoke But I'm actually trying to connect to an IPv4 peer
1241462090 Q * gnuk Quit: NoFeature
1241462107 M * daniel_hozac yeah, so that makes no sense. sounds like unreal is just being stupid.
1241462130 M * kcodyjr that's unfortunately normal in a schizophrenic ipv6 world
1241462137 M * kcodyjr i'm still betting on a caps issue
1241462305 M * Mr_Smoke daniel_hozac: well the odd thing is, with the same config, it's working ok outside a vserver
1241462360 M * Mr_Smoke I'll strace the good, working behaviour, just a sec
1241462547 M * Mr_Smoke Well
1241462551 Q * ktwilight Quit: dead
1241462551 Q * cluk Quit: Ex-Chat
1241462571 M * Mr_Smoke As expected, on the working one, unreal binds to ::ffff:<real ipv4>
1241462592 M * Mr_Smoke And *then* connects to AF_INET6, ::ffff:<the other host's ipv4>
1241462682 M * kcodyjr someone's going to have to walk the source to find what capability a connect() would care about in that circumstance
1241462704 M * Bertl doesn't grsec have a 'test' mode?
1241462713 M * daniel_hozac there's no capability. connecting from an IPv6 address to an IPv4 one will never work.
1241462732 M * kcodyjr or you could just start trying things and see what helps, but it'll piss your users off... http://linux-vserver.org/Capabilities_and_Flags
1241462736 M * kcodyjr how does it work outside vserver then?
1241462762 M * kcodyjr ahh wait a minute, isn't there some daemon outside the vserver that handles 6-to-4 routing?
1241462766 M * Mr_Smoke No idea, "it just works" (tm)
1241462771 M * Mr_Smoke Nope.
1241462792 M * Bertl I presume it uses the ipv4 address?
1241462797 J * ktwilight ~ktwilight@21.240-64-87.adsl-dyn.isp.belgacom.be
1241462823 M * kcodyjr i tried the pure-v6 internal network once, it required a proxy to reach the ipv4 world
1241462863 M * Mr_Smoke Bertl: exactly
1241462893 M * Bertl so, does the guest have an ipv4 address assigned?
1241462905 M * Mr_Smoke Yep, that too.
1241462920 M * Bertl is it the first one?
1241462929 M * Mr_Smoke How do you mean ?
1241462939 M * Bertl the first in the Linux-VServer config
1241462962 M * Mr_Smoke Er ... the first what O.o ?
1241462995 M * Mr_Smoke IS the IP address the first one inside the vserver ?
1241463018 M * Bertl what does /proc/virtnet/<nid>/* contain (please use paste.linux-vserver.org for everything longer than 3 lines) 
1241463065 M * Mr_Smoke This : ( last 2 lintes )
1241463065 M * Mr_Smoke 0:      81.93.244.184/255.255.255.240
1241463065 M * Mr_Smoke 0:      2001:0758:d00d:0000:0000:0000:0000:0184/0
1241463072 M * Mr_Smoke lines*.
1241463102 M * daniel_hozac /0? sounds like you're missing a prefix.
1241463163 M * Mr_Smoke Hm strange
1241463188 Q * AndrewLee Read error: Connection reset by peer
1241463189 M * Mr_Smoke Gosh, the prefix is missing indeed
1241463191 J * AndrewLee ~andrew@210.240.39.7
1241463197 M * Mr_Smoke Oo
1241463209 M * Mr_Smoke That would be the reason then
1241463215 M * Mr_Smoke or *could*
1241463260 M * Mr_Smoke And no way I can fix that without restarting, huh ? :)
1241463267 M * daniel_hozac sure there is.
1241463296 M * daniel_hozac naddress --nid <guest> --set --ip 81.93.244.184/255.255.255.240 --ip 2001:0758:d00d:0000:0000:0000:0000:0184/64
1241463329 M * Mr_Smoke Well hangon a sec
1241463329 M * daniel_hozac but check your assigned IP addresses too. it's most likely wrong.
1241463342 M * Mr_Smoke Inside the vserver I get a /128 prefix
1241463350 M * Mr_Smoke daniel_hozac: nope, the IP is correct.
1241463361 M * daniel_hozac i meant the prefix.
1241463438 M * Mr_Smoke Yeah the prefix was simply missing :/
1241463549 Q * nenolod Quit: fucking with my network some more. back later.
1241463743 Q * scientes_ Quit: scientes_
1241463795 M * Mr_Smoke daniel_hozac: thanks a bunch, I'm about to test the whole thing now
1241464537 M * Mr_Smoke Shoot. It's still not working
1241464554 M * kcodyjr strace says it's the same error?
1241464556 M * Mr_Smoke I've fixed the prefix but it's still binding to its ipv6 address 
1241464559 M * Mr_Smoke Yup
1241464561 M * kcodyjr any chance of trying it as native ipv4?
1241464574 M * Mr_Smoke How do you mean ?
1241464584 M * kcodyjr disable ipv6 in the guest altogether
1241464619 M * Bertl (with the same naddress command as above)
1241464669 M * Mr_Smoke Oh ok
1241464675 M * Mr_Smoke Let's try that
1241464857 M * Mr_Smoke No can do. Without any ipv6 address it refuses to bind.
1241464863 M * Mr_Smoke Hm I'm wondering now
1241464880 M * Mr_Smoke It might be that unreal's way of determining which IP to bind to is flawed
1241464903 M * kcodyjr that's consistent with other applications that have trouble. try explicitly configuring unreal for that?
1241464974 M * Mr_Smoke There is a specific "bind-ip" option, but it's set to the guest's IPv4 already
1241465005 M * Bertl so, run the strace -fF on it with just the ipv4
1241465014 M * Bertl (so that we can see what it does in full)
1241465020 M * Bertl and upload that somewhere
1241465050 M * Mr_Smoke Oh hangon a sec
1241465052 M * Mr_Smoke It's working now
1241465053 M * daniel_hozac Mr_Smoke: you might want to try using 2.3 instead. i've been running unreal on that with IPv4 and IPv6 for quite some time.
1241465061 M * Mr_Smoke O.o
1241465068 A * Mr_Smoke retraces his steps
1241465224 M * Mr_Smoke Oooook so the only thing I did to make it work was to remove IPv6 altogether (ie set only the IPv4 address) and add it back
1241465237 M * Mr_Smoke But now it's working ok
1241465247 M * Mr_Smoke Whew.
1241465275 M * kcodyjr so it was the prefix problem. i bet you'd have seen both the correct and incorrect prefix if you'd "ip addr list" before removing it altogether.
1241465290 M * Mr_Smoke Hm maybe
1241465301 M * Mr_Smoke I can do it again from the top
1241465450 M * Mr_Smoke Or not. I've tried setting no prefix again, so I get the /0 in /proc/virtnet/<xid>/info
1241465458 M * Mr_Smoke And unreal binds to IPv4 happily
1241465482 A * Mr_Smoke is going nuts, slightly
1241465686 M * Mr_Smoke Bah, the good thing is now I know where it came from
1241465734 M * Mr_Smoke daniel_hozac: I've got 2.3 running on another host. It looks fairly stable indeed, and I like the fact that there is a "real" lo inside the guest. I'm still undecided about whether to go 2.3 all the way
1241465891 Q * geb Ping timeout: 480 seconds
1241465901 J * geb ~geb@earth.gebura.eu.org
1241465908 M * Mr_Smoke Anyway, thank you all for your insights, it's been most helpful :)
1241465919 M * Bertl glad it works for you now!
1241466379 M * Mr_Smoke So am I :)
1241466414 M * Mr_Smoke *and* I've learned something too. WIN !
1241466430 M * Bertl that's the way it should be! :)
1241466573 M * Mr_Smoke Indeed ;)
1241466671 M * Mr_Smoke Now, there's no way to add an *interface* (dummy, tap) inside a guest without a restart now, is there ?
1241466681 M * Mr_Smoke I mean I've only just learned about naddress, so who knows :)
1241466700 M * Bertl interfaces are not added to guests
1241466718 M * kcodyjr blast. add to list of reasons to consider vs-2.3 series: i'm being hit by the sec=null bug in nfs.mount >=1.1.3 running on <2.6.23. i can either upgrade the kernel (and vs) or downgrade nfs-utils...
1241466732 M * Bertl Mr_Smoke: IPs are added to a guest, and if that IP is found on an interface, that interface is shown
1241466753 M * kcodyjr if you must have an interface owned strictly by the guest, i think you need to give the guest the NET_ADMIN cap, right?
1241466780 M * Bertl just uploaded vs2.3.0.36.11 for 2.6.29.2
1241466819 M * Bertl kcodyjr: nope, there is no way to 'give' or 'assign' interfaces to guests .. Linux-VServer networking is on the IP layer (isolation)
1241466878 M * kcodyjr right, so what you're really doing NET_ADMIN is giving a guest permissions to do whatever it likes with any interface on the system
1241466888 M * Bertl correct
1241466896 M * kcodyjr by 'owned' i meant administratively, not isolation
1241466897 M * Mr_Smoke Oh ok
1241466898 J * geb_ ~geb@AOrleans-253-1-14-55.w92-140.abo.wanadoo.fr
1241466923 M * Mr_Smoke So if I add tap0 on the host, and add tap0's IP to a guest, then my guest will essentially be able to use tap0, right ?
1241466929 M * kcodyjr yep
1241466933 M * Mr_Smoke Sounds good.
1241466951 M * kcodyjr though, you may wish to assign a subnet to your tap0, one ip on the host, one on the guest
1241466968 M * kcodyjr assigning an ip to the guest makes it 'find' an interface in the same subnet
1241466976 M * kcodyjr doesn't have to be the same ip that i can tell
1241466995 M * Mr_Smoke It might come in handy later. Good to know.
1241467091 Q * Slydder1 Quit: Leaving.
1241467103 M * kcodyjr double blast. older nfs-utils introduces dependency limits on nfsidmap and possibly others. my hand may be forced into upgrading to vs-2.3 series.
1241467144 M * Bertl vs2.3.0.36.11 should be fine :)
1241467186 M * kcodyjr suppose it's time to find out if it'll apply to hardened-sources-2.6.28-hardened-r7
1241467201 M * kcodyjr s/hardened-r7/r7/
1241467205 M * Bertl nah, won't, it is based on 2.6.29.x
1241467221 M * Bertl but you can get a patch for 2.6.28.x too
1241467252 M * kcodyjr i've found that ~amd64 hardened-sources tend to be a bad idea
1241467270 Q * geb Ping timeout: 480 seconds
1241467483 M * kcodyjr hm. but nfs-utils-1.1.2 does the job. if it's only one build dependency maybe i'll live with it. it'll only bite me when the kernel really can be upgraded anyway... i only hesitate because these are highly critical network services being hosted on these. they've been super stable and i don't want to mess up the uptime statistics... gentoo is on shaky ground around here already
1241467653 M * kcodyjr ok, yep. just the one dependency has to be held back below net-libs/libnfsidmap-0.21. mental note to anyone running overly recent userspaces with a vs2.2 compatible kernel, then...
1241467698 M * Mr_Smoke Ooo gentooists :)
1241467746 M * kcodyjr only in cases where recent libraries or rebuildability really were a design requirement. where RHEL versions will do i'll use that or CentOS.
1241467787 M * kcodyjr or, come to think of it, the hardened toolchain. i wouldn't want to go into a hacker's wifi coverage with a laptop running the latest grandmaware...
1241467878 M * kcodyjr as applied to the problem i just identified, it probably applies to any ubermodern distro, rawhide et al, or anyone getting ready to push a new version. on such a distro, backporting to a vs2.2 compatible kernel will open up this bug.
1241467921 M * kcodyjr - ergo, the specter of time pressure on declaring 2.3 stable looms on the horizon...
1241467947 M * kcodyjr sounds like Bertl is feeling close to that confident with it though
1241468128 M * Bertl well, it's done when it's done .. but feel free to speed up the process with some kind of support :)
1241468166 M * kcodyjr forgetting distro integration for a moment, and remembering i haven't even looked at 2.3... what's left to be done?
1241468199 M * kcodyjr i'm well capable of shoehorning the patch into the appropriate kernel-sources ebuild, if we're "there" yet...
1241468359 M * Bertl well, mainly testing and code cleanup for a 'stable' release
1241468461 M * Bertl okay, off to bed now .. have a good one eveyone!
1241468479 N * Bertl Bertl_zZ
1241468797 Q * cga Quit: got a DELL??? update you BIOS with http://github.com/cga/dellbiosupdate.sh/tree/master ;)
1241468894 M * Mr_Smoke Hm I think I should risk a comment here, regarding this whole IPv6 prefix thing
1241468927 M * Mr_Smoke I believe the reason I didn't specify a prefix in /etc/vserver/xid/interfaces/n/ was that I read the vserver script and saw that it assumed a default value of 128
1241468965 M * Mr_Smoke This was confirmed by the fact that whatever I put in prefix there, the guest would always get a /128 prefix, attested by a ip -6 addr inside the guest
1241469003 M * Mr_Smoke So perhaps there should be some clarification as to what the prefix is actually for, and its consequences
1241469043 M * Mr_Smoke Had I known (and looked up, I admit) about /proc/virtnet/xid/info, it would have been a lot easier.
1241469048 M * Mr_Smoke Hope I'm still making sense here :)
1241469092 M * kcodyjr you are. probably some script is interpreting it differently somewhere. i think this is where you're supposed to go edit the wiki...
1241469124 M * Mr_Smoke I'll make a note of that
1241469141 M * daniel_hozac what utils are you using?
1241469151 M * daniel_hozac IIRC i corrected the prefix parsing sort of recently.
1241469724 J * nenolod nenolod@petrie.dereferenced.org
1241469737 M * kcodyjr something like 20 hunks failed applying vs2.3.0.36.8 to hardened-sources-2.6.28-r7... i might be able to cope with that but maybe not. likely i'll have better luck with a vanilla or gentoo base tree.
1241469921 Q * larsivi_ Ping timeout: 480 seconds
1241470065 J * larsivi ~larsivi@70.84-48-63.nextgentel.com
1241471017 J * Floops[w]1 ~baihu@205.214.201.176
1241471408 Q * Floops[w]2 Ping timeout: 480 seconds
1241471533 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1241472051 Q * bonbons Quit: Leaving
1241472768 Q * nenolod Ping timeout: 480 seconds
1241472783 J * nenolod nenolod@petrie.dereferenced.org
1241473378 M * Mr_Smoke daniel_hozac: 0.30.215 (i'm not running ~arch, just plain x86)
1241474065 M * Mr_Smoke Anyways, nite :)
1241475392 Q * Piet Quit: Piet
1241475466 Q * dwery Ping timeout: 480 seconds
1241475496 J * dwery ~dwery@93-39-57-60.ip74.fastwebnet.it
1241477261 Q * dowdle Remote host closed the connection
1241477609 J * dowdle ~dowdle@scott.coe.montana.edu
1241478293 Q * dowdle Remote host closed the connection
1241479047 J * saulus_ ~saulus@c150095.adsl.hansenet.de
1241479153 Q * saulus Ping timeout: 480 seconds
1241479153 N * saulus_ SauLus
1241479180 J * Floops[w]2 ~baihu@205.214.201.176
1241479573 Q * Floops[w]1 Ping timeout: 480 seconds
1241480344 N * DoberMann[PullA] DoberMann[ZZZzzz]