1149292823 M * starlein would say it doesnt matter
1149293174 M * starlein good night virtual units
1149293999 M * daniel_hozac you'll get more accurate data from /proc/virtual/*/{limit,cvirt,status}.
1149294014 M * daniel_hozac (rather than the ugly hack that vserver-stat is...)
1149294525 M * harry then we're in urgent need for decent tools ;)
1149294537 Q * sladen Ping timeout: 480 seconds
1149294686 J * sladen paul@starsky.19inch.net
1149294719 M * daniel_hozac AFAIK there's no interface for getting the accounting data, other than proc.
1149294751 M * daniel_hozac and parsing proc feels like a hack IMHO, plus there are a lot of different versions of the files.
1149295559 J * doener ~doener@i5387C4D3.versanet.de
1149295780 Q * doener_ Read error: Connection reset by peer
1149296287 Q * gerrit Ping timeout: 480 seconds
1149298357 N * sarnold sars
1149298891 J * _mcp ~hightower@wolk-project.de
1149298942 Q * mcp Read error: Connection reset by peer
1149298947 N * _mcp mcp
1149298974 J * Hollow_ ~hollow@home.xnull.de
1149298974 Q * Hollow Read error: Connection reset by peer
1149303837 J * orionpanda orionpanda@netblock-66-245-252-180.dslextreme.com
1149304062 Q * softi42 Ping timeout: 480 seconds
1149304684 J * softi42 eacosqx@p549D56C2.dip.t-dialin.net
1149310847 Q * Hollow_ Remote host closed the connection
1149310875 J * Hollow ~hollow@home.xnull.de
1149315593 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net
1149319087 Q * shedi Read error: Connection reset by peer
1149319732 J * Viper0482 ~Viper0482@p5497743D.dip.t-dialin.net
1149319925 J * shedi ~siggi@inferno.lhi.is
1149320692 Q * pisco Ping timeout: 480 seconds
1149321979 J * nebuchadnezzar ~nebu@zion.asgardr.info
1149322227 J * bonbons ~bonbons@83.222.39.166
1149322737 Q * nebuchadnezzar Ping timeout: 480 seconds
1149323516 J * dna ~naucki@dialer-155-26.kielnet.net
1149323920 J * nebuchadnezzar ~nebu@zion.asgardr.info
1149325208 M * nox harry: you 're making me curious (;
1149327972 Q * kaner helium.oftc.net nobelium.oftc.net
1149327972 Q * FireEgl helium.oftc.net nobelium.oftc.net
1149328610 J * Pater_John ~Patrick09@194.112.144.69
1149329444 J * jpduyx ~jpduyx@adsl-228-22.dsl.uva.nl
1149330029 Q * DreamerC Quit: leaving
1149330047 J * DreamerC ~dreamerc@59-112-22-42.dynamic.hinet.net
1149330166 N * otaku42 otaku42_away
1149330556 J * FireEgl Atlantica@Atlantica.CJB.Net
1149331116 Q * Pater_John Quit: get satisfied! • :: ««« (Gamers.IRC) »»» www.gamersirc.net ::
1149331498 J * DarthVader ~Aniken@203.177.212.163
1149331898 M * harry nox: nothing special ;)
1149331903 M * harry 01:54 -!- nox [~nox@nox.user.oftc.net] has quit [Server closed connection]
1149331903 M * harry 01:54 -!- nox [~nox@nox.user.oftc.net] has quit [Server closed connecti01:54 < harry> hmmmmm... dying fetus++
1149331907 M * harry 01:55 -!- nox [~nox@noxlux.de] has joined #vserver
1149332606 Q * sladen Ping timeout: 480 seconds
1149332842 J * sladen paul@starsky.19inch.net
1149333362 J * lilalinux ~plasma@dslb-084-058-220-005.pools.arcor-ip.net
1149333442 J * vvvvvvv zxczeq@adsl30-222.qualitynet.net
1149333479 Q * cdrx Read error: Operation timed out
1149333640 J * LBiH ~LBiH@adsl23-241.qualitynet.net
1149333721 P * LBiH 
1149334326 Q * vvvvvvv Quit: 
1149334773 Q * jpduyx Read error: Connection reset by peer
1149334829 Q * Viper0482 Read error: Operation timed out
1149335470 J * Viper0482 ~Viper0482@p54975ED5.dip.t-dialin.net
1149337259 M * orionpanda Quick question on COW; does COW work when vservers are stored on NFS? Do I need to patch the NFS server's kernel, or only the client machine's kernel? Or both?
1149338394 Q * DarthVader Quit: Leaving
1149338394 Q * shedi Read error: Connection reset by peer
1149338493 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net
1149338950 M * bonbons orionpanda: I think it should work, but did not try. What you will need is XAttr support on your NFS shares
1149338984 M * bonbons the easiest test for it: hardlink two files on the NFS share, add 
1149339010 M * bonbons IUNLINK and IMMUTABLE flags to them, after that try overwriting one of them
1149339038 M * bonbons repreat the same operation, unmounting and remounting the NFS share before trying the last step
1149339184 M * orionpanda you mean, 'setattr --iunlink <file_name>' ? what should nfs do if it supports xattr? deny permissions on the write?
1149339237 M * daniel_hozac if COW is working, it should break the link.
1149339300 M * orionpanda Is COW handled by the nfs client or the server? Do I need to patch the server kernel?
1149339348 J * shedi ~siggi@inferno.lhi.is
1149339383 M * bonbons it's done by the client, but inside of kernel when opening the file. The server must store the xattr attributes (client and server must support xattr over NFS)
1149339494 M * orionpanda ah. ok. so it's possible for a vanilla ext3 filesystem to not store xattr attributes.
1149339548 M * orionpanda is the the patch for adding xattr support split out from the main vserver patch? if so, do you know where I can get it?
1149339571 M * daniel_hozac xattrs is not a vserver thing...
1149339723 M * orionpanda oh. you're right. CONFIG_EXT3_FS_XATTR in kernel .conf; thanks for clearing this up; i'm going to setup my nfs server now and see if cow works. 
1149341670 Q * brc Ping timeout: 480 seconds
1149342142 Q * Kipps Quit: 
1149342884 J * JonB ~NoSuchUse@0x535f65c3.kjnxx7.adsl-dhcp.tele.dk
1149342901 Q * JonB Quit: 
1149343728 J * brc bruce@20151165238.user.veloxzone.com.br
1149345134 Q * phedny Server closed connection
1149345139 J * phedny ~mark@volcano.p-bierman.nl
1149350857 Q * Smutje Quit: Lost terminal
1149352056 J * DarthVader ~Aniken@203.177.212.163
1149352308 M * starlein anyone tried that net64 patch? did increase NB_V4ROOT to 128 and just wondering if there will be some performence leak in kernel by handling with more than 1000 udp packets/sec?
1149352388 M * starlein or does that performence leak only begin at much more pps?
1149352520 M * bonbons starlein: the list of addresses is scanned on each udp packet or incoming tcp connection, so the more addresses you have, the more it costs
1149352723 M * starlein I see
1149352751 M * bonbons in the near future that will be changed by allowing ranges of addresses to be associated to a guest
1149352775 M * starlein but think that should not get a problem at that low packet count?
1149352804 M * starlein think it would be heavy at ddos attack with many many udp packets or sth.
1149352816 M * bonbons it won't be a real problem, to get better performance, add the most used addresses first
1149352833 M * starlein ah
1149352841 M * starlein fine
1149352849 M * bonbons so the guest is responsive
1149352901 M * bonbons but if you have multiple guests or UDP services on the host you will loose
1149352938 M * starlein right, host goes completely down at ddos with many udp pps
1149352958 M * starlein or lets say the response won't get out
1149352979 M * starlein think it must be caused by that v4root incremental
1149352985 M * bonbons if you let your guests bind the exact address you will work around that current limitation
1149353023 M * bonbons so avoid having the UPD clients listen to 0.0.0.0, but let them bind to the local address
1149353049 M * starlein ahh okay
1149353072 M * starlein thanks for that hint, many processes still binding to 0.0.0.0
1149353157 M * bonbons just make sure that on the port noone binds to 0.0.0.0, otherwise scan is required
1149353229 J * hound weasel@tor.noreply.org
1149353588 Q * Snow-Man Server closed connection
1149353595 J * Snow-Man ~sfrost@kenobi.snowman.net
1149354664 J * okaratas ~devnull@81.214.177.168
1149355051 Q * hound Remote host closed the connection
1149355141 Q * okaratas Quit: 
1149356197 Q * shedi Read error: Connection reset by peer
1149357028 J * shedi ~siggi@inferno.lhi.is
1149358327 Q * cdrx Ping timeout: 480 seconds
1149358576 Q * locksy Ping timeout: 480 seconds
1149358590 J * locksy ~locksy@mrtg.sisgroup.com.au
1149363455 Q * Viper0482 Remote host closed the connection
1149363646 Q * cilkay helium.oftc.net xenon.oftc.net
1149363722 J * cilkay ~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com
1149365097 J * mana ~mana@bravo387.server4you.de
1149365108 M * mana hello channel :)
1149365164 M * Loki|muh hi mana
1149365169 M * mana is anybody familiar with NAT'ing vservers using provate adresses to a public IP adress?
1149365188 A * Loki|muh not
1149365189 M * bonbons I've done it, port by port
1149365227 M * mana yes thats how i do it as well .. but the problem is, that vservers cant connect to ports on the public ip .......
1149365275 M * mana when i want to connect to say domain1.tld it resolves to the public IP adress. I can connect from outside but not from inside sigh
1149365283 M * bonbons can you give a small indication on your setup?
1149365299 M * mana i have two rules :) wait a moment
1149365311 M * mana ah setup -> architecture?
1149365320 M * mana one webserver, with one public ip
1149365356 M * mana several vservers bindung to a dummy interface, each with a private ip adress, starting from 192.168.1.2
1149365399 M * mana here the first global iptable rule that is used to allow guests to access IP's on the internet:
1149365405 M * bonbons just the IP layout with flow (what wants to connect to what and from where)
1149365415 M * mana ok ;)
1149365484 M * mana vserver2 -> public-ip port 80 -> port 80 is mapped to vserver1 beeing the webserver
1149365533 M * mana is that what you mean?
1149365566 M * bonbons that should be good, in what chains to you do your nat, and how?
1149365619 M * mana in that way to allow outgoing traffic: iptables -t nat -I POSTROUTING -s $VSERVER_NET  ! -d $VSERVER_NET -j SNAT --to $EXT_IP
1149365653 M * mana and for each port or port range on extra line: iptables -t nat -A PREROUTING -s ! $VSERVER_NET -m tcp -p tcp --dport 80 -j DNAT --to-destination $VHOSTING:80
1149365703 M * mana thats seems pretty simple, and i like iptable chains simple as i am pretty ew to that stuff :)
1149365785 M * mana i tried to leave out the "-s ! $VSERVER_NET" but that didn't help
1149365883 M * bonbons for your per-service line you should possibly add a '-d $EXT_IP' so you don't catch unintended things
1149365896 M * mana like? :)
1149365938 M * mana i got those rules from a howto on linux-vserver.org
1149366016 M * mana ok i try adding -d $EXT_IP. You think that will fix the connect?
1149366019 M * bonbons I would have written iptables -t nat -A PREROUTING -s ! $VSERVER_NET -d $EXT_IP -m tcp -p tcp --dport 80 -j DNAT --to-destination $VHOSTING:80
1149366046 M * bonbons not sure I'am setting up the same kind of rules here for testing
1149366092 M * mana ok i try that now :) for one port at first as ths chat here runs on a nx-vserver ...
1149366187 M * mana ah what you wrote is the same rule like that one i wrote you :D
1149366228 M * mana ah moment
1149366247 M * mana damn kirc copying ..........
1149366382 M * mana same effect .. connect from outside possible, connect from a vserver is rejected
1149366502 M * mana i have the feeling it is the rule for postrouting ..
1149366578 M * bonbons for me connection is never possible right now... what do the packet counters tell you (where packts get processed) iptables -t nat -L -v
1149366668 M * mana phu thats alot .. what shal i look for exactly?
1149366778 M * mana this looks like the rules reject connects from inside:
1149366784 M * mana     0     0 DNAT       tcp  --  any    any    !192.168.1.0/24       seposition.net      tcp dpt:http to:192.168.1.5:80
1149366788 M * bonbons I get a 'no route to host'
1149366833 M * bonbons it's the first column that's of interest. In you paste there was no packet matching the rule
1149366838 M * mana i get a big table overview, much mor elines than rules that i have with no "no route to host" entrys ..
1149366920 M * mana Chain PREROUTING (policy ACCEPT 17069 packets, 2945K bytes)
1149366920 Q * lilalinux Read error: Connection reset by peer
1149366937 M * mana  pkts bytes target     prot opt in     out     source               destination
1149366956 M * mana     9   504 DNAT       tcp  --  any    any    !192.168.1.0/24       anywhere            tcp dpt:2222 to:192.168.1.1:22
1149366965 M * mana shure we get the same view? :)
1149366977 M * mana thats the first three lines ..
1149366982 M * mana ah columns
1149367020 M * mana okay in the first column i look at the numbers and those tell me where the traffic goes ..
1149367079 M * bonbons yep! The problem here is the one common with NAT routers, hard to get to the public IP
1149367107 M * mana will this table show the same number of rows (or even increasing) when i flush the iptables?
1149367108 M * bonbons is it important to be using the public IP for this?
1149367153 M * mana well, i have a hosting running on one vserver. and a freenx terminalserver on the other .. i want the users to simply access the websites on the hosting vserver from inside the freenx server ..
1149367158 M * bonbons otherwise you could just dnat EXT_IP to GUEST one when src is in VSERVER_NET
1149367171 M * mana might t be better to do something about DNS?
1149367210 M * bonbons you could piddle around with DNS, but that's quite error-prone (and users may reuse the IP seen inside from outside and complain it doesn't work)
1149367264 M * mana man that cant be that difficult heh?
1149367310 M * mana thinking ...
1149367387 M * mana (testing ..)
1149367426 M * mana  ... nothing ..
1149367502 M * mana could i setup a special rule that says something like: "if private IP wants to connect to public-IP:PORT, redirect it to private-IP:PORT?
1149367612 M * mana (reading man iptables)
1149367636 M * bonbons that's possible -s VSERVER_NET -d EXT_IP -p tcp --dport 123 -j DNAT --to GUEST
1149367724 M * mana cool i will try that. I have the configuration work for each port anyway, so one more rule doesn't hurt ..
1149367796 M * mana for PREROUTING right?
1149367862 J * lilalinux ~plasma@dslb-084-058-220-005.pools.arcor-ip.net
1149367905 M * bonbons I have it
1149367989 M * bonbons iptable -t NAT -A OUTPUT -s VSERVER_NET -d EXT_IP -p tcp --dport 123 -j NAT --to GUEST (that's for guest to guest)
1149368027 M * bonbons PREROUTING and POSTROUTING are for traffic entering or leaving the machine, not machine-internal one!
1149368059 M * mana the rules i used before refered all to these chains ....
1149368069 M * bonbons prerouting part is for traffic coming from the internet
1149368134 M * mana aj okay :)
1149368206 M * bonbons and postrouting is for what is leaving the machine
1149368255 M * mana aaah that Works! :DDD
1149368261 M * mana i love you! :DDD
1149368293 M * bonbons having the netfilter flowchart by hand would help a lot ;)
1149368324 M * mana aaah netfilter flowchart? is netfilter similar to iptables? ;)) and where can i get that chart from? :D
1149368345 M * bonbons netfilter is what is inside the kernel, IPTable is the userspace command
1149368358 M * mana i am mroe a programemr than a administrator, expecialy when it coems to cross-machine-cross-network thinks .. but that knowledge can never be bad
1149368376 M * mana ok and where's that flowchart?
1149368597 M * bonbons don't know, I have it in some books, need to loo which ones...
1149368686 M * mana ah got it :)
1149368692 M * mana http://www.aptalaska.net/~jclive/IPTablesFlowChart.pdf
1149368729 M * mana googl's your friend ... at least sometimesand when they dont cancal your addwords account ...ehm
1149368985 M * bonbons heh :)
1149369026 M * mana ho
1149369128 M * bonbons that's the kind of poster to stick to the wall ;)
1149369174 M * mana yep, nice to print out
1149369214 M * bonbons exactly, just maybe remove the noise around before printing
1149369288 M * mana jep. A global linux documentation repository, or a wiki-network would be great .. you cannot trust search engines to find the relevant stuff ..
1149369336 M * mana and this chart is relevant. would have found it without your hint
1149369370 M * bonbons finding the information is most often the hard part - what keyword to use
1149369378 M * mana right
1149369414 M * mana btw. what work of yours did i make you suspend?
1149369549 M * bonbons you suspended the idle task, between ipv6 patching
1149369577 M * mana whu lucky me :). Thank you.
1149369596 M * mana well, its late now. see you later maybe
1149369620 M * bonbons same for me, you made me refresh iptables in my mind!
1149369643 M * mana ah, win-win situation, fine. :)
1149369672 M * mana goodbye channel
1149369688 Q * mana Quit: using sirc version 2.211+KSIRC/1.3.12
1149369923 Q * Skram Server closed connection
1149369935 J * Skram ~MarkS@admins.sentiensystems.net
1149370389 J * s0undt3c1 ~s0undt3ch@bl7-242-101.dsl.telepac.pt
1149370827 Q * s0undt3ch Ping timeout: 480 seconds
1149371384 Q * redtux Server closed connection
1149371419 Q * shedi Quit: Leaving
1149371705 J * redtux ~redtux@pc199.pub.univie.ac.at
1149372885 Q * Wonka Ping timeout: 480 seconds
1149373129 Q * dna Quit: Verlassend
1149373312 Q * DarthVader Quit: Leaving
1149376805 M * orionpanda I'm having some problems with testme.sh; it's returning with: "chcontext is working\n chbind failed! ipv4root is now 127.0.0.1"
1149376819 M * orionpanda i have legacy_vserver_api enabled in kernel config
1149376838 M * doener util-vserver 0.30.210?
1149376847 M * doener is the legacy version thingy enabled?
1149376868 M * doener if so, disable that (or legacy support alltogether)
1149376875 M * orionpanda yes, legacy is enabled 
1149376891 M * orionpanda yes, util-vserver-0.30.210
1149376914 M * doener well, there are three legacy options... legacy, legacy net and legacy version foobar
1149376923 M * orionpanda what should I set them too?
1149376934 M * doener if the version faking is enabled, .210 breaks
1149376973 M * doener you can disable all legacy options. ie. disable "legacy api" and enable "disable legacy networking"
1149377009 M * orionpanda ok. let me try that
1149377276 M * orionpanda also, what does the vserver inode tag propagation option in .config do?
1149377333 M * doener it's related to xid tagging for files... I don't remember what exactly it is good for... daniel_hozac?
1149377363 M * daniel_hozac i believe it's for propagating xid=xxx mount options to mounts below that subtree, but i'm not sure.
1149377379 M * daniel_hozac s/subtree/mount/
1149377437 M * daniel_hozac tagid=, sorry.
1149377558 J * derjohn2 ~aj@dslb-084-058-243-005.pools.arcor-ip.net
1149377574 M * orionpanda hmm. i thought it might have something to do with problems I'm having with cow
1149377588 M * doener what problems?
1149377596 M * orionpanda so: touch a; ln a b; setattr --iunlink a; echo "a" > a;
1149377599 M * orionpanda that yields:
1149377604 M * orionpanda "too many links"
1149377611 M * orionpanda and create's a file named; a?
1149377664 M * daniel_hozac what version?
1149377669 M * doener hm, works fine here... which kernel?
1149377683 M * orionpanda 2.6.17-rc5.-vs2.1.1-rc21.3
1149377727 M * daniel_hozac you might want to try the 2.6.16 versions instead.
1149377744 M * orionpanda here's the output from vserver debug: http://pastebin.com/756703
1149377758 M * orionpanda oh. was cow support removed in 2.6.17?
1149377792 M * doener no, but the port might be buggy ;)
1149377800 M * daniel_hozac no, but the 2.6.17 port was done in a hurry from what i understand.
1149377823 M * doener daniel_hozac: do you happen to know which patches make the difference between rc21 and rc21.3?
1149377830 M * orionpanda good to know. i'll try the most recent 2.6.16 version instead
1149377844 M * daniel_hozac the deltas before .3 in Experimental, i guess :)
1149377909 M * orionpanda are COW and BME available as seperate patches that I can apply?
1149377919 M * daniel_hozac against what, exactly?
1149377928 M * orionpanda plain vanilla 2.6.16 kernel
1149377953 M * doener daniel_hozac: hm, I'm pretty sure some of them are not in .3... eg. the zeng one
1149377972 M * daniel_hozac doener: well, yeah, the zeng one was a debugging one.
1149378030 M * doener and vtime?
1149378051 M * daniel_hozac vtime seems to be in it.
1149378190 J * shedi ~siggi@inferno.lhi.is
1149378245 M * orionpanda As far as seperate COW/BME patches go, the latest patch I can find is from Feb-06: http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1.0.9/37_cow.diff
1149378266 M * orionpanda Is anything more recent available?
1149378271 M * daniel_hozac COW has been changed quite a bit.
1149378275 M * daniel_hozac and i don't think so.
1149378283 M * orionpanda Yes, so I've read.
1149378332 M * daniel_hozac a new split is one of the things on the todo list for the releases though, so they should be available RSN.
1149378351 M * doener maybe Sam has a version that can be broken out in his git tree? IIRC he has done quite some work to transform the patches into a patch series
1149378397 M * daniel_hozac yeah, that's quite possible.
1149378415 M * doener mugwump_: around/listening?
1149378430 M * orionpanda you don't happen to know his git:// url do you?
1149379005 M * doener git://vserver.utsl.gen.nz/git/vserver.git
1149379018 M * doener http://vserver.utsl.gen.nz/gitweb
1149379052 M * daniel_hozac hmm, my googling says git://utsl.gen.nz/vserver
1149379104 M * doener gitweb also says so... maybe it was changed since sam sent his mail to the ml, I just copied the urls from there
1149379170 Q * bonbons Quit: Leaving