1226880498 J * ntrs__ ~ntrs@77.29.18.27 1226880970 M * Bertl okay, off to bed now .. have a good one everyone! 1226880975 N * Bertl Bertl_zZ 1226880982 Q * ntrs__ Ping timeout: 480 seconds 1226881350 Q * Piet Quit: Piet 1226881761 Q * pisco_ Ping timeout: 480 seconds 1226882518 J * pisco ~pisco@86.59.118.153 1226884184 Q * bonbons Quit: Leaving 1226886517 Q * dowdle Remote host closed the connection 1226886880 Q * geb Remote host closed the connection 1226894628 N * quinq qzqy 1226894635 Q * pisco Remote host closed the connection 1226895748 J * pisco ~pisco@86.59.118.153 1226900612 J * Aiken ~Aiken@ppp118-208-13-1.lns1.bne1.internode.on.net 1226902492 J * ntrs__ ~ntrs@77.29.19.95 1226903235 J * mtg ~mtg@dialbs-088-079-143-204.static.arcor-ip.net 1226903808 J * yarihm ~yarihm@whitehead2.nine.ch 1226904272 Q * hparker Quit: Read error: 104 (Peer reset by connection) 1226905344 J * Slydder1 ~chuck@dslb-088-072-100-063.pools.arcor-ip.net 1226905348 Q * Slydder1 1226909645 J * ntrs_ ~ntrs@77.29.21.129 1226910082 Q * ntrs__ Ping timeout: 480 seconds 1226910704 J * ghislainocfs2 ~Ghislain@adsl2.aqueos.com 1226911626 J * larsivi ~larsivi@85.221.53.194 1226911734 J * pmenier ~pme@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr 1226913986 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1226914661 N * Bertl_zZ Bertl 1226914665 M * Bertl morning folks! 1226914957 Q * mtg Ping timeout: 480 seconds 1226916159 J * mtg ~mtg@dialbs-088-079-143-204.static.arcor-ip.net 1226916431 J * zbyniu_ ~zbyniu@ip-62.181.188.13.static.crowley.pl 1226916526 Q * zbyniu Ping timeout: 480 seconds 1226917234 M * nox omfg 1226918046 J * Pazzo ~ugelt@reserved-225136.rol.raiffeisen.net 1226918296 Q * mtg Ping timeout: 480 seconds 1226918831 Q * gnuk Ping timeout: 480 seconds 1226919536 M * fb hello Bertl :) 1226919866 N * zbyniu_ zbyniu 1226921705 M * glen__ how bad idea is it to add db_dump + db_load to rpm internalize / externalize actions? 1226921723 M * glen__ as this would solve most of the host+guest rpmdb version mismatch problems 1226922125 M * Bertl talk to daniel_hozac :) 1226922581 M * glen__ and how to handle etc/rpm/platform file, which should be different for x86_64, i686, i486 guests? 1226922810 J * independence independen@titan.blinkenshell.org 1226923352 J * mtg ~mtg@dialbs-088-079-143-204.static.arcor-ip.net 1226924896 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net 1226926602 N * qzqy quinq 1226926656 Q * Aiken Quit: Leaving 1226928841 Q * xdr Ping timeout: 480 seconds 1226929708 Q * _nono_ Quit: Leaving 1226930080 Q * FireEgl Quit: Leaving... 1226930458 J * pflanze ~chris__@77-56-73-53.dclient.hispeed.ch 1226930605 M * Bertl nap attack ... off for now, bbl 1226930617 N * Bertl Bertl_zZ 1226930921 M * daniel_hozac glen__: don't use /etc/rpm/platform. 1226931269 J * ntrs__ ~ntrs@77.29.10.175 1226931697 Q * ntrs_ Ping timeout: 480 seconds 1226933445 J * hparker ~hparker@2001:470:1f0f:32c:215:f2ff:fe60:79d4 1226933611 Q * larsivi Ping timeout: 480 seconds 1226933910 M * glen__ daniel_hozac, jbj rpm needs it, or it will say package is for invalid platform (linux) 1226933931 M * daniel_hozac that's an... interesting direction. 1226933958 M * daniel_hozac but to be honest, i don't care about jbj rpm. 1226934036 M * glen__ well it's /etc/rpm/platform file for jbj to handle different target arch rpm's, likely fedora rpm you need to copy while /usr/lib/rpm/macros* 1226934110 M * daniel_hozac with Red Hat's rpm you just change your personality and things work as expected. 1226934178 M * glen__ hmm. personality 1226934312 J * tam ~tam@gw.nettam.com 1226934333 M * glen__ and how do you set the personality for build? 1226934366 M * daniel_hozac linux32 vserver .... 1226934369 M * glen__ personality is set later if i echo linux_32bit > /etc/vservers//personality 1226934388 M * glen__ and how do you differenciate between i386 or i586 archs? 1226934453 M * daniel_hozac you don't. 1226934472 M * daniel_hozac 'cuz seriously, who even builds an i386 distro any more? 1226934515 M * glen__ i could need to build any guest, why put boundaries here 1226934619 M * daniel_hozac modifying /etc/rpm/platform on the host is hardly a viable solution. 1226934649 M * glen__ nay, not host, guest 1226934674 J * chI6iT41 ~chigital@services.mivitec.net 1226934735 M * daniel_hozac build uses the host's /etc/rpm/platform, as the guest doesn't exist yet. 1226934963 M * glen__ nope 1226934973 M * glen__ it does use rpm/platform which is copied to guest dirs 1226934986 M * glen__ as if i put correct data there, then build works, if i put wrong one, it fails 1226935581 Q * chI6iT41 Ping timeout: 480 seconds 1226936678 J * xdr ~xdr@118-173-96-87.cust.blixtvik.se 1226937056 J * xdr_ ~xdr@118-173-96-87.cust.blixtvik.se 1226937081 Q * sid3windr Ping timeout: 480 seconds 1226937166 Q * xdr Ping timeout: 480 seconds 1226937257 J * dowdle ~dowdle@scott.coe.montana.edu 1226937270 J * sid3windr luser@bastard-operator.from-hell.be 1226937577 M * yarihm daniel_hozac, is OpenSuSE still such a hassle to install? 1226937603 M * daniel_hozac i haven't done any more integration work. 1226937614 M * daniel_hozac i'm not aware of anyone else doing it either. 1226938145 J * geb ~geb@4.4.82-79.rev.gaoland.net 1226938383 M * yarihm I do not blame you ... this distro IMHO sucks 1226938494 M * geb hi 1226938694 M * daniel_hozac that is my opinion as well, which is why i haven't really been motivated to fix it :) 1226939617 J * doener ~doener@i577AF9EF.versanet.de 1226939680 M * independence does anyone know when the next stable vserver release might be? 1226939708 M * daniel_hozac when it's done :) 1226939721 Q * doener_ Ping timeout: 480 seconds 1226939737 M * independence mhm, ok. so it's not anytime soon then? :p 1226939757 M * daniel_hozac i'd like it to be soon, but who knows. 1226939994 M * pflanze Is anyone maintaining a Git repo of the kernel code? 1226940001 M * daniel_hozac no. 1226940031 N * Bertl_zZ Bertl 1226940034 M * Bertl back now ... 1226940106 M * pflanze I'd like to try vserver with a recent kernel (like 2.6.27.6), and maybe also add grsecurity into the mix. 1226940126 M * independence ya, 2.6.27 with vserver and grsec would be sweet :) 1226940135 M * pflanze patch-2.6.27.4-vs2.3.0.35.9.diff will probably apply; 1226940165 M * pflanze but I'm not sure about the newer patches up there, delta-mutex-fix01.diff and delta-xfs-feat01.diff 1226940180 M * pflanze should I add those on top? 1226940193 M * pflanze That's what I don't see from patch files. 1226940199 M * independence and then grsec on top of that? I hope you know what you're doing hehe :) 1226940350 M * pflanze I really don't understand why you're not using Git. 1226940380 M * pflanze It's difficult enough to follow up on the patches, why make life more difficult. 1226940405 M * pflanze I can't believe that you find Git doesn't suit you. 1226940418 M * Bertl pflanze: would a git repository with 10 diverging branches help you? 1226940445 M * pflanze Probably, 1226940457 M * pflanze for merging with grsecurity I expect so. 1226940464 M * pflanze (Or for merging with anything) 1226940476 M * Bertl well, then go ahead, and check the patches in, and do a branch on each patch where you are not sure :) 1226940506 M * pflanze I need your info on what is meant to combine with what. 1226940518 M * daniel_hozac read the headers. 1226940530 M * pflanze (And those patches are quite coarse grained, and don't contain any message about what they are doing) 1226940540 A * pflanze goes reading 1226940564 M * Bertl yeah, well, mutex fix is hard to explain (what it does ... :) 1226940670 M * Bertl pflanze: those are the things wich really anoy me (and it is probably hard to anoy me :) because, a) I tried GIT, and figured that it is not suited for my way of working, and b) you are the person who 'would like' to use GIT, so stand up, do _your_ part, maintain a git repository 1226940703 M * pflanze I'll do 1226940710 M * pflanze if there's no better way. 1226940726 M * Bertl the better way would be? 1226940729 M * pflanze It's just that I will check vserver every few months or so 1226940745 M * pflanze so it's of no use for others during the pauses, probably 1226940766 M * pflanze I don't understand it. 1226940769 M * Bertl see, you want to add a lot of work to _my_ spare time, to maintain a repository _you_ will use every few month :) 1226940774 M * pflanze I'll do what you tell me, 1226940779 M * pflanze and then try to understand you. 1226940781 M * pflanze Promised. 1226940851 M * pflanze The point is exactly that I can't understand why it would take you any more time to work with Git. 1226940867 M * pflanze But again, I do *not* expect anything, I *will* do as you tell me. 1226940886 M * pflanze I'm just going eat a sandwhich now and then check patches in for a try. 1226941335 J * balbir` ~balbir@bi-03pt2.bluebird.ibm.com 1226941360 J * balbir`` ~balbir@32.97.110.53 1226941361 Q * balbir Read error: Connection reset by peer 1226941671 N * morrigan morrigan_oO 1226941829 Q * balbir` Ping timeout: 480 seconds 1226941894 Q * balbir`` Ping timeout: 480 seconds 1226942029 M * Bertl daniel_hozac: btw, did you look at the ipv6 issues, I found a few checks which really make me wonder ... 1226942073 M * daniel_hozac just some quick glances. 1226942077 M * Bertl http://pastebin.ca/1257951 (~ line 230) for example 1226942081 M * daniel_hozac we're missing some rather important checks :) 1226942158 M * Bertl well, I expected that we are missing some checks, but it seems we are alos doing a lot of unnecessary checks :) 1226942191 M * daniel_hozac i guess so. 1226942227 M * Bertl do you have any patches sitting around addressing any of those 'missing' or unnecessary checks? 1226942296 M * daniel_hozac no, i just glanced at it. 1226942351 M * Bertl okay, np, I just wondered, because I remember that bonbons did check the ipv6 stuff back then ... btw, bonbons: ping? 1226942388 M * daniel_hozac yeah, i verified it too. 1226942397 M * daniel_hozac so they must've gone missing at some point. 1226942411 M * Bertl that's my point 1226942425 M * bonbons Bertl: pong 1226942493 M * Bertl hey, could you have a look at the traces and maybe the ipv6 patches in Linux-VServer and point out any 'obvious' bugs to me? 1226942538 M * Bertl if it helps, I can break out the ipv6 stuff (in a single patch) 1226942690 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com 1226942834 J * chI6iT41 ~chigital@tmo-096-222.customers.d1-online.com 1226942859 M * bonbons Bertl: some context information would help... 1226942954 M * Bertl okay, arekm sees the following behaviour: 1226942969 M * Bertl a) he is able to bind to ipv6 IPs assigned to _other_ guests 1226943001 M * Bertl b) connections made from one guest, to some extend, use the wrong source ip to reach outside 1226943022 M * Bertl let me provide you with the IRC logs for that 1226943033 M * bonbons using which version of vserver patch? 1226943079 M * Bertl the latest 1226943094 M * Bertl I added a bunch of debug messages to the ipv6 code yesterday 1226943122 M * Bertl http://vserver.13thfloor.at/Experimental/delta-ipv6-debug01.diff 1226943136 M * Bertl this should be an up-to-date version: http://vserver.13thfloor.at/Experimental/patch-2.6.27.4-vs2.3.0.35.10.diff 1226943147 M * Bertl a version for 2.6.27.6 will be up shortly 1226943218 M * Bertl http://irc.13thfloor.at/LOG/2008-11/LOG_2008-11-12.txt this and LOG_2008-11-16.txt 1226943291 M * bonbons ok, will have a look at it 1226943300 M * Bertl excellent, thanks! 1226943325 M * Bertl (patch for 2.6.27.6 is now up too) 1226944173 M * pflanze Bertl: have you worked with Darcs? 1226944488 M * glen__ how to run some tool inside vserver guest in pkgmanagement internalize phase? 1226944520 M * glen__ as i'd like to run db_dump in host and db_load in guest against guest rpmdb 1226944576 M * glen__ some %__exec_cd ? 1226944592 M * Bertl pflanze: not yet 1226944618 M * pflanze Bertl: I was just wondering, because it's patch oriented; 1226944641 M * pflanze I haven't really worked with it, but if I'm going to write a tool that takes patches and builds git trees from it, 1226944649 M * pflanze I should look at how darcs works. 1226944726 M * pflanze Or maybe darcs2 would even just be able to cope with the requirements. 1226945006 M * Bertl are you planning on developing Linux-VServer kernels? 1226945020 M * pflanze Can't say; 1226945024 M * cehteh why not just git / stgit? 1226945037 M * pflanze not really, I basically just want a few working servers with subsystems. 1226945053 M * pflanze cehteh: because it didn't work for him -- at least not plain git 1226945090 M * Bertl pflanze: why in the hell, do you try to change our development style/tools then? 1226945118 M * cehteh Bertl: do you have a git for vserver yet? 1226945126 M * pflanze cehteh: no, see above 1226945137 M * cehteh heh .. i just peeking in 1226945168 M * pflanze Bertl: ehr. 1226945170 M * cehteh but setting up a vserver git should be trivial ... its more about convincing the involved people :P 1226945184 M * Bertl we already have a git repository 1226945197 M * cehteh ah .. url? 1226945211 M * Bertl it is just not used .. but again, why would you want to convince the developers to use it, if they don't like it? 1226945240 M * cehteh it would make it easier for me :) 1226945258 M * Bertl in what way exactly? 1226945270 M * cehteh but yes i acknowledge, it needs at least one of the core devs who wants to maintain it 1226945300 M * cehteh i can just merge things in and look at them. thus following the progress easier and possible more often test things 1226945338 M * cehteh currently i merely wait until some "to be told" stable patch appears and then i make a new kernel every half a year or so 1226945338 M * Bertl and why exactly can't you do that if you import the Linux-VServer patch into your git repository? 1226945349 M * cehteh i could do that 1226945355 Q * mtg Quit: Verlassend 1226945357 M * cehteh but its more work for me 1226945376 M * pflanze I think it's not the "more work", it's less transparent. 1226945384 M * Bertl well, so the idea is to put all the work on the kernel developers, good idea :) 1226945401 M * cehteh git pull vserver vs looking at the vserver page, figuring out whats the most actual, fetching it, applying it, maybe diffing it etc 1226945494 M * cehteh Bertl: i believe it would pay back for you, because more people review and test the code .. but otherwise, thats just my opinion, do wahtever you want, someone else could maintain the vserver git too, just needs someone who cares 1226945532 M * cehteh well and instead preparing patches, just commiting into your git would be easier for you too .. but :) 1226945544 M * Bertl so you really believe that git is a good way to 'review' changes (not to say patches)? 1226945581 M * cehteh reviewing is almost the same .. but deployment of patches gets much easier 1226945596 M * Bertl cehteh: first, preparing a patch (besides the coding, compiling and testing) is a single command (<60 chars) here 1226945619 M * Bertl including the upload to the web site 1226945622 M * pflanze It depends on whether the patches are individual changes or whole patches-against-upstream linux. 1226945635 M * pflanze The individual patches would be nice -- but I don't see the grouping. 1226945673 M * pflanze The combinded patches are pretty much impossible to work with (both looking at, and merging). 1226945677 M * cehteh Bertl: with git or any distributed version control system you could change/improve your workflow, commiting very small changes, 10 times a day if you like 1226945682 M * Bertl cehteh: second, how would git benefit me there, except for the fact, that it will result in endless time spent on fixing up broken repositories and commits? 1226945694 M * cehteh huh? 1226945726 M * Bertl you don't seem to realise that I often commit my changes 10 times a day (as patches) 1226945728 M * cehteh i never had a problem with broken repositories or broken commits 1226945748 M * pflanze Bertl: where are those patches? 1226945755 M * cehteh yes i dont notice that because it is not transparent to me 1226945771 M * Bertl http://vserver.13thfloor.at/Experimental/ 1226945782 J * cga ~weechat@94.36.130.212 1226945803 M * pflanze But I only see about 5-10 patches per month ther 1226945804 M * pflanze e 1226945840 M * pflanze I guess those are the relevant ones, those to keep? 1226945842 M * pflanze Or not? 1226945854 M * Bertl that's because there is little time (and almost no payed time) to do more development atm 1226945889 M * Bertl and yes, those patches are not random commits, they are well tested 1226945932 M * cehteh well .. i have to go on .. if you have git questions or need git help you can nag me anytime, thats with what i could help, if you want to go on as before, well it worked so far, inconvinent for outside people imo, but for you and the other core devs maybe the most convinent/used to 1226945936 M * pflanze Still, what's missing is how the individual patches are combined into the large patch-against-upstream. 1226945984 M * pflanze I think the reason Bertl doesn't like the Git approach is because he is maintaining patch sets, 1226945989 M * pflanze not so much changesets; 1226945999 M * pflanze i.e. it's the Darcs mindset instead of the Git mindset. 1226946003 M * cehteh dunno 1226946027 M * pflanze With Git, you have to rebase your patchsets all the time, or use git format-patch to create, "ehr", patches. 1226946030 M * cehteh actually his patches are not maintained but carefully created, released and then forgotten or? :) 1226946055 M * pflanze OTOH there are several projects doing patchset workflow on top of Git, but I haven't used those. 1226946077 M * cehteh i do that for my private development tip 1226946083 M * cehteh so ..bbl 1226946118 M * pflanze I could imagine doing some light weight tool to work the patches into Git repositories, so that not one common Git repo is necessary, 1226946125 M * pflanze and no rebasing problem exists. 1226946141 M * glen__ what does exec-cd do? 1226946155 M * pflanze (This is territory where I'd probably be duplicating work of the aforementioned projects, but then.. maybe easy enough and good it is?) 1226946168 M * Bertl pflanze: go ahead, maintain a git repository of Linux-VServer for a month or two 1226946198 M * pflanze Again, I'm not looking after Vserver every day, so somehow this must be automatic. 1226946218 M * pflanze So if you can provide more info about the patches, I could do such a tool. 1226946224 M * cehteh i could place a mob repository on my server if you need such 1226946238 M * cehteh then some people can share the work 1226946246 M * pflanze mob? 1226946257 M * Bertl well, the requirements from my side, to use _any_ repository for actual work would be like this: 1226946258 M * cehteh public/anonymous pushable 1226946274 M * Bertl (note, I'm not against solutions which work for me :) 1226946300 M * Bertl - I can get an arbitrary 'patch' state in a second 1226946318 M * Bertl - I can create a new 'branch' on that version in a few seconds 1226946335 M * cehteh what is a patch state? the state as it was at some point in time? 1226946348 M * Bertl that is basically the 'commit' 1226946358 M * cehteh yes .. so what is a patch state? 1226946367 M * Bertl i.e. something I consider so far tested that it should go to the repository 1226946390 M * pflanze you mean, internal vs. public. 1226946406 M * Bertl no, the workflow here is like this: 1226946408 M * cehteh you can commit untested things and anytime you consider something working you can create a branch for that or just put a tag on it in git 1226946422 M * pflanze Like, you'd like to keep commits (patches) around internally then select them (squash them) for publishing? 1226946426 M * Bertl let me give you an example how e.g. a patch is developed 1226946442 M * cehteh dunno if you are too shy to make test code and bugs public accessible 1226946476 M * Bertl let's assume we have patch-2.6.27.6-vs2.3.0.35.10 as base 1226946483 M * pflanze cehteh: I'm actually concerned with that, too (but I don't know if it's this what bothers Bertl) 1226946494 J * ktwilight_ ~ktwilight@87.66.193.174 1226946497 M * cehteh thats why i am asking 1226946517 M * Bertl now I figure that I should fix something with xfs (again :) 1226946540 M * cehteh creating branches in git is matter of milliseconds 1226946542 M * Bertl what happens here is, I create a new tree (within seconds) of this 'branch' 1226946567 M * Bertl then I edit inside this branch, and do a compile (note, most of the kernel is already compiled) 1226946585 M * Bertl then I do some testing on the resulting kernel with qemu 1226946608 M * Bertl assumed that all is working fine, I 'commit' the changes here, by calling a script 1226946629 M * Bertl that script produces a patch, e.g. delta-xfs-fix99.diff 1226946650 M * Bertl and I can continue to fix something else ... 1226946696 M * Bertl alternatively, if I consider the current working rbanch ready for a 'release', I call another script, which produces a patch-2.6.27.6-vs2.3.0.35.11.diff for example 1226946706 M * Bertl (which is automatically uploaded) 1226946750 M * Bertl note: the important part in this process is that I do not have to wait for either the new branch, or the compile or the commit (which is implicit) 1226946764 M * pflanze How are you creating the new tree, using cp -r --link ? 1226946769 A * cehteh is off .. we can talk another time about this 1226946772 M * Bertl cp -la yes 1226946784 Q * ktwilight Ping timeout: 480 seconds 1226946861 M * pflanze You can have detached working directories with Git, but have never looked into whether the hardlinking part would work. 1226946879 M * pflanze "Usually", you're checking out a new point in history in the current working dir; so, 1226946893 M * pflanze a few files (or more) change, which might not be as cheap as your solution. 1226946899 Q * kir Quit: Leaving. 1226946921 M * pflanze I'm not doing kernel development usually, so dunno what other kernel devs do to mitigate the working dir change problem. 1226946927 M * Bertl which is not what I want, as it often happens that I'm working on three branches at once, for example 1226946952 M * pflanze (In projects of the size I'm working with usually, the "change files in the working dir" & recompile issue isn't an issue) 1226946966 M * pflanze ok 1226946985 M * Bertl the kernel is quite smart in recompiling on stuff which need recompiling 1226946994 M * pflanze well, you can git clone locally, of course; it's just that it (at least usually) doesn't hardlink working directory files 1226947000 M * Bertl given that the timestamps are intact and the objects remain 1226947024 M * Bertl well, if I get a copy, and not hardlinks, the overhead is too high 1226947038 M * pflanze (git clone some/local/path does hardlink the git database, but not the working directory files, esp. the object files, of course) 1226947042 M * Bertl 99% of the files are already in the inode cache 1226947043 M * pflanze yes, I see. 1226947053 M * pflanze But that might be as easy as a wrapper around git clone 1226947101 M * Bertl go ahead, if I get my forrest of working directories, and can easily change/rename each of them as I like (and all that gets propagated to git) I'm fine 1226947128 M * Bertl I'm even willing to write some commit messages :) 1226947149 M * pflanze ok, I'll write such a wrapper script; 1226947165 M * Bertl what I don't want to do is bother with git stuff, tried that, didn't work for me 1226947173 M * pflanze which git stuff? 1226947198 M * pflanze hm 1226947215 M * pflanze I'm thinking in two strains right now: 1226947222 M * Bertl basically any git stuff 1226947235 M * pflanze (a) writing a tool that can take your patches and additional info from you and build a git repo out of it; 1226947280 M * pflanze (b) the above discussion was looking into what Git was missing, and the cp -la thing should be solvable by a cp -la && git clone (with some details probably which I'll have to look into), 1226947294 M * pflanze for as long as you have described here. 1226947338 M * pflanze I guess there might be more than the hardlink issue which may be a problem -- I think the only real one is the rebasing/upstream merging disturbance. 1226947372 M * pflanze (again, some people are working on several tools to handle the latter decently, but I can't vouch for any of them) 1226947404 M * glen__ uuu, how to execute command in gust chroot in pkgmanagement internalize? (so it uses it's libs etc) 1226947467 M * pflanze I'll go ask on #git about what others do to attain the cp -la behaviour, and if nothing exists I'm sure I can write up something. 1226947943 M * glen__ some vnamespace calls? 1226948046 Q * yarihm Quit: Leaving 1226948273 M * Bertl glen__: you don't really want that 1226948391 M * glen__ so plain chroot would be better? 1226948432 M * Bertl no, I meant, you don't want to do anything _outside_ a proces context 1226948462 M * glen__ vserver is stopped anyway when internalize/externalize runs 1226948549 M * glen__ http://glen.alkohol.ee/pld/util-vserver-dbrebuild-internalize.patch 1226948564 M * Bertl the problem is, you do not want to execute guest code on the host. period. 1226948565 M * glen__ here's what i made so far. it works, but likely not good 1226948597 M * glen__ so it would be FINE for me to switch to guest context to gain the purpose 1226951627 M * fb Bertl: i'll wait for 2.6.27.x vserver-grsec patch before testing xfs, if you don't mind :) 1226951644 Q * chI6iT41 Ping timeout: 480 seconds 1226952877 J * ntrs_ ~ntrs@77.29.21.43 1226953299 Q * ntrs__ Ping timeout: 480 seconds 1226953890 M * glen__ Bertl, suggest what to do better/differently? 1226953892 M * glen__ http://glen.alkohol.ee/pld/util-vserver-dbrebuild-internalize3.patch 1226954137 M * Bertl glen__: you really need to talk to daniel_hozac, I'm not maintaining util-vserver 1226954356 M * glen__ k 1226954828 J * larsivi ~larsivi@9.80-202-30.nextgentel.com 1226955944 M * bonbons Bertl, daniel_hozac: rawv6_bind() misses a check [net/ipv6/raw.c:237] -- unfortunately not easy to progress tg3 regularly goes mad on the box :( 1226956129 M * Bertl okay, should that fix the issues arekm was observing? 1226956148 M * Bertl don't we disallow raw binds? 1226956175 J * Darkglow ~pdesnoyer@208.71.184.41 1226956181 M * Bertl ah, no, that's ip raw 1226956298 M * Darkglow hi guys. I have an issue with my vservers...for a reason I have not found out yet, (I suspect hashify), when I do a lsof, I get processes with "(deleted) at the end... for example postfix, snmpd, atd. restarting them works for most of them( except postfix, because of the way the init is done) but this is annoying... any idea why ? 1226956323 M * Darkglow example of lsof output "/usr/sbin/snmpd;3bh05q (deleted)" 1226956348 M * Guy- you should generally restart vservers after hashifying them 1226956363 M * Guy- otherwise you lose the shared cache benefit 1226956409 M * Bertl yes, teh (deleted) can be considered 'normal' 1226956423 M * Bertl it basically means that the file is still open but gone 1226956450 M * Darkglow what I thought... related to hashify... link to file changed... so original file is "gone"... right ? 1226956469 M * Bertl probably, could as well be a package update in the guest 1226956493 M * Darkglow ah ... that's it. 1226956507 M * bonbons Bertl: for now just reading code, no testing/patching yet - need to get guests starting on the box for that second part... (but with "dazed NIC" it's not easy!) 1226956534 M * Bertl no problem, I guess arekm will help with testing 1226956555 M * Darkglow anyone has Debian, look at /etc/init.d/postfix if you run postfix... it checks for pid of master process and because of deleted, can't find it properly and fails to restart.. :( 1226956571 M * Darkglow ok, so after I upgrade packages, I should restart my vservers ? 1226956596 M * Guy- no, you should hashify first 1226956597 M * Bertl well, in theory, a package upgrade should do the RightThing(tm), but you are using debian :) 1226956624 M * Guy- as for the broken initscript, I suggest you switch to something that doesn't rely on pidfiles - such as runit :) 1226956642 A * arekm as "bad reminder" 1226956648 M * arekm any progress? 1226956667 M * Bertl well, bonbons found something, so we could try that out 1226956827 J * Aiken ~Aiken@ppp118-208-13-1.lns1.bne1.internode.on.net 1226956950 M * bonbons Bertl, arkem: looks like my hit is probable: http://pastebin.ca/1257941, lines 74, 213 (assuming I'm looking at the right strace :)) 1226957061 M * Guy- Darkglow: btw, even if the initscript can't find the postfix process, you can still kill it manually 1226957125 M * arekm bonbons: nice (that strace is right one) 1226957136 M * Darkglow yes I can... but the restart after auto-config changes (I use puppet to distribute my configs) does not work, I have to login every server and manually kill (or write a script, which is what i will have to do) 1226957172 M * bonbons arekm: also right lines? (e.g. bind() that should fail but does not) 1226957230 M * Guy- Darkglow: in such a setup, I think runit would really, really pay off 1226957243 Q * cga Quit: WeeChat 0.2.6 1226957244 M * arekm bonbons: 213 yes but 74? 1226957275 M * Darkglow never heard of it 1226957299 M * Guy- Darkglow: its service supervision/process management capabilities far exceed those of initscripts, and it's even simple (i.e. not bloatware) 1226957299 M * bonbons arekm: that's where the socket() got requested: raw socket 1226957314 M * Guy- Darkglow: apt-cache show runit then 1226957344 M * arekm bonbons: aha, I assumed that you are saying that 74 is doing something wrong 1226957348 M * Darkglow thanks for the tip, I will read about runit. Looks very intersting 1226957387 M * Guy- Darkglow: I never looked back :) 1226957388 M * arekm bonbons: bind() is the one problem. The other problem is that for outgoing connection (without any bind) wrong ipv6 source is used (not assigned to guest) 1226957407 M * arekm bonbons: (no strace for the other case) 1226957454 M * Bertl bonbons: the question is, shall we allow raw sockets at all (for ipv6)? 1226957461 M * bonbons arekm: for the bad source selection that reminds me some issue I've already seen a loong time ago 1226957478 M * arekm Bertl: don't disable mtr for me ;> 1226957510 M * Bertl well, I have no problem making that a flag if it can be done securely 1226957526 M * Bertl not sure it can, that's why I'm asking 1226957544 M * arekm it's not disabled for ipv4, too 1226957548 M * bonbons Bertl: isn't ping using raw sockets? 1226957550 M * arekm why ipv6 is "tricky" then? 1226957571 M * Bertl we disable raw sockets on ipv4, we enable icmp raw sockets for ping 1226957581 M * daniel_hozac we do the same for IPv6. 1226957594 M * bonbons so the matter is: bind must only allow available addresses, for non-bound usage of socket we must check that local address is an available one 1226957604 M * arekm exactly, the same happens for ipv6 so no isse there imo 1226957631 M * Bertl so why do we need checks for rawv6_bind()? 1226957707 M * daniel_hozac otherwise ping/other ICMP users don't get limited? 1226957756 M * Bertl okay, I don't see a check in raw_bind()? 1226957767 Q * Darkglow Remote host closed the connection 1226957835 M * daniel_hozac IPv4 is handled differently. 1226957843 M * daniel_hozac i assume ip_route_connect takes care of all users. 1226957865 M * glen__ um, do i have to have /.rpmdb on hosts for external pkg management, it seems if i remove that dir vrpm will start failing 1226958224 M * bonbons arekm: what does some simple call like ping6 do in your case: ping6 -n -c 2 -I

