1226448631 Q * rgl Ping timeout: 480 seconds 1226448961 P * ghislainocfs2 1226449036 N * Guest2808 Genghis 1226449069 N * Genghis Guest2813 1226449579 J * pisco_ ~pisco@86.59.118.153 1226449591 Q * pisco Ping timeout: 480 seconds 1226450174 Q * ard Ping timeout: 480 seconds 1226452290 J * rgl ~rgl@lx2-84-90-232-86.netvisao.pt 1226452703 Q * Piet Quit: Piet 1226452726 N * Guest2813 Genghis 1226452760 N * Genghis Guest2819 1226454386 Q * rgl Ping timeout: 480 seconds 1226456416 N * Guest2819 Genghis 1226456450 N * Genghis Guest2829 1226457835 N * quinq qzqy 1226460106 N * Guest2829 Genghis 1226460140 N * Genghis Guest2838 1226462956 Q * hparker Quit: Quit 1226463412 J * hparker ~hparker@2001:470:1f0f:32c:212:f0ff:fe0f:6f86 1226463796 N * Guest2838 Genghis 1226463830 N * Genghis Guest2845 1226464755 J * Supaplex ~supaplex@166.70.62.200 1226466689 Q * Supaplex Ping timeout: 480 seconds 1226467325 J * dowdle_ ~dowdle@71-36-196-94.blng.qwest.net 1226467486 N * Guest2845 Genghis 1226467509 Q * dowdle Ping timeout: 480 seconds 1226467520 N * Genghis Guest2852 1226467771 Q * larsivi Ping timeout: 480 seconds 1226467795 J * larsivi ~larsivi@9.80-202-30.nextgentel.com 1226468081 J * larsivi_ ~larsivi@9.80-202-30.nextgentel.com 1226468291 Q * larsivi Ping timeout: 480 seconds 1226468335 J * larsivi__ ~larsivi@9.80-202-30.nextgentel.com 1226468502 J * Supaplex ~supaplex@166.70.62.193 1226468576 Q * larsivi_ Ping timeout: 480 seconds 1226468635 J * larsivi ~larsivi@9.80-202-30.nextgentel.com 1226468831 Q * larsivi__ Ping timeout: 480 seconds 1226468980 J * larsivi_ ~larsivi@9.80-202-30.nextgentel.com 1226469216 Q * larsivi Ping timeout: 480 seconds 1226469231 Q * dowdle_ Remote host closed the connection 1226469234 J * larsivi__ ~larsivi@9.80-202-30.nextgentel.com 1226469471 Q * larsivi_ Ping timeout: 480 seconds 1226470335 Q * pmenier Quit: Konversation terminated! 1226471176 N * Guest2852 Genghis 1226471210 N * Genghis Guest2856 1226472626 J * ntrs_ ~ntrs@77.29.11.78 1226473303 J * mtg ~mtg@vollkornmail.dbk-nb.de 1226474074 J * ghislainocfs2 ~Ghislain@adsl2.aqueos.com 1226474866 N * Guest2856 Genghis 1226474900 N * Genghis Guest2859 1226475601 Q * larsivi__ Ping timeout: 480 seconds 1226476711 J * dna ~dna@80-194-dsl.kielnet.net 1226477262 J * pmenier ~pme@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr 1226477614 J * rgl ~rgl@lx2-84-90-232-86.netvisao.pt 1226478556 N * Guest2859 Genghis 1226478590 N * Genghis Guest2865 1226479807 J * kir ~kir@swsoft-msk-nat.sw.ru 1226480708 J * ard ~ard@shell2.kwaak.net 1226481848 Q * ntrs_ Ping timeout: 480 seconds 1226482246 N * Guest2865 Genghis 1226482280 N * Genghis Guest2869 1226482511 Q * FireEgl Read error: Connection reset by peer 1226484239 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net 1226484281 Q * derjohn Ping timeout: 480 seconds 1226484618 Q * ghislainocfs2 Read error: Connection reset by peer 1226484624 J * ghislainocfs2 ~Ghislain@adsl2.aqueos.com 1226484800 J * derjohn ~derjohn@80.69.41.3 1226484899 Q * nou Ping timeout: 480 seconds 1226485058 J * nou Chaton@2001:6f8:328:bbc:6666:6667:: 1226485369 Q * doener_ Quit: leaving 1226485936 N * Guest2869 Genghis 1226485970 N * Genghis Guest2876 1226486603 Q * hparker Quit: Read error: 104 (Peer reset by connection) 1226487105 N * morrigan_oO morrigan 1226487653 Q * pmjdebru1jn Remote host closed the connection 1226487906 J * davidkarban ~david@193.85.217.71 1226488049 N * Bertl_zZ Bertl 1226488055 M * Bertl morning folks! 1226488097 M * Bertl Guest2876: fix your client, I'll have to ban you again 1226489001 M * nox hi Bertl 1226489111 M * Bertl hey nox! how's going? 1226489313 J * pmjdebruijn pascal@jester.pcode.nl 1226489576 N * Guest2876 Genghis 1226489610 N * Genghis Guest2882 1226490590 M * nox Bertl: everything is fine just a bit busy 1226491859 J * arekm arekm@carme.pld-linux.org 1226491931 M * arekm hello, I'm using 2.6.27.5 with 2.6.27.3-vs2.3.0.35.7 patch. Looks like IPv6 addresses are leaking from a guest 1226491999 M * arekm outgoing connections from guest reach the other end with IP not "assigned" to guest 1226492031 M * Bertl leaking means? 1226492150 M * arekm means guest is able to use IP addresses not asigned to it 1226492291 M * arekm "ip" over netlink sees only assigned IPv6, so something is like half filtered 1226492297 M * Guest2882 Bertl, sorry, I have no clue why this network cant remember my auth... 1226492325 N * Guest2882 Genghis 1226492379 M * Genghis I'm on 6 networks, and this is the only one i have this issue 1226492391 M * Genghis been looking for the cause some time ago, but so far no luck 1226492488 M * arekm connection to remote end is established, getsockname() returns non-guest ipv6 address but bind() fails with cannot assign requested address. On the other hand mtr --address non-guest-ipv6 some-remote-ipv6 is able to use non-guest-ipv6 (verified by tcpdump) 1226492626 M * arekm With ipv4 the same tests work correctly 1226492747 M * Bertl Genghis: it looks like your client is changing the nick every hour 1226492777 M * Bertl Genghis: you are not losing the connection or anything, your client (or proxy) just changes the nick over and over again 1226492787 M * Bertl (take a look at the irc logs) 1226492857 M * Bertl arekm: and the guest ip (ipv6) can reach the destination? 1226492875 M * Genghis yeah, that is because i'm "not authed" the network says 1226492878 M * Genghis but i am ;) 1226492902 M * Genghis so basicly, i connect, i auth, and some hours or days later 1226492912 M * Bertl well, no idea _what_ auth you are talking about, but NickServ registration works fine 1226492913 M * Genghis all of the sudden the network changes my nick to guest 1226492931 M * Genghis well, thats what i mean, nickserv auth 1226492945 M * Bertl as you can see (with my nick) that works fine 1226492958 M * Genghis and i dont have this issue on other networks, cause there, once authed, i'm good to go 1226492959 M * arekm Bertl: it reaches remote end without a problem (connection is established) 1226492989 M * Bertl arekm: I'm talking about the ipv6 address _assigned_ to the guest, not the 'wrong' one used 1226493038 M * Genghis well, since i have no cue at all on how to fix this, i better leave this chan :( I dont want to cause trouble 1226493048 M * Genghis keep up the good work guys, and have fun 1226493054 M * arekm Bertl: ah, with mtr - yes (mtr --address guest-ipv6address remote) 1226493059 P * Genghis 1226493065 N * qzqy quinq 1226493128 M * arekm Bertl: with application (socket->bind_to_guest_ipv6->then connection) also works 1226493217 M * Bertl so for whatever reason, you get a wrong default source address, right? 1226493266 M * arekm Bertl: yes, that's one problem. The second one is that I can explictly use other guests ipv6 addresses while I shouldn't be able to do that. 1226493340 M * Bertl hmm, use as in .. you can bind ipv6 addresses of other guests? 1226493467 M * Bertl could you get me the contents of /proc/virtnet//* for your guest? 1226493533 M * arekm Bertl: hm, lftp cannot bind but mtr can bind to other guests ipv6 address 1226493564 M * Bertl okay, in that case, please get me an strace -fF of mtr binding to the wrong ip too 1226493581 M * arekm Bertl: http://pld.pastebin.com/f43ea5408 1226493611 M * arekm Bertl: and strace http://pld.pastebin.com/f5f91aa9f 1226493713 M * arekm Bertl: 2001:6a0:200:60::2 is endpoint of the tunel (this one doesn't belong to any guest, only host) 1226493718 M * arekm my endpoint 1226493739 M * arekm 2001:6a0:13f:5::1 is IPv6 address of other guest 1226493752 M * arekm 2001:6a0:13f:1::1 is IPv6 of my test guest 1226493985 M * Bertl so line 214 in the strace should not succeed, right? 1226494013 M * arekm yes 1226494033 M * Bertl interesting is the port address 1226494073 M * arekm 0 means "port assigned by the OS" 1226494096 M * arekm also note line 208 - that ipv6 address shouldn't be there 1226494426 M * Bertl and the address is assigned on the host? 1226494555 M * Bertl I can prepare a debug patch, if you can build the kernel with that and enable Linux-VServer debugging? 1226494611 M * arekm 208 line - yes on host 1226494651 M * arekm hm, I would have to setup other test machine for that. I can do that but not immediately 1226494741 M * Bertl okay, no problem ... will take some time to prepare the debug patch anyways 1226494971 M * arekm I also see that modular ipv6 effort went to /dev/null 1226495371 M * Bertl well, there is no real point in making ipv6 modular 1226495431 M * arekm there is but not important to you (we had this discussion before ;-). There was even a patch for modularising ipv6 1226495444 M * Bertl the only good reason for having modular ipv6 is for distros to satisfy completely different needs, and I'd say, if a distribution want's to do that, so be it ... 1226495494 M * Bertl I'm even willing to do that if a distributor pays for the development :) 1226496013 M * arekm hehe, pld exists for 10 years and we don't even have formal body (in terms of law) so ... it will take years for us to sponsor anything hehe 1226496062 M * Bertl well, I'm fine with development on your side ... as you said, the patches are out there, probably need a little love .. that's all 1226496389 M * arekm Bertl: btw. how much it would cost (+-) ? 1226496442 M * Bertl no idea, but I guess it should take about two days to adapt and check 1226496533 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com 1226496539 M * arekm I also have no idea how much such things cost... 100euro, 1000euro, 10000euro... more, less 1226496574 M * Bertl about 1000 EUR max, I'd say 1226497050 M * arekm average salary in .pl is 750eur hehe 1226497063 M * arekm for month ;> 1226497221 M * pmjdebruijn arekm: for educated folks? 1226497246 M * nox for whole viollages :D 1226497253 M * nox villages* 1226497310 M * arekm pmjdebruijn: average in poland means all working people 1226497311 M * fb arekm: 1000 eur, less taxes i'd say 1226497368 M * ghislainocfs2 that is also the minimum salary in france for a month, much of the population is 1000€ per month 1226497376 M * fb pmjdebruijn: education has not much to do with salary here 1226497414 M * arekm fb: http://praca.wp.pl/kat,18453,title,Ile-wynosi-srednia-pensja-Polakow,wid,9557191,wiadomosc.html says 2.7kPLN (gross) which is ~ 730EUR 1226497418 M * fb and it's common entry level educated people earn more than PhD-s 1226497437 M * pmjdebruijn ok 1226497468 M * fb arekm: last time i checked GUS data, it's more than 3500PLN 1226497468 M * ghislainocfs2 of coure high end kernel developers are not the same story 1226497483 M * ghislainocfs2 there is no maximum to salary anyway :) 1226497495 M * ghislainocfs2 and in some country no minimum also 1226497509 M * fb ghislainocfs2: in most countries i'd say 1226497689 M * arekm Bertl: can setup the machine now btw 1226497951 M * Bertl good, take your time ... 1226498604 M * Hawq hello 1226498643 M * Hawq Bertl: I fixed /proc problem... by going back to patch-2.6.27.3-vs2.3.0.35.7.diff 1226498801 M * Hawq Bertl: I wasted yours time a bit, I didn't noticed that patch on my Th was the one above and cvs update wasn't updating it while building. thats why it worked when built on th. 1226498824 M * Hawq Bertl: doing diff of buildlog was good idea :) 1226498990 J * TheSeer ~theseer@border.office.nonfood.de 1226498996 M * TheSeer heya :) 1226499062 M * TheSeer http://phpfi.com/377088 <- is that a known problem? 1226499991 Q * rgl Ping timeout: 480 seconds 1226500087 J * root ~root@ramiris.silicon.org 1226500211 Q * root 1226500245 J * axmax ~axmax@p57A48661.dip0.t-ipconnect.de 1226500523 M * Hawq bbl 1226500603 Q * axmax Quit: jmIrc destroyed by the OS 1226500660 M * daniel_hozac TheSeer: no. 1226500702 M * TheSeer hmm okaay ;) 1226500710 M * TheSeer i rebooted the box as recommended ;/ 1226501253 M * TheSeer daniel_hozac: any obvious idea as to why that might have happend? 1226501345 M * daniel_hozac not relaly. 1226501482 M * TheSeer k.. never mind then.. 1226501503 M * TheSeer what's the status for later kernel versions anyway? 1226501538 M * daniel_hozac work-in-progress. 1226501585 M * TheSeer ;) 1226501600 M * TheSeer so no ETA yet.. 1226502165 Q * fb Quit: maintenance 1226502238 J * rgl ~rgl@lx2-84-90-232-86.netvisao.pt 1226502536 M * Bertl Hawq: hmm? so recent kernels cause the problem or what? 1226502599 M * Bertl TheSeer: later as in? 1226502612 M * TheSeer ? 1226502621 M * Bertl 15:51 < TheSeer> what's the status for later kernel versions anyway? 1226502621 M * TheSeer ah.. 1226502624 Q * mtg Quit: Verlassend 1226502630 M * TheSeer yeah, took me a while to grasp the context ;) 1226502651 M * TheSeer well, > 2.6.22 1226502656 M * Bertl http://vserver.13thfloor.at/Experimental/ 1226502679 M * Bertl (up to, and including 2.6.27.4/5) 1226502729 M * TheSeer ah.. good one... how experimental is experimental? ;) 1226502761 M * Bertl well, I use it in production, and so do many others, IIRC 1226502785 M * TheSeer hmm.. okay, that should be good enough ;) 1226502788 M * Bertl okay, have to grab some groceries .. bbl 1226502796 N * Bertl Bertl_oO 1226502798 M * TheSeer thanx ,) 1226505480 P * kir Leaving. 1226505805 J * mtg ~mtg@dialbs-088-079-143-204.static.arcor-ip.net 1226505940 J * eugen ~eugen@host-62-245-148-129.customer.m-online.net 1226505944 N * eugen bluegene 1226505963 M * bluegene anyone awake? 1226505991 M * xdr bluegene: yes 1226506003 M * bluegene Very good. 1226506011 M * bluegene Anyone using PVFS2 with vservers? 1226506141 M * xdr bluegene: not me sorry 1226506146 M * bluegene To explain, I'm running into I/O limitations, so I'm trying to explore alternatives. 1226506175 M * bluegene I have a RAID1 SATA setup, which doesn't scale too great. 1226506192 M * bluegene Do you use cluster filesystems, or a SAN? 1226506217 J * ntrs_ ~ntrs@77.29.12.235 1226506364 M * bluegene I was thinking that given that there are problems with xfs then PVFS is probably not going to work. 1226506398 M * bluegene It probably makes sense to allocate half of the storage for PVFS, and keep the vservers on the local fs. 1226506421 M * bluegene I'll probably just ask on pvfs-users list. 1226506710 J * ntrs__ ~ntrs@77.29.9.140 1226506979 J * torsti76 ~torsti76@gate.iwm-kmrc.de 1226506989 M * torsti76 hi folks! 1226506995 M * torsti76 i have a very odd problem 1226507007 M * torsti76 im running vserver on an amd64 host 1226507023 M * torsti76 and added a 32 bit guest (all gentoo linux) 1226507030 M * torsti76 so far, so good 1226507073 M * torsti76 now i want to use python 1226507088 M * torsti76 and install eggs 1226507125 M * torsti76 to do so, i have to prepend linux32 everytime i call a script 1226507142 Q * ntrs_ Ping timeout: 480 seconds 1226507169 M * torsti76 otherwise, python would try to get amd64 eggs, since uname -m says "x86_64" 1226507212 M * torsti76 is there a way to circumvent this? i.e. "fake" an i686 uname entry for 32bit guests? 1226507223 M * torsti76 any help would be highly appreciated 1226507433 N * Bertl_oO Bertl 1226507437 M * Bertl back now ... 1226507449 M * torsti76 hi bertl 1226507454 M * Bertl torsti76: configure your guest properly, and it will show i586 by default 1226507485 M * Bertl alternatively you can configure this string via uts config 1226507499 M * torsti76 bertl: can you give me a hint, where the "magic" config option resides? ;) 1226507530 M * Bertl http://www.nongnu.org/util-vserver/doc/conf/configuration.html 1226507566 M * torsti76 thx 1226507596 M * Bertl bluegene: what is PVFS? 1226507709 M * Bertl bluegene: btw, there is a patch for xfs 1226507774 M * Bertl bluegene: and if you are having troubles with I/O why do you experiment with the filesystem? 1226507843 Q * ntrs__ Read error: Connection reset by peer 1226507888 A * ard would stick to ext3 anyway... 1226507923 M * ard Since 2.6.19 or so all filesystems scale equally well, ext3 is even on par with reiser3.6 1226507937 M * ard reiser4 however is a different store 1226507951 A * ard hasn't tried ext4 or logfs or ubifs yet 1226507990 M * pmjdebruijn ubifs isn't for general use is it? 1226507996 M * rgl reiser did not stall development? 1226507997 M * pmjdebruijn en logfs is generally weird... 1226508001 M * ard tested stuff with 8 bonnie threads, really writing > 10M files of 5..64 k 1226508032 M * ard well, I just mention ubifs and logfs for completeness 1226508080 A * ard also tested while doing drbd raid1 1226508120 M * ard but the real use case is of course depending on the user :-) 1226508147 M * ard the general idea with web programming is that pictures are written to the store, and then forgotten 1226508188 M * ard and then we start slapping with a big trout, and the web programmers suddenly appear to be able to write cleaning scripts :-) 1226508209 M * ard (imagine having to backup > 150M files...) 1226508438 J * glen_ ~glen@elves.delfi.ee 1226508450 M * glen_ can i specify MARK when building vserer? 1226508848 M * Bertl I don't think so ... 1226509864 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1226510000 J * grim1 ~ben@68-117-54-205.dhcp.roch.mn.charter.com 1226510286 M * grim1 hi all -- any ideas on what may have changed between vs2.3.0.34 and vs2.3.0.35.9 that's preventing a vserver from starting? It returns the error: vsysctl: ("kernel/shmall") Permission denied 1226510304 J * dowdle ~dowdle@scott.coe.montana.edu 1226510332 M * daniel_hozac ah... 1226510435 M * grim1 my other vservers that don't depend on the sysctl changes start up and work just fine 1226510505 M * grim1 running util-vserver-0.30.214, but tried 215 as well 1226510577 M * grim1 and the root directory of the vserver is on its own filesystem 1226510579 J * _gh_ ~gerrit@c-71-193-204-84.hsd1.or.comcast.net 1226510595 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-fperm-fix07.diff 1226510612 M * grim1 daniel, you're too quick 1226510753 J * hparker ~hparker@2001:470:1f0f:32c:215:f2ff:fe60:79d4 1226510797 M * arekm er 1226510898 Q * mtg Quit: Verlassend 1226511147 Q * pisco_ Remote host closed the connection 1226511289 J * pisco ~pisco@86.59.118.153 1226511509 M * grim1 I see that the patch is against 2.3.0.35.8, is that a better choice than 2.3.0.35.9? 1226511523 M * daniel_hozac they're the same. 1226511548 M * Bertl hmm, I don't hope so :) 1226511574 M * grim1 k - they're ~12 hours apart so I wonder 1226511587 M * daniel_hozac Bertl: they are :-) 1226511612 M * Bertl hum, how did that happen? 1226511633 M * Bertl (and why didn't you tell me earlier?) 1226511678 M * grim1 indeed, same 1226511719 M * grim1 after diffing the diffs 1226511732 M * Bertl yep, correct ... 1226511751 M * Bertl time to fix that :) 1226511823 M * grim1 thanks again. vservers on 2.6.27 is the best thing since vservers on 2.6.22 ;) 1226511933 M * arekm Bertl: some progress? 1226511950 M * Bertl not yet ... 1226511961 M * grim1 so happy to be able to take advantage of the ocfs2 improvements in the .23 and .24 kernels 1226512051 M * pmjdebruijn is it usable now then? 1226512072 M * pmjdebruijn We've played with it in the past... not considering it stable enough for production use 1226512137 M * grim1 it's been stable for me -- the biggest problem i've seen is an occasional iowait on a file 1226512227 M * grim1 In a directory where several cluster are dumping files, I'll see processes get permanently stuck in iowait 1226512236 A * arekm can confirm that .27 with vserver is behaving stable (beside known ipv6 problem) 1226512261 Q * davidkarban Quit: Ex-Chat 1226512267 M * arekm actually I use .27 kernel with vserver+grsecurity+apparmor at once 1226512269 M * grim1 pmjdebruijn: that is if you're referring to ocfs2 1226512275 M * pmjdebruijn grim1: the issue we had, was while rebooting one of the two ocfs2 machines 1226512284 M * pmjdebruijn grim1: the other would crash and reboot as well ;) 1226512288 M * pmjdebruijn so much or redundancy :) 1226512292 M * pmjdebruijn for* 1226512294 M * grim1 yep, had that happen in the past 1226512314 M * pmjdebruijn we generally don't even want shared fs anymore 1226512321 M * grim1 was resolved with proper tuning 1226512327 M * grim1 yep, I'd never do it again ;) 1226512342 M * pmjdebruijn grim1: oh well, good to hear that was fixed 1226512399 M * grim1 _seems_ to be fixed I'll give it a few more months to be sure 1226512414 M * pmjdebruijn right 1226512475 M * grim1 it's good for what it is -- we're mounting a few large filesystems off of an iscsi nas 1226512483 A * pmjdebruijn shivvers 1226512487 M * pmjdebruijn the i-word 1226512501 M * pmjdebruijn something else that doesn't work well with vanilla kernels 1226512522 M * pmjdebruijn we've had major issues with iSCSI as well 1226512554 M * pmjdebruijn we started out on FibreChannel... then considers iSCSI for some things... biggest mistake we've made in a long while 1226512561 M * pmjdebruijn we have everything on FibreChannel now... 1226512567 M * grim1 as did we... but eventually worked all those kinks out 1226512589 M * grim1 FC would be ideal 1226512594 M * arekm fc costs too much. /me prefers local storage, less problems and failure points 1226512595 M * pmjdebruijn grim1: In my storage... I don't want kind to have ever existed in my knowledge 1226512607 A * pmjdebruijn doesn't gamble with storage... 1226512625 M * pmjdebruijn FC is horribly expensive... but it just works... very reliable... especially with multipath... 1226512651 M * pmjdebruijn but it buys you peace of mind... 1226512654 M * grim1 arekm: local storage is king 1226512688 M * pmjdebruijn but not very maintainable with larger numbers of servers 1226512690 Q * TheSeer Quit: Client exiting 1226512698 M * grim1 bah -- google 1226512718 M * pmjdebruijn we don't have everything on FC though... 1226512727 M * pmjdebruijn only servers which have customer data 1226512765 M * grim1 what I'd really like to see more of is ATAoE 1226512800 M * grim1 so simple 1226512826 M * arekm heh, so low performance disks? 1226512866 N * pmenier pmenier_off 1226512878 M * grim1 high qty of low performance disks still makes for a fast array 1226512918 M * pmjdebruijn grim1: so unreliable disks 1226512919 M * grim1 besides, there are plenty of fast sata disks available these days 1226512938 M * grim1 and reliable 1226512958 M * arekm fast? not with ton of random/parallel traffic like web/email serving 1226512971 M * pmjdebruijn grim1: with cheap controllers, it's usually the controller that's the bottleneck, not the disks 1226512993 M * grim1 ATAoE supports NCQ 1226513000 M * grim1 each disk has its own controller 1226513059 M * grim1 it's faster than you think 1226513109 M * grim1 as for random parallel traffic -- that's what memcached is for 1226513115 M * arekm I have sata disks and these are slow 1226513119 A * Hawq back 1226513143 M * Hawq Bertl: still here? 1226513147 M * arekm I know no mail server (pop3/imap) that uses memcached but well... 1226513175 M * grim1 fair enough -- not my workload though 1226513180 M * arekm or web server on hosting farm (yes, it's used by portals and such but you can't do that on hosting) 1226513216 Q * torsti76 Quit: Leaving. 1226513285 M * Hawq Bertl: no. not recent kernel is causing problems here. recent patches :( older patch and all is working, newer patch... oops, permission to /proc is denied 1226513312 M * pmjdebruijn grim1: we have dual-attached fibrechannel drives... 1226513320 M * pmjdebruijn :) 1226513348 M * Bertl Hawq: doesn't make sense 1226513356 Q * rgl Ping timeout: 480 seconds 1226513378 M * Bertl Hawq: so what is the latest version which works for you? 1226513467 M * Hawq patch-2.6.27.3-vs2.3.0.35.7.diff 1226513492 M * Bertl and the 35.8 fails for you, yes? 1226513501 M * Hawq yes 1226513507 M * grim1 arekm: a memcached enhanced mail system would be a good product 1226513547 M * Hawq Bertl: now I double checked that and I'm sure. pure vanilla 2.6.27.5 + patch-2.6.27.3-vs2.3.0.35.7.diff works 1226513571 M * Hawq Bertl: newer patch and /proc becomes unaccessible after setattr -Rx --hide /proc 1226513741 M * Bertl daniel_hozac: all relevant changes I can see there are your dx_permission changes, any ideas on that? 1226513771 J * fb fback@red.fback.net 1226513781 M * fb hello again :) 1226513876 J * Piet ~piet@86.59.118.153 1226513926 M * fb to move guest between two filesystems, can i just stop the guest, then xfs_dump ... | xfs restore ... files between the filesystems? 1226513962 M * pmjdebruijn probably 1226513984 M * pmjdebruijn fb: or xfscopy 1226514009 M * fb or i'm gonna lose some important attributes? 1226514013 M * pmjdebruijn fb: but I'd recommend dump -> restore, as that really rebuilds the fs instead of copying... it's a bit slower... but you lose any error (if any existed) on the source fs 1226514039 M * pmjdebruijn fb: xfs_dump xfs_restore should handle acls properly (if I'm not mistaken... but the man page is your friend) 1226514082 M * fb pmjdebruijn: standard acl, yes, but i'm concerned about vserver-related acls, if any exist for vserver :) 1226514201 M * pmjdebruijn vserver related acls? 1226514201 M * fb (and for xfs filesystem) 1226514202 M * pmjdebruijn no clue 1226514240 M * Bertl fb: there are no Linux-VServer related acls yet :) 1226514260 M * fb Bertl: thanks! 1226514262 M * Bertl fb: flags are stored as xattrs, and they should be dumped/restored properly 1226514284 M * fb so i can use xfs_dump/restore safely, as man page suggests 1226514290 M * Bertl but you never know if the xfs tools get that right 1226514315 M * Bertl in case of doubt, rsync (with the proper options) should get the job done 1226514320 M * fb Bertl: they claim to do that :-) 1226514345 M * pmjdebruijn at in theory, the change that xfs_dump/xfs_restore get it right is higher than rsync :) 1226514349 M * fb beside, are there any use of them for non-hashified guests? 1226514368 M * pmjdebruijn we only have plain guests though, no shared resources 1226514380 J * grim11 ~ben@68-117-54-205.dhcp.roch.mn.charter.com 1226514564 Q * dna Quit: Verlassend 1226514679 Q * grim1 Ping timeout: 480 seconds 1226514702 J * cga ~weechat@94.36.130.212 1226514942 M * fb hmh 1226514962 M * fb is that normal, there's no loopback for ipv6-only guest? 1226515014 M * daniel_hozac Bertl: as Hawq showed, IATTR_PROC_DEFAULT isn't being applied. 1226515049 M * daniel_hozac Bertl: that in combination with the vx_hide_check leads to inaccessible entries. 1226515147 M * Bertl okay, now the big question, why isn't it 'being applied'? 1226515170 M * daniel_hozac that i didn't get to :) 1226515388 M * Bertl Hawq: what is the filesystem /proc is mounted on? 1226515427 M * Hawq I use ext3 1226515856 M * daniel_hozac Bertl: looks like it's just missing from /proc itself though. 1226515858 M * daniel_hozac at least for me. 1226515870 M * Supaplex without restarting the guest, how do I rehash the networking? I need the guest/interfaces/* stuff to reapply. 1226515882 M * Bertl Hawq: could you check if reverting this one: http://people.linux-vserver.org/~dhozac/p/k/delta-fperm-fix06.diff makes vs2.3.0.35.8 makes it work as expected? 1226515886 M * daniel_hozac Supaplex: do it manually. 1226515914 M * Bertl s/makes/from/ 1226516016 M * Supaplex and how? :) 1226516040 M * daniel_hozac Supaplex: see http://linux-vserver.org/Frequently_Asked_Questions#How_do_I_assign_a_new_IP_address_to_a_running_guest.3F 1226516091 M * fb i have a guest with only ipv6 address assigned, and there's no lo interface inside the guest. Is the loopback for ipv6 virtualised too? should i create lo interface manually? 1226516108 M * daniel_hozac fb: it isn't, that's why there isn't one. 1226516179 M * daniel_hozac Bertl: http://people.linux-vserver.org/~dhozac/p/k/delta-proc-fix02.diff 1226516212 M * daniel_hozac not sure it makes sense yet though. 1226516235 M * Bertl the main question is, why does it work for me, but fail for Hawq? 1226516244 M * daniel_hozac have you hidden /proc? 1226516253 M * daniel_hozac i.e. setattr --hide /proc? 1226516278 M * Bertl well, no, but util-vserver should do the same for him as it does for me, no? 1226516300 M * daniel_hozac util-vserver doesn't do that. 1226516329 M * Bertl so who is doing that? IIRC, we agreed that nothing but util-vserver was running/active? 1226516335 M * Supaplex # naddress --add --nid 49164 --ip 10.141.10.3/24 returns Adding 10.141.10.3naddress: vc_net_add(): No such process. vserver-stat shows 49164 is the CTX of the guest I want. 1226516350 M * fb daniel_hozac: so for now it's one of the missing features? Thanks, i think i can do without ::1 within that guest 1226516364 M * daniel_hozac Supaplex: you're using dynamic contexts. 1226516380 M * Bertl Supaplex: nid != xid, and stop using dynamic contexts, they are deprecated since ... ever! 1226516392 M * Supaplex blame debian :P 1226516406 M * Supaplex crap. I have to run to work. 1226516408 M * daniel_hozac because you didn't specify --context xyz when you built the guest? 1226516416 M * Hawq Bertl: its building now with reverted delta-fperm-fix06.diff 1226516445 M * Hawq or should I build just with http://people.linux-vserver.org/~dhozac/p/k/delta-proc-fix02.diff added instead? 1226516452 M * Supaplex no I didn't. more food for thought =) 1226516480 M * daniel_hozac Hawq: that would take care of your issue, anyway. 1226516513 M * Hawq daniel_hozac: then building with delta-proc-fix02.diff added to newest patch 1226516556 M * daniel_hozac i don't think it's the right fix though. 1226516706 M * Hawq daniel_hozac: why not right? 1226516811 J * rgl ~rgl@240.221.68.192.in-addr.arpa 1226516847 P * grim11 1226516906 M * daniel_hozac Bertl: is there a reason we don't give IATTR_WATCH by default? 1226516994 M * daniel_hozac Hawq: it should be IATTR_ADMIN | IATTR_WATCH instead. 1226517051 M * Bertl not that I can remember 1226517216 M * Bertl but I still don't get what changed .. i.e. what is Hawq doing which breaks with fperm-fix06, and why does it break at all? 1226517259 M * daniel_hozac for some reason, something/someone runs setattr --hide /proc. 1226517280 M * daniel_hozac and since it doesn't have IATTR_ADMIN, the host can't see it either. 1226517325 M * Bertl okay, now that starts making sense for the first part, but why does the patch _change_ that behaviour? 1226517349 M * Bertl (assuming that the very same setattr is running without the patch too, but without malicious effect?) 1226517352 M * daniel_hozac yeah, that i don't know. 1226517413 M * glen_ i seem to have one lingering ctx, how to see what is running under ctx=888 ? and possibly kill those procs? 1226517418 M * daniel_hozac vps 1226517445 M * daniel_hozac Bertl: could be we don't check vx_flags in the permission routines for /proc. 1226517532 M * glen_ can i use vkill -c 888 -1 -1 ? 1226517570 M * daniel_hozac vkill -c 888 -- -1 1226517587 M * daniel_hozac -s 1 if you really want SIGHUP 1226517761 Q * fb Quit: moving guest to a new place 1226517870 M * Hawq daniel_hozac: sorry, I was away for a moment. IATTR_ADMIN | IATTR_WATCH instead of IATTR_PROC_DEFAULT in delta-proc-fix02.diff, right/ 1226517874 M * Hawq ? 1226517907 J * g_en__ ~glen@elves.delfi.ee 1226518014 Q * glen_ Ping timeout: 480 seconds 1226518340 M * daniel_hozac Hawq: yes. 1226518439 M * Hawq daniel_hozac: great, I'm already building it 1226518995 J * fb fback@red.fback.net 1226519188 M * g_en__ are there any useful scripts to be placed to scripts/ dir to handle guest iptables rules somewhat easier? 1226519218 M * g_en__ found also some vserver_virtuatables-0.1.tar.gz ... idea looks nice, but it's written in php and not good overview what is it doing 1226519244 N * g_en__ glen__ 1226519472 M * daniel_hozac glen__: i just have one static ruleset that is loaded when the host boots. 1226520676 Q * rgl Ping timeout: 480 seconds 1226520762 J * rgl ~rgl@240.221.68.192.in-addr.arpa 1226521407 Q * sladen Ping timeout: 480 seconds 1226521568 M * Hawq daniel_hozac: yup, now it works. thanks a lot. I'm sending 2.6.27.5 to pld titanium :) 1226521696 M * Bertl Hawq: who is doing the malicious setattr --hide /proc ? 1226521742 M * daniel_hozac Bertl: i sort of think it's a bug it's not being denied even without that :-) 1226521792 M * Bertl that's fine, but I'd like to figure why this is done on pld ... 1226522571 M * Hawq Bertl: in PLD there is vprocunhide startup script which is part of our util-vserver package. 1226522575 M * Hawq Bertl: http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/vprocunhide.init?rev=1.11 1226522582 J * sladen paul@193.28.45.41 1226522600 M * Hawq Bertl: there are also init scripts for vroot devices and for starting vservers 1226522684 M * daniel_hozac and you're not using the ones in util-vserver because....? 1226522709 M * daniel_hozac and obviously, you're doing it wrong :-) 1226522980 M * Hawq daniel_hozac: PLD always uses own startup scripts as they must obey set of rules we have for them. usually they're simply original scripts adjusted to meet PLD requirements. in this particular case I wasn't touching startup scripts so I don't know why they do what they do :) 1226523017 M * Hawq daniel_hozac: someone more familiar with PLD rc-scripts would tell more here, I'm not the one 1226523020 M * Bertl but it seems, they do different things than the util-vserver scripts :) 1226523179 M * Hawq Bertl: possible. original vprocunhide.init is dated may 6th 2005 and was created by baggins. he's also the one who added setattr --hide 1226523215 M * Bertl so now we've found the guilty one :) 1226523334 J * m_o_d ~kane@host.ltv.pl 1226523336 M * m_o_d hello 1226523338 M * Hawq seems so. reason he gave for setattr was "more paranoia" :) 1226523392 M * m_o_d how can i guest default run level from 3 to 2? 1226523434 M * daniel_hozac m_o_d: as per the great flower page, apps/init/runlevel.start 1226523448 M * daniel_hozac Hawq: just in case the kernel got it wrong? 1226523456 M * daniel_hozac Hawq: in which case, i think you have far more serious problems... 1226523558 M * Hawq daniel_hozac: could be. I don't know why he added setattr. 1226523567 M * Hawq daniel_hozac: what kind of problems? 1226523646 M * daniel_hozac your kernel's not doing what it's supposed to. there's no guarantee it's going to honor that setting anyway. 1226523853 M * Hawq daniel_hozac: so it would be safer to drop that setattr + update our init scripts so they do what original script does? 1226523893 M * daniel_hozac it's what i'd do. 1226524085 M * Hawq daniel_hozac: well, I'll look over original and our scripts and try to rework them 1226524109 M * Hawq but first I'll try to nail problem with X and console switching :) 1226524223 M * m_o_d daniel_hozac: where i can find description about directory structure in /etc/vserwer/$guest/ ? 1226524436 M * daniel_hozac m_o_d: as i said, the great flower page. http://www.nongnu.org/util-vserver/doc/conf/configuration.html 1226524484 M * m_o_d great 1226525091 Q * FireEgl Read error: Connection reset by peer 1226525219 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com 1226526013 Q * cga Quit: WeeChat 0.2.6 1226526746 Q * meebey Ping timeout: 480 seconds 1226527404 M * arekm $_VSERVER_INFO - FEATURE iattr || exit 0 1226527408 M * arekm what does this test for? 1226527651 M * daniel_hozac tests if iattr support is available in the kernel. 1226529029 Q * bonbons Quit: Leaving 1226530756 M * Hawq sleep time here. good nite. 1226531042 J * Hollow__ ~hollow@shiva.xnull.de 1226531048 Q * Hollow Remote host closed the connection 1226531067 J * bzed_ ~bzed@devel.recluse.de 1226531071 J * ghislainocfs21 ~Ghislain@adsl2.aqueos.com 1226531079 Q * bzed Remote host closed the connection 1226531084 N * bzed_ bzed 1226531101 N * Hollow__ Hollow 1226531129 J * derjohn_mob ~aj@p5B23FBD4.dip.t-dialin.net 1226531396 Q * ghislainocfs2 Ping timeout: 480 seconds 1226532277 Q * rgl Quit: Leaving 1226533183 J * yarihm ~yarihm@77-56-182-18.dclient.hispeed.ch 1226533479 Q * balbir Quit: Coyote finally caught me 1226533611 J * doener ~doener@i577AC489.versanet.de 1226533862 J * balbir ~balbir@32.97.110.53 1226534019 Q * Piet Quit: Piet