1316908967 N * Bertl_zZ Bertl
1316908970 M * Bertl back now ...
1316909963 Q * ghislain Quit: Leaving.
1316914545 Q * manana Remote host closed the connection
1316918449 J * emma81 ~emma81@9YYAABPWM.tor-irc.dnsbl.oftc.net
1316918526 P * emma81 
1316921762 Q * arekm Ping timeout: 480 seconds
1316926732 M * Bertl off to bed now ... have a good one everyone!
1316926737 N * Bertl Bertl_zZ
1316930667 J * jamieson ~jamieson@71.11.175.78
1316931268 J * arekm ~arekm@ixion.pld-linux.org
1316931785 M * jamieson Bertl_zZ or anyone else, has anyone anywhere ever seen an instance where a vserver kernel refuses traffic to all ports from a (way distant, like on another contintent) box on the other side of a NAT router but allows traffic from another box hanging off SAME NAT router?
1316931789 M * jamieson bizaar but true.
1316931800 M * jamieson s/bizaar/bizarre ;-)
1316931846 M * jamieson weirder still, this occurs only with vserver kernel, not standard kernel. weird still, my customers in another state are experiencing same thing. weirder still, this applies to ALL traffic on all interfaces. weirder still, ICMP still works -- just not tcp
1316931861 A * jamieson is totally stumped
1316931932 M * jamieson like, how does vserver even know what the source ip of the "bad" clients are (since both good and bad are behind same nat f/w)...
1316932015 M * jamieson oddly, this doesn't occur on backup server (same kernel)
1316932054 M * jamieson usual suspects (iptables, tcpwrappers, etc) don't seem to be at play here.
1316932090 M * jamieson not routing, since a) other boxes behind same NAT f/w work, and b) icmp works for both good and bad clients
1316934873 Q * fisted Ping timeout: 480 seconds
1316934975 J * fisted ~fisted@xdsl-87-78-210-81.netcologne.de
1316935575 J * ghislain ~AQUEOS@adsl2.aqueos.com
1316935855 J * sannes ~ace@cm-84.209.106.118.getinternet.no
1316937931 Q * jamieson Quit: sleeping
1316938472 Q * mcp Remote host closed the connection
1316938488 J * mcp ~mcp@wolk-project.de
1316941308 J * thierryp ~thierry@home.parmentelat.net
1316949980 J * bonbons ~bonbons@2001:960:7ab:0:590a:3d15:372b:d3e9
1316950237 J * manana ~mayday090@178.162.120.195
1316954032 Q * thierryp Remote host closed the connection
1316954638 N * Bertl_zZ Bertl
1316954647 M * Bertl morning folks!
1316955308 J * markc ~markc@203.25.132.186
1316955424 M * markc hi, are there any alternate php control panels to openvcp.org? ... or forks that are more uptodate?
1316955575 M * Bertl there probably are, but nothing which readily comes to my mind atm
1316955605 M * Bertl the thing with the control panels is that they usually target commercial products and commercial users
1316955608 Q * fisted Ping timeout: 480 seconds
1316955620 M * markc Bertl, thanks, took a long shot snd did a search on Github and... https://github.com/freezmeinster/vmin
1316955711 M * markc I've never seen any cp actually working so I'm not sure what they're like, as a beginner, it would be nice to have some kind of gui with the various options right in front of me
1316955743 M * markc seems a pity openvcp is no longer maintained (I guess)
1316955758 M * Bertl well, I don't know any gui for any virtualization or isolation system which gives you the actual options
1316955776 M * Bertl they usually abstract and reduce the system to a minimum
1316955793 M * Bertl (which is understandably)
1316955847 M * markc well that's what I mean, a simple "gimme a new vserver" and then do all the work under the hood, without me having to rtfm all the time
1316955880 M * Bertl IMHO util-vserver does a pretty good job for that already (although on the command line)
1316955932 M * markc yes it great, but I'll have to write scripts to automate the process and I thought, surely, this has been done a 1000 times before
1316955961 M * Bertl most likely, just that is usually the part which differentiates one provider from the other
1316955981 M * Bertl (i.e. having a smart web interface for creation and/or customer)
1316955994 M * Bertl so usually they do not share that part readily
1316956021 M * Wonka like Plesk for websites?
1316956023 M * hparker Doesn't syscp support vserver?
1316956026 J * fisted ~fisted@xdsl-87-78-217-226.netcologne.de
1316956050 M * markc right, and obviously don't contribute to openvcp or openvps or even hypervm
1316956094 M * markc hmm, vmin looks like it might be good, and simple/small enough to easily hack... if it works
1316956121 M * Bertl check it out and let us know how it goes
1316956253 M * markc okay... I've got a 64bit openwrt build running as a guest, currently a du of ~12Mb... I need to figure out templates and such so that's when I thought there may be some kind of gui that would hasten the learning process
1316956385 M * Bertl so you already have a guest?
1316956406 M * Bertl then I'd suggest to simply use the 'clone' build method
1316956407 M * markc yes, all 12Mb of it... lovely
1316956434 M * Bertl which either makes a copy with your 'new' arguments like hostname or interfaces
1316956460 M * Bertl or, if you use unification, a shallow hardlinked version (i.e. even less disk space per clone)
1316956531 M * markc ah, that's the one I am particularly interested in, haven't tried it yet... clone first I guess, but I'll get vmin running with lighttpd and see if it offers those options
1316956970 M * markc do I have to stop a guest first before cloning it? ... I just tried what I thought would work and got a huge amount a permission denied errors
1316956998 M * Bertl permission denied sounds strange, could you upload the output?
1316957166 M * markc it's okay, I stopped the guest to be cloned first and it then cloned cleanly
1316958942 M * markc so if I need some kind of localhost interface in each guest would something like 127.0.1.1 127.0.1.2 within each guest work?
1316958985 M * Bertl you do not need that (with any somewhat recent kernel) as you can enable automatic loopback ip assignment and loopback isolation
1316958998 M * markc I want to start a php-cgi instance so lighttpd can talk to is via fastcgi, but php-cgi usually binds to 127.0.0.1 (localhost)
1316959043 M * Bertl which will give you 127.0.0.1 inside each guest to bind to, and outside the guest it will be seen as 127.x.y.1 where x,y is built from the context id
1316959045 M * markc thanks, I'll google up on "automatic loopback ip assignment"
1316959061 M * Bertl what's your kernel and what is the kernels .config?
1316959198 M * markc I'm using the Archlinux x86_64 linux-vserver package ... what might be a keyword to zgrep /proc/config.gz with?
1316959214 M * Bertl VSERVER :)
1316959240 M * Bertl and what kernel/patch version does archlinux use?
1316959370 M * markc it's a 3.0.4 kernel with the 2.3.1-pre10.1patch
1316959387 M * Bertl excellent!
1316959468 M * markc no sign of a VSERVER + LOOPBACK variable
1316959509 M * markc yes, it was part of their AUR system so a simple "packer -S linux-vserver" built and installed it
1316959552 M * Bertl I'm interested in the following config options:
1316959556 M * Bertl CONFIG_VSERVER_AUTO_LBACK
1316959565 M * Bertl CONFIG_VSERVER_AUTO_SINGLE
1316959586 M * markc ah yes, both of them are set =y
1316959607 M * markc doh, LBACK == loopback
1316959661 M * Bertl okay, then you need to add an nflags entry with ~single_ip
1316959673 M * Bertl for your guest
1316959691 M * Bertl (the rest will be done automatically)
1316959718 M * Bertl http://www.nongnu.org/util-vserver/doc/conf/configuration.html
1316959741 M * markc so I just did a clone with --interface wlan0:192.168.42.43/32 so what should that single IP be? .. ah, rtfm :)
1316959771 M * Bertl the single_ip means that your guest gets special remapping if it only has a single IP assigned
1316959791 M * Bertl that is not what you want when you want to use the loopback isolation as well
1316959804 M * Bertl thus you negate this flag in the config with ~single_ip
1316959805 M * markc oh... still reading
1316959822 M * Bertl (as your kernel is configured to automatically set that flag)
1316959867 M * markc actually, it's looking at that "flower" page last night that got me looking for some kind of gui.. so many options to learn !
1316959883 M * Bertl it boils down to 'echo ~single_ip >/etc/vservers/<guest>/nflags'
1316959900 M * Bertl after stopping the guest, and before a new guest startup
1316959953 M * Bertl when the guest comes up again, you can enter it and should see your IP on ethX and the loopback ip on lo
1316960030 M * markc oops, stop the guest first... should I remove /etc/vservers/v4/interfaces/0/ip (v4 is this particular guest) ?
1316960058 M * Bertl that is the IP you want assigned to the guest, no?
1316960068 M * Bertl (besides lo)
1316960126 M * markc yes, it's what I passed in as  --interface wlan0:192.168.42.43/32 when I cloned it from my current v3 guest
1316960144 M * Bertl so no reason to remove that
1316960242 M * markc okay, there is a v4/interfaces/0/dev that contains "wlan0" so that may still be needed, I guess
1316960291 M * markc ah!!... magic :) thank you for that
1316960600 M * markc what I really like about vservers in general is ability to access them as root from the host, it will make management so much easier, can't wait to try and test out -m unification
1316960655 M * Bertl it isn't actually a build method, but yeah, unfication is nice to have when you have several reasonably similar guests
1316964104 M * Bertl nap attack .. bbl
1316964110 N * Bertl Bertl_zZ
1316965893 Q * hparker Ping timeout: 480 seconds
1316966983 J * hparker ~hparker@linux.homershut.net
1316969146 J * thierryp ~thierry@home.parmentelat.net
1316969714 Q * thierryp Remote host closed the connection
1316969803 J * thierryp ~thierry@home.parmentelat.net
1316972721 J * ghislain1 ~AQUEOS@adsl2.aqueos.com
1316972866 Q * thierryp Remote host closed the connection
1316972962 Q * ghislain Ping timeout: 480 seconds
1316976772 Q * markc Remote host closed the connection
1316980029 N * Bertl_zZ Bertl
1316980033 M * Bertl back now ...
1316980573 Q * ntrs Ping timeout: 480 seconds
1316981050 J * ntrs ~ntrs@vault08.rosehosting.com
1316984748 Q * bonbons Quit: Leaving
1316987703 J * Walex ~Walex@87-194-99-40.bethere.co.uk
1316990454 Q * ghislain1 Quit: Leaving.
1316991825 J * markc ~markc@203.25.132.186