1226958264 A * arekm going to boot test machine 1226958950 Q * hparker Quit: Quit 1226959249 M * arekm bonbons: http://pld.pastebin.com/f4b20ca52 1226959361 M * bonbons arekm: looks very much the same as the other trace, and 2002:594c:1b49:1:211:d8ff:feb3:200 is your forbidden address I assume 1226959416 M * bonbons on my old kernel 2.6.22.19-vs2.2.0.7-ipv6-hrt6 that same bind gets rejected... so some check got lost since then! 1226959419 M * arekm bonbons: yes, it's other guest ip 1226959622 J * Mojo1978 ~Mojo1978@ip-88-152-50-100.unitymediagroup.de 1226959671 M * bonbons and back then there was a check in net/ipv6/raw.c, rawv6_bind() 1226960196 J * hparker ~hparker@2001:470:1f0f:32c:215:f2ff:fe60:79d4 1226960809 Q * Aiken Remote host closed the connection 1226960821 J * Aiken ~Aiken@ppp118-208-13-1.lns1.bne1.internode.on.net 1226961877 Q * ntrs_ Ping timeout: 480 seconds 1226961916 M * Bertl bonbons: could you upload the patch/chunk for that check? (no need to hurry) 1226961928 M * Bertl off to bed now .. have to get out early tomorrow 1226961938 N * Bertl Bertl_zZ 1226961940 M * bonbons Berlt: currently doing the changes for both issues... 1226961949 M * Bertl_zZ excellent, tx! 1226961975 M * bonbons once it've compile-checked my patch (and if I get the patch out of the box ;)) I will share it 1226961997 M * bonbons it will hopefully fix arekm's 2 issues 1226962423 Q * micah Quit: Lost terminal 1226962457 J * micah ~micah@micah.riseup.net 1226962486 Q * esa Ping timeout: 480 seconds 1226962487 J * esa ~esa@ip-87-238-2-45.static.adsl.cheapnet.it 1226962544 A * arekm sleeps 1226962810 Q * Pazzo Quit: Ex-Chat 1226963301 Q * pflanze Ping timeout: 480 seconds 1226963463 J * pflanze ~chris__@77-56-73-53.dclient.hispeed.ch 1226964238 J * ntrs_ ~ntrs@77.29.21.43 1226964306 Q * Aiken Remote host closed the connection 1226964760 M * bonbons arekm: try this patch: http://people.linux-vserver.org/~bonbons/vs2.3.0.35.10-ipv6-saddr-breakout-fix.diff 1226964803 Q * ntrs_ Ping timeout: 480 seconds 1226965886 Q * maddoc charon.oftc.net kinetic.oftc.net 1226965886 Q * transacid charon.oftc.net kinetic.oftc.net 1226965886 Q * Wonka charon.oftc.net kinetic.oftc.net 1226965886 Q * BobR_oO charon.oftc.net kinetic.oftc.net 1226965886 Q * cehteh charon.oftc.net kinetic.oftc.net 1226965886 Q * eyck charon.oftc.net kinetic.oftc.net 1226965886 Q * snooze charon.oftc.net kinetic.oftc.net 1226965887 J * snooze ~o@1-1-4-40a.gkp.gbg.bostream.se 1226965887 J * eyck BCdy9K7c@nat05.nowanet.pl 1226965887 J * Wonka produziert@chaos.in-kiel.de 1226965888 J * maddoc maddoc@social.ostruktur.com 1226965889 J * BobR_oO odie@IRC.13thfloor.at 1226965902 J * cehteh ~ct@pipapo.org 1226965907 J * transacid ~transacid@transacid.de