1191975314 Q * brc synthon.oftc.net charm.oftc.net 1191976298 Q * fatgoose Quit: fatgoose 1191976637 J * friendly12345 ~friendly@ppp121-44-205-137.lns3.mel4.internode.on.net 1191977002 Q * hparker Quit: peer reset by connection 1191977549 J * fatgoose ~samuel@modemcable179.138-200-24.mc.videotron.ca 1191977637 Q * fatgoose 1191978179 J * fatgoose ~samuel@modemcable179.138-200-24.mc.videotron.ca 1191978198 Q * fatgoose 1191978977 Q * meandtheshell Quit: Leaving. 1191980292 Q * nospoonuser Ping timeout: 480 seconds 1191982363 J * brc bruce@megarapido.cliquerapido.com.br 1191983589 Q * FireEgl Ping timeout: 480 seconds 1191984344 J * nospoonuser ~nospoonus@n18-241.dsl.vianetworks.de 1191984907 J * nospoonu1er ~nospoonus@n18-241.dsl.vianetworks.de 1191984930 Q * nospoonuser Read error: Connection reset by peer 1191985030 J * FireEgl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa 1191985570 Q * FireEgl Ping timeout: 480 seconds 1191986373 Q * Piet Quit: Piet 1191986409 Q * nospoonu1er Read error: Connection reset by peer 1191986412 J * nospoonuser ~nospoonus@n18-241.dsl.vianetworks.de 1191986806 Q * puck Quit: Coyote finally caught me 1191988315 J * zLinux_ ~zLinux@212.118.99.51 1191988509 Q * zLinux Ping timeout: 480 seconds 1191992207 J * fatgoose ~samuel@76-10-154-145.dsl.teksavvy.com 1191992310 Q * friendly12345 Quit: Leaving. 1191992496 J * balbir ~balbir@122.167.64.109 1191993022 J * friendly12345 ~friendly@ppp121-44-205-137.lns3.mel4.internode.on.net 1191993217 N * Bertl_zZ Bertl_oO 1191993224 M * Bertl_oO back later ... 1191993739 Q * Aiken Read error: Operation timed out 1191994122 J * fatgoose_ ~samuel@76-10-154-145.dsl.teksavvy.com 1191994122 Q * fatgoose Read error: Connection reset by peer 1191994275 J * JonB ~NoSuchUse@kg1-20.kollegiegaarden.dk 1191996856 J * virtuoso_ ~s0t0na@ppp91-122-27-37.pppoe.avangard-dsl.ru 1191997264 Q * virtuoso Ping timeout: 480 seconds 1191999213 J * ntrs_ ~ntrs@79.125.225.225 1191999947 Q * ntrs_ Ping timeout: 480 seconds 1192000622 Q * balbir Ping timeout: 480 seconds 1192000798 J * ema ~ema@rtfm.galliera.it 1192001108 Q * fatgoose_ Quit: fatgoose_ 1192001130 Q * ema Quit: leaving 1192001310 J * balbir ~balbir@122.167.92.66 1192002471 J * Aiken ~james@ppp121-45-206-11.lns1.bne1.internode.on.net 1192002582 J * emtty ~eric@dynamic-acs-24-154-85-144.zoominternet.net 1192002644 Q * JonB Ping timeout: 480 seconds 1192002955 J * larsivi ~larsivi@85.221.53.194 1192002980 J * gebura ~gebura@173.201.101-84.rev.gaoland.net 1192002994 M * gebura hi 1192002997 M * daniel_hozac hello 1192003029 J * amax ~a@r5ct9.net.upc.cz 1192003034 M * amax hi all 1192003055 M * amax any experts/developers are here ? 1192003082 M * daniel_hozac i suppose so. 1192003088 M * amax typical problem.. one guest can see other's guest internal ip 1192003102 M * amax cant find solution on wiki/docs 1192003116 M * daniel_hozac internal meaning what? 1192003160 M * amax well, each guest have external ip for extenrnal services, and dummy0 (for example) for local bind (loopback replacement) 1192003188 M * amax i need to get one private interface per guest not shareable to other guest 1192003241 M * daniel_hozac in that case, iptables is your friend. 1192003249 M * amax even I create now dummy0 with 10.1.0.1 and dummy1 with 10.2.0.1 this guests can ping each other and see local services 1192003263 M * daniel_hozac interfaces don't matter, all that traffic will go over lo. 1192003334 M * daniel_hozac if you would actually be using dummyX, the traffic wouldn't get anywhere. 1192003336 M * amax so, what is typical solution (example) from productive working server ? 1192003340 M * amax no 1192003359 M * amax i use dummy0 in one guest and dummy1 in second 1192003363 M * amax different subnets 1192003368 M * amax each can see others 1192003374 M * daniel_hozac as is to be expected. 1192003414 M * amax so, im looking for typical pattern (doc or example) to create protected guests 1192003430 M * daniel_hozac for guest in guests; do iptables -A OUTPUT -s ! -d -j DROP; done 1192003434 M * amax even if im using vlans, this didnt helps.. 1192003443 M * daniel_hozac as i said, interfaces don't matter. 1192003451 M * daniel_hozac host-local traffic will _always_ use lo. 1192003472 M * daniel_hozac where the address is assigned is of no importance whatsoever. 1192003473 M * amax i have disabled in guests lo 1192003507 M * daniel_hozac that doesn't matter. 1192003529 M * daniel_hozac Linux-VServer does IP address isolation, meaning all the networking happens on the host, guests are just limited to a subset of the IP addresses. 1192003534 M * amax nflags ~lback_remap 1192003534 M * amax ~hide_lback 1192003557 M * daniel_hozac so you have 2.3, but you're not using the lback feature which already provides what you want? 1192003570 M * daniel_hozac (though they're not restriced yet) 1192003575 M * amax no im trying not use 127.0.0.x 1192003582 M * gebura amax, what mask did you use for your vservers ? 1192003596 M * amax due to exposing service to public 1192003599 M * amax well 1192003601 M * amax mask.. 1192003607 M * gebura network mask 1192003612 M * amax for 127 it was /16 1192003618 M * amax or /32 1192003623 M * gebura for dummyX ? 1192003633 M * amax for dummy got any variant 1192003644 M * Loki|muh I've some strugle with cpu scheduling here... I set sched_hard as flag for this context, but only when I use insanely high numbers with vsched, there is any effect... 1192003647 M * Loki|muh vsched --xid 150 --fill-rate 1 --interval 754200000 --tokens 50 --tokens-min 20 --tokens-max 100 --force 1192003653 M * daniel_hozac it's not relevant. 1192003663 M * daniel_hozac amax: just block it with iptables, as i showed you above... 1192003674 M * amax I see man, thanks 1192003680 M * amax but 1192003702 M * amax here is the one problem.. why we cant get 'non routable' interfaces ? 1192003713 M * amax just simple dummyX ? 1192003714 M * daniel_hozac Loki|muh: do you have CONFIG_VSERVER_HARDCPU=y? 1192003738 M * Loki|muh yes, its the debian etch kernel 1192003744 M * daniel_hozac amax: it has nothing to do with interfaces. 1192003752 M * daniel_hozac Loki|muh: hmm? i thought that had it disabled. 1192003766 M * daniel_hozac amax: all host-local traffic will use lo. 1192003783 M * Loki|muh |>pc1:/vservers# zgrep HARDCPU /proc/config.gz 1192003783 M * Loki|muh |>CONFIG_VSERVER_HARDCPU=y 1192003783 M * Loki|muh |>CONFIG_VSERVER_HARDCPU_IDLE=y 1192003788 M * gebura amax, can you give me an example of networkmask you have on your vserver ? 1192003795 N * virtuoso_ virtuoso 1192003797 M * daniel_hozac amax: note: 2.3 should have lback isolation RSN. 1192003838 M * daniel_hozac Loki|muh: interesting... okay, so how are you testing it? running cpuhog inside the guest and checking with vtop? 1192003844 M * Loki|muh yes 1192003849 M * amax its /26 on external and 192.168.0.33/24 on internal and 10.1.0.1/24 on dummy0 1192003877 M * Loki|muh its an amd64 dualcore 1192003903 M * daniel_hozac Loki|muh: i seem to recall there being problems with the scheduler in the etch kernel. could you try a bp.o kernel instead? 1192003906 M * amax so each guest should use dummy0 to bind local services and i should put to "initialize" file iptables call to protect guests 1192003943 J * jmcaricand ~user@d77-216-233-159.cust.tele2.fr 1192003957 M * Loki|muh i try to find a machine to test it ;) 1192004143 M * amax one huge problem of migration 1192004166 M * eyck where can I find 2.6.23 vs2.2.0.4 patch? 1192004171 M * amax many guests have own 10.0.0.1/24 1192004185 M * amax i should rewite tonns of configs. .^( 1192004196 M * amax to separate networks.. 1192004236 M * daniel_hozac 2.3's automatic lback feature uses 127.xid.1. 1192004338 M * daniel_hozac or, rather, nid :) 1192004356 M * amax nice.. when is expected to appears ? 1192004392 M * daniel_hozac what? 1192004408 M * amax is it useable already? 2.3 ? 1192004426 M * daniel_hozac lback is not isolated yet. 1192004435 M * daniel_hozac 2.3.0.27 should have that though. 1192004456 M * amax ok thanks ^) 1192004459 M * amax ah one more q 1192004461 M * amax vxW: xid=105 did lookup hidden ffff81015d172dc0[#0,4026531874] -/proc/bus-. 1192004468 M * amax my syslog file full 1192004476 M * amax what does it mean ? 1192004491 M * daniel_hozac that the guest with xid 105 tried to access /proc/bus. 1192004528 M * amax why can i see pid of process in warning ? :) 1192004533 M * amax cant* 1192004606 A * amax tesing new solution with iptables 1192004656 M * amax ah.. one more trouble ^) in stable 2.2 is fully unusable cpusets 1192004666 M * amax they are didnt works at all . 1192004676 M * daniel_hozac hmm? 1192004677 M * amax due to wrong syntax of using 1192004677 M * daniel_hozac how so? 1192004678 M * amax sure 1192004716 M * amax will explaing just later 1192004722 M * daniel_hozac (note that cpusets is a mainline feature that is completely untouched by Linux-VServer) 1192004733 M * amax well. 1192004742 M * amax its presents in documentation 1192004745 M * amax but not works ^) 1192004798 M * amax http://www.nongnu.org/util-vserver/doc/conf/configuration.html here is doc to configs structure 1192004824 M * daniel_hozac yes, i know. i'm the one who updates it ;) 1192004842 M * amax but any try to use it, give me error with cpusets 1192004848 M * amax in functions library 1192004864 M * daniel_hozac and you did create /dev/cpuset and mount it? 1192004871 M * amax yes! 1192004932 M * daniel_hozac works fine here. 1192005028 M * amax cpusets "works" alone well 1192005028 M * amax but vserver scripts fail to create himself nodes there 1192005028 M * amax just per declared sets 1192005028 M * amax also, in libraries 1192005028 M * amax he uses nonexisting attributes to cpusets 1192005030 M * amax ok, in 30 min i will try reproduce it ) 1192005045 M * daniel_hozac such as? 1192005072 M * daniel_hozac virtualized is added by a patch. 1192005232 M * Loki|muh daniel_hozac: seems to work with 2.6.22-2-vserver-amd64, I will test it tonight on the real system, thanks for the hint 1192005320 M * daniel_hozac Loki|muh: okay, good. you might want to file a bug for etch.. 1192005370 J * amax_ ~a@r5ct9.net.upc.cz 1192005377 M * amax_ == thanks for help 1192005380 J * Guest1249 ~ensc@www.sigma-chemnitz.de 1192005393 M * daniel_hozac you're welcome! 1192005394 M * amax_ solution with iptables "works" well 1192005400 M * amax_ ^) 1192005444 A * amax_ bow before daniel_hozac 1192005496 M * amax_ so, i have made easy script to make private dummy address protected via initialize script 1192005512 Q * amax Ping timeout: 480 seconds 1192005515 M * daniel_hozac which will be obsolete in a day or two ;) 1192005517 J * FireEgl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa 1192005523 M * amax_ hmm.. 1192005528 M * amax_ why? ^)) 1192005540 M * amax_ 2.3 coming soon ? 1192005546 M * daniel_hozac 2.3 already exists. 1192005565 M * daniel_hozac 2.3.0.27 should have the "guests can't talk to eachother's lback" fix. 1192005583 J * dna ~dna@97-251-dsl.kielnet.net 1192005609 M * daniel_hozac (and 2.3.0.27 should be available in a day or so, depending on how many things Bertl_oO decides to add) 1192005631 M * amax_ is this coming stable? 1192005645 M * daniel_hozac 2.3 is devel. 1192005678 M * daniel_hozac and given that we just started this devel series, it's gonna take a while before anything in it becomes stable. 1192005700 M * daniel_hozac but, i'm running 2.3 on all my servers. 1192005730 M * amax_ ok now i have 4 8cpus servers for vserver. 1192005758 M * amax_ ... using stable.. 1192005777 M * amax_ also, should I use grsec patch? 1192005789 M * amax_ or too buggy atm ? 1192005791 M * daniel_hozac that's up to you to decide... 1192005813 M * amax_ well, one box will be designed for pure development 1192005825 M * amax_ many users will get #root in guests 1192005890 M * amax_ does default isolation enought to uses it w/o problems ? 1192005906 M * larsivi Heya gents 1192005910 M * daniel_hozac well, yes. otherwise it'd be a serious security bug... 1192005927 M * larsivi trying to do vserver build -m rsync, but how to incorporate the --source argument? 1192005954 M * daniel_hozac vserver new build -m rsync --hostname... -- --source ... 1192005980 M * amax_ also.. vserver-copy didnt work with new structure of /etc/vserver 1192005990 M * daniel_hozac which is why it's in the legacy package. 1192005999 M * daniel_hozac along with all the other legacy scripts. 1192006009 M * amax_ any new scripts are exists ? 1192006018 M * daniel_hozac vserver ... build -m clone/rsync. 1192006037 M * daniel_hozac note that they don't handle configuration at this point. 1192006047 M * amax_ isee 1192006056 M * larsivi daniel_hozac: 'new' is the name of the new vserver ? 1192006060 M * daniel_hozac larsivi: yes. 1192006210 M * larsivi daniel_hozac: hmm, do you have a complete example? (for a debian system) 1192006211 M * amax_ so. about cpusets 1192006272 M * daniel_hozac larsivi: vserver lenny2 build -m rsync --hostname lenny2.test --interface eth0:10.2.0.3/24 --context 52 -- --source lenny 1192006280 M * amax_ making service to create cpuset dir. http://rafb.net/p/kb4nJk41.html (service for gentoo) 1192006362 M * amax_ got cpuset active 1192006365 M * amax_ cpuset on /dev/cpuset type cpuset (rw) 1192006392 Q * gebura Quit: Quitte 1192006474 M * daniel_hozac amax_: and the problem? 1192006527 M * amax_ WARNING: Failed to create or CPUSET "test1" does not exist! Not using it! 1192006542 M * amax_ ** /usr/lib64/util-vserver/vserver.functions: line 765: echo: write error: No space left on device 1192006559 M * amax_ just got 3 files in cpuset dir 1192006568 M * amax_ name cpus cpu_exclusive 1192006568 M * daniel_hozac mems, cpus and name? 1192006574 M * daniel_hozac you need mems. 1192006592 M * amax_ mems 0 ? 1192006596 M * daniel_hozac otherwise the cpuset doesn't have access to any memory. 1192006607 M * daniel_hozac and it refuses to add the current task to it. 1192006615 M * daniel_hozac well, whatever zones you want. 1192006621 M * amax_ ok which values for example ? 1192006626 M * daniel_hozac preferably the one attached to the CPU. 1192006649 M * amax_ hm 1192006650 M * amax_ sure 1192006652 M * amax_ works 1192006656 M * daniel_hozac grep Mems /proc/self/status 1192006660 M * amax_ plz.. describe it in wiki ? 1192006669 M * amax_ many pplz bored with this problem 1192006686 M * amax_ Mems_allowed: 1 1192006686 M * daniel_hozac please do so... 1192006693 M * amax_ kk 1192006738 J * gebura ~gebura@173.201.101-84.rev.gaoland.net 1192006894 M * amax_ nice,now it works well ^) 1192006896 M * amax_ thanks again 1192006921 M * amax_ atm what is the best way to disk space limitation per guest ? 1192006926 M * amax_ lvm2+reiserfs ? 1192006944 M * daniel_hozac depends on your requirements. 1192006967 M * amax_ or quotas ? 1192006972 M * daniel_hozac disk limits work well for me. 1192006976 J * Julius ~julius@p57B266F1.dip.t-dialin.net 1192006988 M * daniel_hozac but if you want user/group quotas, you need to go the LVM route. 1192006999 M * daniel_hozac (at this point, anyway) 1192007004 M * larsivi daniel_hozac: hmm, can I see the progress of rsync? 1192007040 M * amax_ well im looking solution to make backups. 1192007047 M * daniel_hozac larsivi: you can specify rsync options with -o, but then you don't get the defaults. 1192007049 M * amax_ lvm2 snapshots ? 1192007070 M * larsivi daniel_hozac: ah, seems it's done now 1192007450 J * JonB ~NoSuchUse@130.227.63.19 1192008059 M * larsivi daniel_hozac: it seems the copy went fine now, thank you very much 1192008071 M * larsivi apache is making some strange messages though 1192008075 M * daniel_hozac you're welcome! 1192008081 M * daniel_hozac such as? 1192008083 M * larsivi 98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 1192008091 M * larsivi no listening sockets available, shutting down 1192008110 M * daniel_hozac and what addresses have you assigned to that guest? 1192008121 M * larsivi connecting to port 80 works fine though, and it seems to be running 1192008126 M * daniel_hozac do they overlap with another guest that is also running apache? 1192008151 M * larsivi they shouldn't be, the address should be the same as the old one which is no longer running 1192008170 M * daniel_hozac are you sure about that? 1192008195 M * daniel_hozac grep
/proc/virtnet/*/info 1192008591 M * larsivi daniel_hozac: i don't get any hits, neither here nor there with that 1192008702 M * daniel_hozac none at all? 1192008720 M * daniel_hozac then the guest probably assigned the address you think it is, as that's the file that lists them. 1192008729 M * daniel_hozac s/assigned/isn't assigned/ 1192008743 M * larsivi ah, there it was, sorry - but only on the new host 1192008756 M * daniel_hozac and just one match? 1192008764 M * larsivi yes 1192008778 M * daniel_hozac is the new host running a web server? 1192008795 M * larsivi I hope not! 1192008805 M * daniel_hozac check netstat -pnlt to be sure... 1192008817 M * larsivi hah, it was 1192008824 M * larsivi wtf 1192008886 M * larsivi ok, now things are looking more sane :) 1192008928 M * daniel_hozac good! 1192008943 M * larsivi I wonder when that webserver was installed :) 1192009045 M * amax_ daniel_hozac.. should I create lo interface with 127.0.0.1 now in guests ? or this is security hole ? 1192009062 M * daniel_hozac amax_: "now"? 1192009074 M * amax_ with 2.2 vserver 1192009101 M * daniel_hozac if you let guests share an IP address (such as 127.0.0.1) they will be able to interfere with one another. 1192009116 M * daniel_hozac i.e. one guest binding to port 80 would prevent others from doing so. 1192009129 M * amax_ i see, so how to disable 127.0.0.1 complete ? 1192009152 M * amax_ for guests 1192009158 M * amax_ nflags ? 1192009165 M * daniel_hozac with 2.2, 127.0.0.1 is rewritten to the guest's first IP address. 1192009184 M * amax_ ye, but if i want to disable it too ? 1192009193 M * daniel_hozac change the code :) 1192009200 M * amax_ nfalgs works ? 1192009202 M * amax_ or ? 1192009206 M * daniel_hozac no. 1192009219 M * daniel_hozac the destination address rewriting is hard-coded. 1192009232 M * amax_ iptables ? 1192009242 M * daniel_hozac what is it that you want to achieve? 1192009250 M * amax_ example 1192009272 M * amax_ i want to detect my wrongly configured service 1192009280 M * amax_ while migration 1192009287 M * amax_ some of them uses 127.0.0.1 1192009302 M * amax_ i dont want to expose it to external ip automatically 1192009334 M * amax_ simple way is remove 127.0.0.1 and find errors of binding/connecting 1192009375 M * amax_ just a huge migration issue to me now 1192009448 M * larsivi you know, when I entered #vserver on freenode, and found it to be existing but empty, I feared vserver was a dead project :P I'm glad I was wrong :) 1192009464 M * larsivi but you should try to have it say where to find you 1192009723 M * daniel_hozac amax_: and why not make your private dummyX IP the first one? 1192009748 M * daniel_hozac larsivi: http://linux-vserver.org/Communicate is not verbose enough? 1192009773 M * amax_ no 1192009776 M * amax_ not enought 1192009788 M * amax_ no point to irc network/server 1192009798 M * amax_ oftc was found in google 1192009802 M * larsivi daniel_hozac: sure it is, I just hang around on freenode anyways and opened up #vserver as my first action 1192009823 M * larsivi ah, good point, the server isn't actually mentioned 1192009827 M * daniel_hozac ah, yes, it's only when you hover over the link. 1192009828 M * amax_ first one.. dummy0 hm.. great idea 1192009833 M * daniel_hozac feel free to fix it... 1192009842 M * amax_ lazy )) 1192009849 M * daniel_hozac that's my middle name! :) 1192009912 M * amax_ so.. 0 iface is dummy0 1192009913 M * amax_ hm 1192010000 M * amax_ hm ping not works.. 1192010011 M * amax_ strange.. iptables blocking ? 1192010013 M * amax_ hm.. 1192010881 M * daniel_hozac ah, yes, that's right. if you make it the first address, source selection is going to pick that. 1192010920 M * daniel_hozac i think we can fix that... 1192011109 J * DavidS ~david@193.170.138.34 1192011507 P * friendly12345 1192011726 M * daniel_hozac amax_: hmm, what's your network setup like? i think the current code should already do the right thing. 1192011735 M * amax_ hm 1192011746 M * amax_ in some guests ping 127.0.0.1 works, in some - not 1192011749 M * amax_ amazed. 1192011758 M * amax_ but 127.0.0.2 works 1192011782 M * daniel_hozac ping 127.0.0.1 shouldn't work in any... 1192011796 M * daniel_hozac ping is a really bad tool to test these things. use nc if you want accurate results. 1192011810 M * amax_ ok 1192011858 M * amax_ but 127.0.0.2 ping works 1192011871 M * amax_ damn ) 1192011872 J * Yvo ~yvonne@91.64.217.106 1192011991 M * amax_ ah.. 1192011996 M * amax_ hehe 1192012264 M * amax_ so 127/8 still present.. ( 1192012298 M * amax_ hm 1192012312 M * amax_ strange results will check more now 1192012313 M * daniel_hozac iptables -A OUTPUT -s ! 127.0.0.0/8 -d 127.0.0.0/8 -j DROP 1192012441 M * amax_ no.. bad idea ^) 1192012479 M * daniel_hozac if you don't want 127.0.0.0 to be reachable from guests, it's the easiest way. 1192012529 M * amax_ but i can able to listening on 1192012555 M * daniel_hozac what? 1192012568 M * amax_ bind to address 1192012587 M * amax_ ok will explore it now 1192012716 M * daniel_hozac you're able to bind to 127.x.y.z from a guest without assigning the guest that IP? 1192012792 M * amax_ checking now 1192012839 M * amax_ some strange bugs atm.. 1192012929 M * amax_ checked. no. cant bind 1192012985 M * amax_ also ping 127.0.0.2 works but 127.0.0.1 not ^-)) 1192013030 M * amax_ dummy0 is inet addr:10.0.0.2 Bcast:0.0.0.0 Mask:255.255.255.255 1192013049 M * amax_ probably this is a solution.. 1192013106 M * amax_ no.. 1192013115 M * amax_ sshd binds ok to 127.0.0.1 1192013131 M * amax_ will check is it mapped to dummy0 1192013252 Q * jmcaricand Ping timeout: 480 seconds 1192013252 Q * gebura Read error: Connection reset by peer 1192013308 J * gebura ~gebura@173.201.101-84.rev.gaoland.net 1192013384 M * amax_ so, confirm the solution 1192013395 M * amax_ 1. dummy0 should be first ip 1192013406 M * amax_ with 0 1192013411 M * amax_ and with /32 netmask 1192013419 M * amax_ just an ip 1192013442 M * amax_ 2. 127.0.0.1 will not ping but bind will works to dummy0's ip 1192013475 M * amax_ 3. with iptables protecting dummy0 ip we got a private internal ip only 1192013515 M * amax_ thats works to me well, so i can pretty use 127.0.0.1 now and it really seems like a PRIVATE loopback, isolated from others uests 1192013518 M * amax_ guests* 1192013536 M * amax_ its a solution to anyone who do migration 1192013553 M * amax_ and can rewrite tonns of configs 1192013557 M * daniel_hozac and with 2.3, everything just works :) 1192013564 M * amax_ daniel_hozac, thanks for advice 1192013569 M * daniel_hozac you're welcome. 1192013584 M * amax_ 2.3 for me will be in 2-3 months 1192013586 M * amax_ or later 1192013598 M * amax_ with stable kernels and fixed bugs 1192013627 M * amax_ i just found really USEABLE solution 1192013635 M * amax_ to clean migration 1192013640 M * amax_ for everyone 1192013648 M * amax_ just put this to wiki? ok ? 1192013655 M * daniel_hozac feel free. 1192013659 M * amax_ or .. hm i can.. 1192013687 M * amax_ only cant understand why ping not works ^) 1192013705 M * daniel_hozac because ping is weird. 1192013725 M * gebura amax_, maybe should you try iptables -L -v [-t nat] 1192013747 M * amax_ no, i found clean solution 1192013749 M * daniel_hozac -n 1192013767 M * gebura you will see packets accepted, rejected, forwarded by iptables and sorted by rule 1192013783 M * amax_ dummy0 any ip/32 now isolated, 127.0.0.1 -> mapped prefect 1192013838 M * amax_ nat is solution for other kind of guests, now was a -migration- problem (security) 1192013843 M * amax_ its fixed now 1192013863 M * amax_ 127.0.0.1 now is private and secured, i not need to fix toons of configs, im happy ) 1192013886 M * amax_ this is more easy way btw )) 1192014132 M * amax_ thanks all, will back soon ) 1192014150 Q * amax_ 1192014569 Q * bastiaan_ Ping timeout: 480 seconds 1192014751 J * CWC ~CWC@89-215-37-177.2073053861.ddns-lan.pl.ekk.bg 1192014874 Q * CWC 1192014939 J * bastiaan_ ~bastiaan@sh.vhl.welmers.net 1192016523 M * Bertl_oO okay, I need a nap now .. will be back later ... 1192016532 N * Bertl_oO Bertl_zZ 1192017271 Q * transacid Remote host closed the connection 1192017663 J * amax ~a@r5ct9.net.upc.cz 1192017679 M * amax daniel_hozac hi again ) 1192017686 M * amax one more q 1192017709 M * amax in scripts dir i can create pre-start and post-stop etc 1192017734 M * amax what is easy way to detect inside script which one guest is operating ? 1192017755 M * amax i havent found any variable name points to /etc/vservers/myguest 1192017781 M * amax or just "myguest" if exploring env inside script 1192017787 J * transacid ~transacid@transacid.de 1192017816 M * amax so what is universal way to get direct link to /etc/vservers/${myguest} ? 1192017820 M * daniel_hozac "$2" 1192017826 M * daniel_hozac is the name of the guest. 1192017827 M * amax checking. 1192017854 M * amax THANKS ^) 1192018051 Q * eSa| Quit: Coyote finally caught me 1192018078 J * esa ~esa@ip-87-238-2-45.adsl.cheapnet.it 1192018082 N * esa eSa| 1192018183 M * amax %-)) IP=`cat /etc/vservers/${2}/interfaces/0/ip` 1192018185 M * amax nice nice 1192018327 J * Piet ~piet@tor.noreply.org 1192018560 M * amax daniel_hozac how do you think, whats is correct place to place firewall ruleses per each guests ? 1192018572 Q * JonB Ping timeout: 480 seconds 1192018598 M * amax in the scripts pre-start.d/ ? 1192018606 M * amax and post-stop.d/ ? 1192018613 M * daniel_hozac sure. 1192018624 J * ema ~ema@rtfm.galliera.it 1192018629 M * amax just name it like 0 1 2 ? 1192018641 M * amax per interface rules.. 1192018651 M * daniel_hozac however you see fit :) 1192018708 M * amax love vserver much 1192018719 M * amax great thing 1192018816 A * harry just has 1 set of iptable rules 1192018837 M * harry i don't see a reason to start/stop firewall rules with each guest start/stop 1192018867 M * daniel_hozac well, if you move guests between systems, it's probably the easiest way. 1192018885 M * harry true 1192019147 M * amax well 1192019161 M * amax i can change rule, and simple restart guest 1192019172 M * amax this is good place to place it ^) 1192019195 M * amax just correct rule adding/removing 1192019214 M * amax can I hide interface for guest ? 1192019233 M * daniel_hozac all interfaces on which it does not have an address are hidden by default. 1192019246 Q * Aiken Quit: Leaving 1192019286 M * amax i see ) 1192019790 M * matti Hi harry :) 1192020554 M * Red_Devil can someone explain this message in my dmesg ? 1192020562 M * Red_Devil vxW: xid=170 messing with the procfs. 1192020601 M * daniel_hozac the guest with xid 170 tried to modify a file in proc. 1192020622 M * Red_Devil ok, its just a warning 1192020634 M * daniel_hozac it's more of a notice really. 1192020640 J * JonB hidden-use@192.38.9.151 1192020651 M * Red_Devil ok :) 1192020754 M * eyck could we also get a notice about which pid tried to modify which file in proc? 1192020910 Q * JonB 1192021024 M * amax i want to know this same ) 1192021051 J * CWC ~CWC@89-215-37-177.2073053861.ddns-lan.pl.ekk.bg 1192021502 J * JonB hidden-use@192.38.9.151 1192021922 Q * hallyn_ Quit: leaving 1192022072 M * ard ls 1192022074 M * ard eh 1192022077 M * ard wrong window 1192022107 M * eyck bad user, no quota for you 1192022122 M * ard :-) 1192022166 M * sid3windr cool, no quota!:) 1192022917 Q * CWC Quit: Client exiting 1192023087 Q * larsivi Quit: Konversation terminated! 1192023223 Q * JonB Quit: This computer has gone to sleep 1192025173 J * JonB ~NoSuchUse@kg1-20.kollegiegaarden.dk 1192025854 M * ard Hmmmm... downloading 2.6.23 in 2.5s... 1192025857 M * ard that's a tad slow 1192025893 M * daniel_hozac indeed. 1192025987 M * daniel_hozac 1.2 here. :) 1192025992 M * ard 8-D 1192025998 M * ard our mirror is to slow :-( 1192026043 J * meandtheshell ~markus@85.127.117.208 1192026231 M * ard Heh... they suggest here to do a GET | tar xj, since that's faster than writing *and* reading from disk :-) 1192026331 Q * JonB Quit: This computer has gone to sleep 1192026876 J * fatgoose ~samuel@76-10-156-251.dsl.teksavvy.com 1192027369 J * dowdle ~dowdle@scott.coe.montana.edu 1192027639 M * zbyniu is possible to have / of guest over NFS? 1192027654 M * zbyniu secure-mount: flock(): I/O error 1192027660 M * zbyniu Failed to update mtab-file 1192027692 M * zbyniu 2.6.18-4-vserver-sparc64 from debian, util-vserver_0.30.212-1_sparc.deb 1192027741 M * daniel_hozac does the NFS mount support locking? 1192027763 M * daniel_hozac IIRC i made a patch just for that purpose... 1192027853 N * _mountie mountie 1192027877 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/uv/experimental/util-vserver-0.30.210-lockf.patch 1192027908 M * daniel_hozac i guess i never got any feedback on it since it's not in trunk.... 1192027950 M * zbyniu daniel_hozac: is that patch in mainstream util-vserver-0.30.212 ? 1192027964 M * daniel_hozac it's not in any version. 1192028012 M * zbyniu ok, let's try it :) 1192028017 M * daniel_hozac if it works, i'll add it to 0.30.215. 1192028196 J * hallyn ~xa@adsl-75-2-77-142.dsl.chcgil.sbcglobal.net 1192029165 J * JonB ~NoSuchUse@kg1-61.kollegiegaarden.dk 1192029953 J * pmenier ~pmenier@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr 1192030230 J * ntrs_ ~ntrs@79.125.232.200 1192030656 Q * sladen Remote host closed the connection 1192030673 Q * gebura Remote host closed the connection 1192030674 J * sladen paul@starsky.19inch.net 1192030689 M * amax how can i specify broadcast for interface for guest ? 1192030728 M * daniel_hozac the broadcast is IP & mask | ~mask. 1192030734 M * daniel_hozac as always 1192030754 M * amax i need specify broadcast for ip /32 1192030757 M * amax not 0.0.0.0 1192030771 M * amax just x.255.255.255 1192030773 M * daniel_hozac don't use /32 if you want a broadcast. 1192030782 M * amax but thats reasonable 1192030789 M * amax for dummy interface 1192030810 M * amax also.. 1192030873 M * amax found some strange thing while migration.. inside guest only 1 ip address.. strating one old program written on tcl.. it not works. but on real server all ok 1192030884 M * amax 5 sec.. stracing 1192030923 M * amax http://rafb.net/p/BRJuQ634.html 1192030924 J * transaci1 ~transacid@transacid.de 1192030934 M * amax cant understand whats wrong.. 1192030945 M * amax sshd listen ok on this addrs 1192030948 N * Bertl_zZ Bertl 1192030964 M * amax its assigned to dummy1 1192030996 M * Bertl that was somewhat refereshing :) 1192031014 M * daniel_hozac since nothing's failing, you'd have to ask the source or whoever wrote it... 1192031020 M * amax cant 1192031020 Q * transacid Remote host closed the connection 1192031025 M * amax binary chat 1192031027 M * amax on tcl 1192031036 M * amax havent sources many years 1192031040 M * daniel_hozac so, whoever wrote it then. 1192031055 M * amax its just working outside vserver 1192031069 M * amax but cant understand whats wrong in systrace part? 1192031075 M * daniel_hozac nothing's wrong. 1192031090 M * daniel_hozac which is why you need to consult someone who knows why it would do that. 1192031105 M * amax sry 1192031122 M * amax ^) my migration issues.. 1192031140 M * amax idk about .. maybe vserver security/capabilities ? 1192031157 M * daniel_hozac no, since nothing is failing. 1192031333 J * julius_ ~julius@p57B2742E.dip.t-dialin.net 1192031350 Q * ensc Ping timeout: 480 seconds 1192031501 M * Bertl daniel_hozac, amax: short overview please? 1192031511 M * daniel_hozac http://rafb.net/p/BRJuQ634.html 1192031564 M * amax well 1192031599 M * amax bind(3, {sa_family=AF_INET, sin_port=htons(8801), sin_addr=inet_addr("62.205.173.99")}, 16) = 0 1192031599 M * amax listen(3, 128) = 0 1192031599 M * amax time(NULL) = 1192030635 1192031599 M * amax write(1, "error address#3\n", 16error address#3 1192031602 M * amax oops 1192031629 M * amax why bind failed ? 1192031640 M * daniel_hozac it didn't. 1192031640 M * amax we have this address inside guest. 1192031671 M * amax yes, probably diff returncode?.. 1192031684 M * daniel_hozac huh? 1192031699 M * Bertl amax: you mean 'bind9' right? 1192031720 Q * Julius Ping timeout: 480 seconds 1192031768 M * amax function bind.. 1192031777 M * amax by return codes its success 1192031786 M * Bertl amax: hmm, obviously that didn't fail (according to your strace) 1192031800 M * amax but something wrong in over check logic looks like.. hmm 1192031810 M * amax ye 1192031816 M * amax its give zero 1192031827 M * Bertl the man page says: 1192031830 M * amax ok will debug more.. 1192031833 M * Bertl RETURN VALUE: On success, zero is returned. 1192031840 M * Bertl (man 2 bind) 1192031841 M * amax sure 1192031879 M * Bertl do you happen to check for errno unconditionally? 1192031889 M * Bertl because that can go terribly wrong :) 1192031924 M * amax not my prog, i have only compiled code ^( 1192032143 M * Bertl np, what program is it, if I may ask? 1192032275 M * amax chat 1192032278 M * amax webchat 1192032282 M * amax serious, stable 1192032288 M * amax tcl+tclpro 1192032294 M * amax obfusicated ^( 1192032328 M * daniel_hozac it sounds like something that should be supported by the vendor. 1192032348 M * amax vendor died 1192032362 M * amax 2003year 1192032382 M * amax hate commercial stuff. ( 1192032393 M * daniel_hozac i guess you're screwed then. 1192032403 M * amax sure idk what to do now ( 1192032416 M * amax thanks for help anyway 1192032468 Q * DavidS Quit: Leaving. 1192032593 M * daniel_hozac Bertl: http://people.linux-vserver.org/~dhozac/p/k/delta-dmap-feat07.diff 1192032708 M * daniel_hozac it seems to work, and has all the features i want... 1192032772 M * daniel_hozac there's still a lot of optimizations to do, and a lot of the code is flat out ugly. 1192032806 J * fatgoose_ ~samuel@76-10-156-251.dsl.teksavvy.com 1192033191 M * Bertl daniel_hozac: was it tested with module loading/unloading? 1192033203 M * daniel_hozac hmm? 1192033220 M * Bertl I just remeber that we had some 'potential issues' with that 1192033239 M * Bertl I don't know exactly where, but maybe I will remember ... 1192033240 Q * fatgoose Ping timeout: 480 seconds 1192033293 M * daniel_hozac well, my kernel has a lot of modules, and unloading loop worked fine. 1192033325 M * Bertl vs_device_perm(v,d,m,p) -> vs_device_perm(v, d, m, p) :) 1192033413 M * daniel_hozac heh, right. 1192033531 M * Bertl hmm, so how does the lookup semantics work 1192033544 M * Bertl first you look for the hash entry 1192033557 M * Bertl then you scan for defaults? 1192033601 M * Bertl and then the sequence is local_default, global, global_default, fallback? 1192033641 M * daniel_hozac right. 1192033657 M * Bertl why do we scan for the defaults at all? 1192033666 M * daniel_hozac because we failed to find the specific entry. 1192033673 M * Bertl wouldn't it make sense to put them into vx_info? 1192033674 M * daniel_hozac (i.e. for this context) 1192033723 M * daniel_hozac yeah, that was my original plan... 1192033743 M * Bertl okay, how much data are we talking about here? 1192033760 M * daniel_hozac for the default? 1192033766 M * Bertl yep 1192033803 M * daniel_hozac 8 + 2 * sizeof(void *) 1192033809 M * Bertl basically 2x dev_t + flags, no? 1192033831 M * matti Hi Bertl 1192033833 M * matti daniel_hozac: :) 1192033833 M * daniel_hozac hmm, why 2 x dev_t in that case? 1192033834 M * Bertl actually 1x dev_t + flags at most 1192033904 M * Bertl so that should be harmless to put into vx_info 1192033925 M * Bertl do we want to make it a compile time option? 1192033934 M * daniel_hozac hmm? 1192033947 M * daniel_hozac just curious, what would the dev_t be for? 1192033963 M * Bertl the target, no? 1192033979 M * daniel_hozac then we'd need two dev_t's unless i'm missing something. 1192033985 M * daniel_hozac i.e. S_IFCHR and S_IFBLK. 1192034002 M * Bertl right, now I know why I had two dev_t in my mind :) 1192034048 M * Bertl so thats 8 + sizeof(flags) 1192034071 M * Bertl dev_t should be 32 bit IIRC 1192034078 J * bonbons ~bonbons@ppp-110-213.adsl.restena.lu 1192034080 M * daniel_hozac yeah, that's what i'm remembering too. 1192034097 M * daniel_hozac the reason i went with the list of defaults was just to simplify the code somewhat. 1192034115 M * daniel_hozac i.e. there's a struct vs_mapping for every entry, default or not. 1192034115 M * Bertl i.c. how so? 1192034134 M * Bertl ah, okay, I think we can do that in a simple way in this case too 1192034138 M * daniel_hozac it's obviously minor, but the other way just looked ugly. 1192034156 M * Bertl just let's make a sub struct containing the dev_t and flags 1192034177 M * daniel_hozac sure, that works. 1192034178 M * Bertl then put two of them into vx_info, and one in vs_mapping 1192034202 M * Bertl just passing the pointer to that around should suffice then 1192034211 M * daniel_hozac right 1192034219 M * Bertl what's the fallback? 1192034235 M * daniel_hozac the compatible default? 1192034240 M * Bertl yep 1192034253 M * daniel_hozac it's just to allow current setups to keep working. 1192034255 M * Bertl XXX: is an interesting tag :) 1192034269 M * daniel_hozac vim hilights it :) 1192034274 M * Bertl lol 1192034307 M * daniel_hozac i didn't want to go break the world just by enabling the option. 1192034321 M * Bertl so that gives us the current behaviour, all alowed and such 1192034326 M * daniel_hozac right. 1192034336 M * daniel_hozac which can be revoked by vdevmap --xid 0 1192034345 M * Bertl why do we need to extra assign that? 1192034372 M * daniel_hozac hmm? i.e. why not add a default by default? 1192034380 M * Bertl I mean, why not have two global defaults or make the global default a fallback by default *G* 1192034409 M * Bertl to me that entire case looks unnecessary 1192034453 M * Bertl btw, we want additional parethesis here: (target && vdm->flags & DATTR_REMAP) 1192034455 M * daniel_hozac it was just the path of least resistence with the list implementation. 1192034496 M * Bertl okay, so having a 'global_default' which does a 1:1 mapping should work, yes? 1192034524 M * Bertl vdm->flags short of DATTR_REMAP 1192034535 M * Bertl but with DATTR_OPEN 1192034545 M * daniel_hozac sure. 1192034576 M * Bertl then we can eliminate the entire else path and the 'out:' 1192034589 M * daniel_hozac yep 1192034639 M * Bertl "--- mapping device" <- that needs to get standard look 1192034655 M * daniel_hozac standard look? 1192034668 M * Bertl well, the way our debug messages all look like 1192034718 J * hparker ~hparker@linux.homershut.net 1192034760 M * daniel_hozac so s/--- mapping device/vs_map_device/? 1192034766 M * Bertl other than that looks quite good, can you roll another one with the changes? 1192034771 M * daniel_hozac will do. 1192034801 M * Bertl yeah, something like that, but the debug messages are details, I can fix them up myself later 1192034862 M * Bertl btw, do we need the iminor/imajor anymore? 1192034918 M * Bertl hmm, that is an interesting hunk there 1192034931 M * Bertl ah, got it, because of the mappings 1192034937 M * Bertl nevermind ... 1192034947 M * daniel_hozac hehe 1192034971 M * Bertl stat is also covered? 1192035084 M * daniel_hozac apparently not. will fix that up too. 1192035102 M * Bertl excellent! best test with something like tar or rsync too 1192035123 M * Bertl (they sometimes do strange things with devices :) 1192035139 M * daniel_hozac hehe, okay. 1192035449 Q * pmenier Quit: pmenier 1192035579 Q * ema Quit: leaving 1192035975 M * daniel_hozac Bertl: hmm, the else block in __lookup_mapping has to stay, no? i mean, how else do we specify what to do in case nothing's set? 1192036040 M * daniel_hozac or should the host-default be ununsettable, just reverting to the default of DATTR_OPEN when unset? 1192036050 M * Bertl I just wouldn't allow the host default to get 'unset' 1192036059 M * daniel_hozac so it's more of a reset, okay. 1192036093 M * Bertl but maybe the dual default case is simpler 1192036129 M * Bertl i.e. if (global_default) ... else .. global_fallback .. 1192036184 M * Bertl something completely different: do we have inodes which dx_permission does apply to, without superblock? 1192036240 M * daniel_hozac is it possible to have an inode without a superblock? i assume you're referring to the proctag patch, i just wanted to err on the side of caution. 1192036278 J * tuxmania ~bonbons@2001:960:7ab:0:20b:5dff:fec7:6b33 1192036329 M * Bertl okay, so we keep that in mind, and if we see kernel traces there, we know where to look :) 1192036334 M * Bertl wb tuxmania! 1192036356 M * daniel_hozac hehe, right. 1192036500 M * Yvo *** Yvo is very happy *** my postfix works 1192036511 M * Bertl Yvo: congrats! 1192036561 M * matti LOL 1192036595 Q * bonbons Ping timeout: 480 seconds 1192036651 M * Yvo thx ;-) 1192036656 M * daniel_hozac Bertl: http://people.linux-vserver.org/~dhozac/p/k/delta-dmap-feat08.diff still building, will test soon. 1192036706 M * Bertl daniel_hozac: why do we need linux/sched.h in char_dev.c? 1192036724 M * Yvo it was one terrible line in main.cf which I had to uncomment: #receive_override_options = no_address_mappings :-/ 1192036783 M * Bertl daniel_hozac: and why does the patch contain the proctag stuff? *G* 1192036788 M * daniel_hozac Bertl: good point. 1192036798 M * daniel_hozac Bertl: d'oh, haha. i've got that in my tree too. 1192036817 M * daniel_hozac fixed in place. 1192036844 M * ruskie hmm there a usable vserver patch for 2.6.23 ? 1192036853 M * Bertl ruskie: yes and no 1192036865 M * ruskie any eta on when one will be available? 1192036871 M * Bertl ruskie: there is a pre version which works under certain conditions with limited features 1192036883 M * ruskie so a week or two? or a month? 1192036897 M * Bertl I'd say a few days at most 1192036902 M * ruskie ok 1192036908 M * daniel_hozac that's not going to be stable though. 1192036910 M * Bertl now that it is out, we will update/test patches 1192036918 M * daniel_hozac stabilizing on a new kernel takes time. 1192036924 M * ruskie I can wait for a while 1192036932 M * ruskie I don't update on every release 1192036939 M * Bertl yeah, devel patches .. i.e. 2.3.x 1192036944 M * ruskie but I kinda have the feeling it's time to update from 2.6.19.2 version 1192036961 M * daniel_hozac and is there a reason you want 2.6.23? 1192036964 M * Bertl 2.6.22.9 seems to be a good choice if you want to update 1192036973 M * ruskie had probs with .22 1192036975 M * eyck yeah, but we want 2.6.23 1192036983 M * ruskie not sure about .23 anyway 1192036986 M * ruskie will have to first test it 1192036994 M * ruskie and if it won't work as I want I'll stick to .19.2 1192036996 M * eyck testing is for wussies 1192037002 M * Bertl eyck: go away from the keyboard and let the 'real' eyck chat again! 1192037014 M * ruskie reason for switching to .23 is for the new cpu scheduler 1192037031 M * ruskie and generaly any interesting updates from .19.2 onward 1192037039 M * ruskie other than that I don't really update often... 1192037048 M * daniel_hozac that's one of the reasons vserver is going to take time... :) 1192037071 M * Bertl eyck: just kidding, how's going? 1192037093 M * ruskie hmm isn't there xen now in .23 as well? 1192037117 M * Bertl the changelog has all the gory details :) 1192037129 M * ruskie I just recall something while extracting it 1192037140 M * ruskie I guess I can play with that for a bit... been meaning to try it anyway :) 1192037295 M * eyck Bertl: I'm busy with physical work for a change, it's kind of refreshing and fun 1192037318 M * eyck unless you drop a server or two on stairs and they won't boot anymore, 1192037335 M * eyck hmm, well, if you think about it, it's still fun, in a strange perverted way 1192037341 M * Bertl hehe 1192037344 M * ruskie :) 1192037358 M * ruskie I prefer pure physical work compared to doing computer stuff 1192037371 M * ruskie since then you tire after 8 hours... grab some sleep and still have most of the day 1192037375 M * Bertl daniel_hozac: http://vserver.13thfloor.at/Experimental/delta-magic-fix01.diff and http://vserver.13thfloor.at/Experimental/delta-tag-fix02.diff 1192037394 M * ruskie anything else with it usually drains me permanently for the day after 6 or so hours 1192037402 M * Bertl daniel_hozac: that should leave us with the proc permission itself, which I still need to check 1192037456 M * daniel_hozac Bertl: what about do_lookup? 1192037539 M * Bertl yep, is missing the devpts case 1192037559 M * Bertl will make the dx_check an else there 1192037631 M * daniel_hozac i don't think we want devpts there though. 1192037677 M * Bertl hmm? won't that cause problems with looking up wrong devpts entries? 1192037713 M * daniel_hozac well, there's nothing else protecting devpts in that path. 1192037718 N * BobR_oO BobR 1192037723 M * daniel_hozac i.e. suddenly they'd all be visible. 1192037731 M * daniel_hozac we'd need to add a devpts_revalidate first. 1192037888 Q * Piet Remote host closed the connection 1192037925 M * Bertl hmm, hmm ... how did that work till now? 1192037960 M * daniel_hozac the xid tagging. 1192038005 M * Bertl well, we had the dx_check() with xid for devpts, right? 1192038023 M * daniel_hozac you mean devpts_permission? 1192038036 M * Bertl no, in the lookup 1192038056 M * daniel_hozac ah, right. 1192038205 M * Bertl so we should be fine with doing the xid check there now too, no? 1192038277 M * daniel_hozac right. 1192038974 J * Piet ~piet@tor.noreply.org 1192039060 M * Bertl okay, so with http://vserver.13thfloor.at/Experimental/delta-tag-fix03.diff, we should have the same state as before (except for xid related procfs security checks) 1192039143 M * daniel_hozac hmm, now wait a minute... unless i'm missing something, we would have allowed access to the host's pts's, no? 1192039291 M * Bertl hmm, have to test that, but possible ... 1192039318 M * daniel_hozac right, lookup returns EACCES, meaning it's devpts_permission saving the day. 1192039346 M * daniel_hozac (or rather, lookup works fine, it's access which is denied) 1192039354 M * Bertl yeah, right 1192039369 M * Bertl I think we want to adjust that to hide the entries too 1192039402 M * daniel_hozac yeah. 1192039411 M * Bertl should be simple now :) 1192039414 M * daniel_hozac indeed :) 1192039436 P * Yvo 1192039442 M * Bertl so, that leaves us with the question: do we need procfs specific xid blockers? 1192039460 M * Bertl because if, then we should put that in a proc_permission 1192039727 M * daniel_hozac i agree, do_lookup is the only place we need the filesystem specific code. 1192039939 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-dmap-feat09.diff remaps stat too, but only after the device has been accessed. 1192039973 M * Bertl hmm, so what do we get there? 1192039984 M * daniel_hozac hmm? 1192039997 M * Bertl the 'but only after the device has been accessed.' worries me :) 1192040011 M * daniel_hozac yeah, i'm looking at that now. 1192040019 M * daniel_hozac we don't set i_mdev early enough. 1192040023 M * Bertl so if I do a stat(/dev/xy) I will get two different results? 1192040038 M * daniel_hozac no, you have to actually open the device. 1192040043 M * Bertl also the question remains, what values do we want to get from stat? 1192040047 M * daniel_hozac but stat, open, stat. 1192040058 M * daniel_hozac would show different values (assuming it hasn't been opened before). 1192040096 M * daniel_hozac i think stat should show the mapped values. 1192040107 M * Bertl not sure about that, actually 1192040128 M * daniel_hozac oh? 1192040134 M * Bertl let's look at it from two perspectives 1192040151 M * Bertl 1) host perspective, where we copy a dev tree 1192040167 M * Bertl 2) guest persepctive, where we create/copy/modify devs 1192040189 M * Bertl from the host PoV, we always want to copy the actual device node 1192040197 M * Bertl regardless of the mapping, right? 1192040202 M * daniel_hozac definitely. 1192040218 M * Bertl okay, for the guest side, a /dev/sda mapped to /dev/hdb (for example) 1192040220 M * daniel_hozac and if the mapping wouldn't be so permanent, that wouldn't be a problem (as the host isn't mapped). 1192040244 M * Bertl should still be seen as /dev/sda, that's the point of the mapping after all, no? 1192040255 M * daniel_hozac right. 1192040274 M * Bertl so what we want to get reported from stat and friends, is /dev/sda not /dev/hdb 1192040294 M * Bertl (speaking in major/minors here :) 1192040317 M * daniel_hozac yes, of course. 1192040337 M * Bertl okay, so how does mdev fit in there 1192040421 M * daniel_hozac i guess the simplest solution is stat->rdev = (vx_check(0, VS_ADMIN) ? inode->i_rdev : inode->i_mdev). 1192040500 M * Bertl please elaborate why we handle host and guest differently? 1192040508 M * daniel_hozac but that's just for stat. i think the persistence of mdev might be a problem, though i can't come up with any scenario right now. 1192040583 M * daniel_hozac to get the host-sees-the-truth, guest-sees-what-we-want behaviour we want? 1192040611 M * Bertl well, a /dev/sda is still a /dev/sda, even if remapped, no? 1192040635 M * daniel_hozac hmm? 1192040644 M * Bertl and somehow, if the host accesses a /dev/sda it should behave like a /dev/sda, no? 1192040677 M * daniel_hozac ah, you mean that mdev shouldn't be a problem? 1192040755 M * Bertl I'm still not sure how the entire mapping will/should behave in a case we are sharing devices 1192040774 M * Bertl e.g. let's assume we have udev on tmpfs 1192040783 M * daniel_hozac what will happen right now is that the guest who first opens the device decides what happens with it 1192040785 M * Bertl mapped into guest via --bind 1192040802 M * Bertl will that change the device for the host too? 1192040808 M * daniel_hozac yeah. 1192040825 M * Bertl hmm, even with namespaces? 1192040855 M * daniel_hozac i'd think so, as we're storing it in the inode. 1192040933 M * Bertl we might get a problem with that, especially for the defaults 1192040965 M * daniel_hozac yeah. 1192041073 M * Bertl granted, we can put that under 'then don't do it :)' 1192041275 M * daniel_hozac yeah, i guess so. 1192041331 M * daniel_hozac the stat thing is a problem though. 1192041382 M * daniel_hozac i almost want to just translate rdev every time it's used, but that would be some pretty serious overhead, i guess. 1192041409 M * Bertl definitely 1192041492 M * Bertl question is: if we 'define' that device nodes have to be unique when mapped 1192041518 M * Bertl does that give us a consistant view from guest/host side? 1192041575 M * Bertl we could, for example, tag them (xid wise) 1192041577 M * daniel_hozac consistent how? 1192041611 M * Bertl in such way that host and guest rsync to a different system will work 1192041668 M * daniel_hozac well, the host accessing the guest's device nodes will be mapped. 1192041725 M * Bertl which means that vserver - build -m rsync will fail? 1192041745 M * daniel_hozac yeah. 1192041751 M * daniel_hozac or well, not fail. 1192041754 M * daniel_hozac just be incorrect. 1192041776 M * Bertl not terribly good, eh? 1192041789 M * daniel_hozac indeed. 1192041813 M * daniel_hozac thus the ugly stat hack i suggested earlier ;) 1192041823 M * Bertl ri8ght 1192041827 M * Bertl *right 1192041881 M * daniel_hozac but for that to even be relevant, we need to initialize mdev earlier somehow. 1192041905 M * Bertl e.g., when it is not set? 1192041910 M * daniel_hozac would init_special_inode be a suitable place? 1192041956 M * daniel_hozac when it's being remapped, mdev is only set when you open it. 1192041998 M * daniel_hozac i.e. stat, open, stat will return two different results. 1192042020 M * Bertl okay, let's take a step back 1192042041 M * Bertl and make a real world example 1192042080 M * Bertl let's assume we have devices /dev/null /dev/tty0 and /dev/hda 1192042088 M * daniel_hozac okay. 1192042152 M * Bertl c:1:3, c:4:0 and b:3:0 1192042171 Q * hparker Remote host closed the connection 1192042180 M * Bertl now we have a guest 1192042200 M * Bertl which uses /dev/null as it is, maps /dev/tty0 to /dev/tty10 1192042217 M * Bertl and uses vroot0 instead of /dev/hda 1192042282 M * Bertl so we have: 1192042315 M * Bertl c:1:3 -> c:1:3, c:4:0 -> c:4:10, and b:3:0 -> b:4:0 1192042329 J * hparker ~hparker@linux.homershut.net 1192042336 M * daniel_hozac right 1192042366 M * Bertl let's further assume the inodes are guest specific and we do not do strange things on the host with them 1192042395 M * Bertl now, when the guest does a backup (tar/rsync) from inside 1192042418 M * Bertl we want it to see the c:1:3, c:4:0 and b:3:0 values, not the mapped ones 1192042434 M * daniel_hozac yes 1192042450 M * Bertl the same, IMHO, goes for a host side rsync/clone/tar 1192042488 M * Bertl i.e. if you copy the guest, you will 'copy' the same mappings too, no harm done 1192042516 M * Bertl if you want different mappings, that's fine too, the unmapped device will stay the same 1192042579 M * Bertl sounds fine so far? 1192042584 M * daniel_hozac yeah. 1192042630 M * Bertl so, what we want to present to the user (guest or host) is the consistant view of c:1:3, c:4:0 and b:3:0, regardless if they are currently remapped or dormant 1192042699 M * Bertl now what do we want to do in cases where the mapping changes? 1192042731 M * daniel_hozac i.e. the mapping for /dev/tty0 is changed to /dev/tty9 instead? 1192042846 Q * Piet Remote host closed the connection 1192042865 J * nysis ~nysis@dslb-088-073-149-032.pools.arcor-ip.net 1192042889 J * Piet ~piet@tor.noreply.org 1192042897 M * daniel_hozac it seems to be clear that we always want to show mdev. 1192042977 M * Bertl okay, so what's the problem with open now? 1192043006 M * Bertl btw, wb nysis! 1192043008 M * daniel_hozac well, it's not a problem with open, it's more a problem of the stat data being incorrect until after you've opened it. 1192043022 M * daniel_hozac so, let's say you haven't enabled quotas yet. 1192043034 M * Bertl daniel_hozac: how so? it shouldn't ever change, no? 1192043036 M * daniel_hozac ls -l /dev would show b:4:0 for hda 1192043051 M * daniel_hozac i_mdev isn't set until the device is opened. 1192043055 M * Bertl why? it should show b:3:0 instead 1192043070 M * Bertl it should _always_ show b:3:0 1192043073 M * daniel_hozac yes, it _should_ :) 1192043100 M * daniel_hozac so we agree to move the vs_map_device calls to init_special_inode (or whereever the most appropriate place is)? 1192043130 M * Bertl I'm probably missing something here ... 1192043143 M * daniel_hozac fs/char_dev.c:chrdev_open 1192043148 M * daniel_hozac (e.g.) 1192043152 M * Bertl the values are stored in the inode, we want to show them always, unconditionally 1192043158 M * daniel_hozac this is where we set inode->i_mdev. 1192043175 M * daniel_hozac up until that point, inode->i_mdev == inode->i_rdev, regardless of mapping. 1192043185 M * Bertl okay 1192043272 M * Bertl what I'm trying to say is that probably the iminor/major changes are kind of wrong 1192043279 M * daniel_hozac how so? 1192043296 M * daniel_hozac are they used for kernel internal things? 1192043353 M * daniel_hozac or hmm, i've been confusing them all along, haven't i... 1192043377 M * Bertl i_rdev is the one read from the inode 1192043392 M * daniel_hozac yes, you're absolutely right. i'm so sorry... 1192043401 M * daniel_hozac forget everything i said :) 1192043409 M * Bertl np, almost got me convinced :) 1192043443 M * Bertl so we want to provide i_rdev info in all stat cases, right? 1192043447 M * daniel_hozac indeed. 1192043465 M * Bertl and that should not depend on anything, be it host/guest or openedor not 1192043481 M * daniel_hozac exactly. 1192043496 M * daniel_hozac so http://people.linux-vserver.org/~dhozac/p/k/delta-dmap-feat08.diff does the right thing, i think. 1192043525 M * Bertl yes, that was my impression too 1192043545 M * Bertl what we haven't considered yet is changes in mappings 1192043569 M * Bertl (and how to deal with them, as I think we might be leaking memory there?) 1192043586 M * daniel_hozac hmm? 1192043600 M * daniel_hozac a change would involve an unset followed by a set. 1192043607 M * Bertl simple case first, we open a mapped device twice 1192043628 M * Bertl will that properly take care of everything? 1192043647 M * Bertl should do so, I think, as we do not change anything, right? 1192043655 M * daniel_hozac sure, we only map things when acquiring the bdev/cdev. 1192043670 M * Bertl we do an additional, maybe uneccesary lookup for the mapped device 1192043705 M * Bertl now let's consider the case where we change the mapping between two open/close sequences 1192043726 M * daniel_hozac yeah, this is not handled at all. 1192043729 M * Bertl we should be fine there too, because of the missing optimization 1192043777 M * Bertl the hary cases are, where the guest has a device open, and we change the mapping, yes? 1192043802 M * Bertl but I think we can put that on 'don't do that' again 1192043802 M * daniel_hozac changing the mapping won't affect already opened inodes. 1192043821 M * daniel_hozac i.e. even if it's closed when it's changed. 1192043822 M * Bertl not even when the same inode is opened again? 1192043843 M * daniel_hozac the cdev/bdev is only acquired once per inode life-time. 1192043873 M * Bertl but the chrdev_open will be called twice, no? 1192043908 M * Bertl and thus, it will change the mdev for the already open inode too, or am I missing something? 1192043956 M * daniel_hozac we'd have to move it outside of the if (!p) branch. 1192043971 M * daniel_hozac but you're right, it's an easy problem to solve. 1192044026 M * daniel_hozac similar for the block device case, just a matter of moving the check up a bit. 1192044057 M * Bertl okay, sounds good 1192044228 M * Bertl we might want to restructure the wrappers a little bit, so that we can get rid of i_mdev when the kernel option is disabled 1192044237 M * Bertl but that can wait till later 1192044502 Q * JonB Quit: This computer has gone to sleep 1192044537 M * daniel_hozac okay, http://people.linux-vserver.org/~dhozac/p/k/delta-dmap-feat10.diff 1192044768 M * Bertl the vx_dmap_target should be #ifdef-ed 1192044776 M * Bertl (in the vx_info struct) 1192044787 M * daniel_hozac ah, yeah! 1192044811 M * Bertl or probably better to move it into a struct _vx_device ? 1192044822 Q * meandtheshell Quit: Leaving. 1192044881 M * daniel_hozac okay 1192045294 M * daniel_hozac we could drop VXC_SECURE_MKNOD too, right? 1192045351 M * daniel_hozac i mean, that's something i added to not kill compatibility for people using CAP_MKNOD when i had it in the stable kernel, and now that defaults are implemented, there's no reason for it (when it's devel). 1192045604 M * Bertl yep, should be fine 1192045614 M * Bertl okay, off for dinner .. back shortly 1192045620 N * Bertl Bertl_oO 1192045656 M * daniel_hozac okay, http://people.linux-vserver.org/~dhozac/p/k/delta-dmap-feat11.diff 1192045675 J * Yvo ~yvonne@91.64.217.106 1192046120 M * Yvo I would like to update the main-system on which my virtual servers are running from debain etch to lenny or testing, so far my sources.lst looks like this: http://paste.linux-vserver.org/6947 - could somebody perhaps give me a sources.lst which is already optimized for vserver and which contains every source I need to update the system step by step? Thanks :-) 1192046202 M * daniel_hozac :%s/etch/lenny/g and remove the updates line. 1192046568 J * PhatJ_ ~PhatJ@24-231-253-65.dhcp.aldl.mi.charter.com 1192046569 Q * PhatJ Read error: Connection reset by peer 1192046617 M * Yvo http://paste.linux-vserver.org/6948 just like that? 1192046644 M * daniel_hozac you can remove the top line now, i think. 1192046663 M * Yvo ok 1192046665 M * Yvo thx! 1192046694 J * snooze ~o@1-1-4-40a.gkp.gbg.bostream.se 1192046763 M * snooze heya, any news on supporting 2.6.23? 1192046779 M * snooze (yeah i know it was recently released ;) 1192046801 M * daniel_hozac there are highly experimental patches which are lacking features and such. 1192046846 J * ensc ~irc-ensc@p54B4EE5D.dip.t-dialin.net 1192046867 M * snooze when do you think a stable patch will be around? 1192046885 M * snooze even more interresting, one with grsec included 1192046976 M * daniel_hozac stable? that's gonna take a while. 1192046998 M * daniel_hozac as for grsec, you'd have to ask them. 1192047040 M * snooze alright, well i guess grsec will take even longer 1192047061 M * snooze i better stick with 22.9 1192047149 M * daniel_hozac ensc: ping? 1192047398 Q * Piet Remote host closed the connection 1192047478 J * Piet ~piet@tor.noreply.org 1192047758 J * larsivi ~larsivi@101.84-48-201.nextgentel.com 1192047786 Q * Piet Remote host closed the connection 1192047788 P * Yvo 1192047829 J * Piet hiddenserv@tor.noreply.org 1192047998 N * Bertl_oO Bertl 1192048004 M * Bertl back now .. 1192048358 M * daniel_hozac Bertl: have you already fixed the 127.0.0.0/8 bug? 1192048388 M * Bertl nope, only the lback remap 1192048449 M * daniel_hozac wouldn't it make sense to rewrite all of those to lback? 1192048513 M * Bertl hmm, would be an option I guess 1192048537 M * Bertl leaves the problem for non-lback guests 1192048579 M * daniel_hozac return -EPERM? 1192048594 M * daniel_hozac or maybe -ENETUNREACH. 1192048599 M * Bertl yes, I think that is appropriate 1192048605 M * Bertl the eperm :) 1192048624 M * Bertl unreach always looks like routing issue 1192048629 M * Bertl EPERM makes it obvious 1192048972 Q * tuxmania Quit: Leaving 1192049262 M * daniel_hozac something like http://people.linux-vserver.org/~dhozac/p/k/delta-lback-fix05.diff? 1192049404 M * Bertl yeah, note that: include/linux/in.h already has IN_LOOPBACK(a) 1192049424 M * daniel_hozac hehe, good. 1192049476 M * Bertl not sure we do not need any mapping here 1192049511 M * Bertl but if we do, then the IS_LOOPBACK() is borked anyway :) 1192049594 M * daniel_hozac updated in place to use IN_LOOPBACK. 1192049622 M * daniel_hozac why would we need to do any mapping? 1192049642 M * Bertl I meant, as you did with the htonl() 1192049651 M * Bertl not lback (re)mapping 1192049677 Q * MooingLemur Ping timeout: 480 seconds 1192049688 J * MooingLemur ~troy@shells195.pinchaser.com 1192049712 M * Bertl hmm, so what are the semantics we expect with that 1192049748 M * Bertl if we have LBACK_REMAP, then connecting to any 127.x will be mapped to lback 1192049780 M * Bertl except for IPs explicitely supplied for the guest 1192049810 M * Bertl without the LBACK_REMAP, we will bail out with EPERM 1192049825 M * daniel_hozac yeah. 1192049834 M * Bertl for any ip in 127.x unconditionally? 1192049851 M * daniel_hozac you think we should limit it? 1192049866 M * Bertl I'm not sure we need that check at all 1192049898 M * daniel_hozac so guests without LBACK_REMAP should be able to access all the other guest's private addresses? 1192049934 M * Bertl not necessarily, but at least those assigned to the guest 1192049975 M * daniel_hozac hmm, yeah, true. 1192049982 M * Bertl also, we are talking connect and src ip here, not necessarily bind/deliver 1192050026 M * Bertl I think the 'still no source ip?' case should be sufficient for the any case 1192050026 M * daniel_hozac bind is already handled, so that shouldn't be a problem. 1192050050 M * Bertl but we want the check for unhandled specific ips 1192050126 M * daniel_hozac and for SINGLE_IP, no? 1192050147 M * Bertl I think we might want to 'ignore' certain IPs on socket lookup 1192050187 M * Bertl basically make the 'other' IPs unavailable there 1192050262 M * daniel_hozac i.e. LOOPBACK(addr) && addr != lback? 1192050299 M * Bertl something like that, not 100% sure though 1192050334 M * Bertl we need to handle both cases, udp and tcp, probably even icmp 1192050636 J * Aiken ~james@ppp121-45-206-11.lns1.bne1.internode.on.net 1192051771 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-lback-fix06.diff seems to work as expected. 1192051915 M * Bertl yeah, that looks good 1192051932 M * daniel_hozac (LOOPBACK does the htonl too) 1192051944 M * Bertl excellent 1192051962 Q * julius_ Ping timeout: 480 seconds 1192051964 M * Bertl makes it even more readable :) 1192052088 Q * nysis Quit: Αποχώρησε 1192052095 P * dna Verlassend 1192053529 Q * larsivi Quit: Konversation terminated! 1192053945 A * matti pokes Hollow 1192053958 M * Hollow pong :) 1192053969 M * matti Wooho! 1192053973 M * matti My hero! 1192054011 M * Hollow so ..? 1192054020 M * Hollow why do you need me on irc? ;) 1192054237 Q * ntrs_ Ping timeout: 480 seconds 1192054546 J * King` ~drauge@clt-84-32-210-22.vdnet.lt 1192054631 Q * King` 1192056077 J * bastiaan3 ~bastiaan@sh.vhl.welmers.net 1192056077 Q * bastiaan_ Read error: Connection reset by peer 1192059831 Q * dowdle Remote host closed the connection