1104105653 M * Bertl tx Doener! 1104105665 M * Doener hu? 1104105674 M * Bertl (for the wiki entry ;) 1104105682 M * Doener ah, no problem ;) 1104105733 M * Bertl wht do you thing, can we get 1.9.4 out this year? 1104105780 M * Bertl +a 1104105890 M * Doener hope so 1104105928 M * Bertl yeah, looks good to me so far ... still a lot of work to do until 2.0 is ready ... but we are on the way ... 1104105931 M * Doener what's mandatory for 1.9.4 to be released (except testing ;) 1104105988 M * Bertl I'd like to see the maskcap stuff finished, but maybe I'm too optimistic 1104106081 M * Bertl especially as it means better non-root security 1104106133 M * Doener you said rs confirmed some basic stuff to be working, is that included in 1.9.3.14? 1104106169 M * Bertl yep 1104106315 M * Doener vx_mcaps? 1104106332 M * Bertl to make the mcap stuff complete there is one macro/inline missing (to test against a subcap) 1104106358 M * Bertl we can add that easily, I guess ... 1104106478 M * Bertl for example, take the VXC_RAW_ICMP 1104106497 M * Bertl we want to be that a subcapability of CAP_NET_RAW (for example) 1104106502 M * Doener VXC_CAP_MASK is subject to change i guess? 1104106506 M * Bertl yes 1104106511 M * Doener ok 1104106526 M * Bertl so we need a check (where now VXC_RAW_ICMP is checked) 1104106543 M * Bertl which verifies that a) VXC_RAW_ICMP is there, and b) CAP_NET_RAW is given 1104106565 M * Bertl we also need to add the CAP_NET_RAW to the VXC_CAP_MASK 1104106576 M * Bertl and provide CAP_NET_RAW to the vserver 1104106607 M * Bertl that is maybe the point where we should either wait or add a compile time option 1104106645 M * Bertl because every VXC we move into the mask, will become unreachable without the corresponding real capability 1104106689 M * Bertl btw, I thought about breaking out the subcap stuff and submitting that for mainline inclusion, as a way to extend the capability system ... 1104106774 M * Bertl if you consider that a good idea, we could work on something like that? 1104106848 M * Doener i wonder if they'd accept that... although i don't really know LSM i guess it allows similar things.. 1104106923 J * tanjix1 tanjix@pD9FAC44A.dip.t-dialin.net 1104107048 M * Bertl well, maybe extending the caps to 64bit would be sufficient 1104107269 N * sladen _ 1104107279 Q * tanjix Ping timeout: 480 seconds 1104107280 M * Bertl wow, cool nick ;) 1104107304 M * Bertl hey _ how are you? 1104107365 N * _ sladen 1104107406 M * sladen *grin* 1104107429 M * sladen almost tempted to keep it just to annoy the hell out of other people :-) 1104107442 M * Bertl yeah, how so? 1104107475 M * Bertl I'd say it might annoy the hell out of you (if your client beeps everytime somebody uses an underscore ;) 1104107522 M * ndim /nick ^G 1104107780 M * Bertl Doener: IMHO changing the cap system to 64 bit should be pretty easy ... 1104107833 M * Bertl at least I don't see any issues with atomicity ... 1104107848 M * Doener just change some structs and defines? 1104107855 M * Bertl and the userspace interface could use the lower 32 caps 1104107873 M * sladen we were just discussing punycode nicks on another channel 1104107896 M * Bertl punycode? 1104107909 M * Doener international domainnames... 1104107937 M * Doener like www.öäüß-suck.de 1104107957 M * Bertl ah, tx 1104107960 M * Doener those are converted to punycode, so that old dns servers etc. don't need to be chagend 1104107972 M * Doener s/chagend/changed/ 1104108044 M * Bertl hmm, sounds to me at least as useless as the international domain names themselves ... :/ 1104108063 M * Bertl (telling fro a short explanation I found on the web) 1104108067 M * Bertl +m 1104108196 M * Doener yes... AFAIK mail clients for example or not meant to support IDN, so for the example above, mails would go to someone@xn---suck-kqa8ayk4b.de ... easy to remember, right? 1104108205 M * Doener s/or/are/ 1104108291 M * Bertl well, that does Outlook(TM) for you it will then look like that somone@www.\246\247\248\249-suck.de ;) 1104108348 M * Doener pretty nice as well :-) 1104108356 M * Bertl okay, any other absolutely useless but funny to know inventions done recently? 1104108513 M * Doener hm, nothing i know of... 1104108535 A * Bertl is compiling with 64bit caps now ... 1104108802 M * Bertl the question now is, can we use that for linux-vserver? 1104109017 M * Doener i don't see a way that significantly differs from the mcaps approach... 1104109090 M * Doener of course we can now set the caps process-wise instead of context-wise, but i don't know any advantages we get by that... 1104109132 M * Bertl well, we could 'move' some combined caps into separate ones ... 1104109177 M * Doener wouldn't that possibly break some userspace apps? ot at least let them 'forget' to drop some caps? 1104109185 M * Bertl like CAP_NET_ADMIN or CAP_IPC_LOCK ... 1104109201 M * Bertl yeah, it probably would ... 1104109432 M * Doener is the openfd code still in place but commented out or removed? 1104109454 M * Bertl in place, commented out 1104109458 M * Doener ok 1104110423 M * Doener how does vx_openfd_task() work? 1104110446 M * Doener i don't understand the hweight_long() call... (i know what it does, but why is it used?) 1104110507 M * Bertl I'm not sure that makes sense at all, the idea was to get the number of already open fds for the current task (on migration) 1104110532 M * Bertl and hweight does return the number of bits set 1104110557 Q * tanjix1 Quit: 1104110580 M * Doener ah, now i see... fds_bits is a mask that holds information about the used fds, right? 1104110590 M * Bertl yes, so I see it ... 1104110597 M * Doener what about count_open_files()? 1104110607 M * Doener in kernel/fork.c 1104110670 M * Bertl IIRC I got the impression that this doesn't account for the 'holes' properly .. (maybe I was wrong there) 1104111380 M * Bertl btw, the quad PIII is running killer and network tests on vs1.9.3.11 for more than 3 days now ... 1104111431 M * dominance Bertl: ok, TODO list is sent to Enrico 1104111442 M * dominance Bertl: let's hope we didn't scare him with the long list *ggg* 1104111473 M * dominance Bertl: if you want to comment yourself on stuff like the klogd not being able to be run from inside a vserver, all input is welcome =) 1104111477 M * Bertl dominance: if you like, I added a ToDo wiki page for the tools ... 1104111510 M * dominance hmm, so far we use SVN for the deb preparations =) 1104111514 M * dominance and that does include the TODO 1104111516 M * dominance but thanks! ;) 1104111538 M * Bertl nothing to thank ... SVN is fine ;) 1104111558 M * Bertl ad klogd, that isn't really tool related, is it? 1104111577 M * dominance mmh, why can't we have it attach to the vserver's xid kernel messages? 1104111595 M * dominance wouldn't you want to see your kernel messages you provoked from inside a vserver? 1104111608 M * dominance given that maybe some webhoster is selling you a vserver as hosting? 1104111648 M * dominance but well.. you have our list.. now we can start discussing.. 1104111668 M * Bertl I have it? 1104111672 M * dominance that's only what we understand so far.. maybe there'll be more to talk about once we seriously know what matter we're talking about 1104111676 M * dominance yep.. it's on the ml 1104111681 M * dominance but you can also have it here: 1104111690 M * dominance http://backend.verfaction.de/~kk/util-vserver/TODO 1104111700 M * Bertl ah, found it ... 1104111710 M * dominance which i actually referenced for the size =) 1104111718 M * Doener regarding basic/highlevel stuff, we only have a) and b)I) 1104111736 M * Doener rebootmgr has been obsoleted by vshelper 1104111737 M * Bertl dominance: should I comment here or on the ml too? 1104111751 M * dominance Bertl: only on the ML or on some place to read for ndim too 1104111764 M * dominance something archived maybe *g* 1104111777 M * ndim This here is archived. 1104111779 M * Bertl well, this channel is logged ;) 1104111785 M * dominance yup, i know.. 1104111792 M * dominance not that i very much agree with channel logging.. 1104111800 M * dominance but i had just found a quote of mine in google from here 1104111856 M * Doener converting a chroot to a vserver can be done with: vserver somename build -m skeleton ; cp -a /path/to/chroot /path/to/skel 1104111920 M * Doener ok, this is all i can comment ad hoc ;) 1104111933 Q * nox Quit: I shouldn't really be here - dircproxy 1.0.5 1104112135 M * dominance Doener: i was rather interested of doing that *WITHOUT* moving the chroot aside.. 1104112154 M * dominance Doener: i.e. just "hook the chroot up to the vserver" 1104112285 M * dominance so the idea can't be very far to just have the "skeleton" instead of "complaining there is already a chroot" peruse the existing chroot and check its tools before adding them as valid chroot 1104112479 M * dominance Bertl: i forgot to say.. the full list of files in the deb is in the buildlog 1104112503 M * dominance Bertl: so if anyone wants to discuss which files are needed and need to go there, that'd be a good list to start from =) 1104112507 M * Bertl okay, you got my answer for now ... we'll see what enrico adds ... 1104112533 M * Bertl (probably I missed most of the important questions ;) 1104112546 M * dominance hrmpf.. i read MLs... no need to CC me.. 1104112583 M * Bertl then fix your mua, lkml standards apply to this specific ml too ;) 1104112600 M * dominance my MUA didn't request a reply-to 1104112613 M * dominance the reply-to was *ONLY* to the list.. 1104112620 M * dominance either way reply-to for a ml is broken 1104112636 M * dominance but that's something else which people don't understand.. 1104112658 M * dominance thus i wouldn't know what my MUA needs to be fixed.. but i'm all ears.. 1104112737 M * Bertl hmm, .. good point ... 1104113002 M * Bertl http://larve.net/people/hugo/2000/07/ml-mutt 1104113101 M * Bertl I'm not seeing that I do something wrong either (by hitting 'g' for group-reply in mutt) 1104113218 M * Bertl but maybe you can tell me here ... 1104113251 M * dominance it's not GROUP you should reply to but LIST =) 1104113260 M * dominance and that's not g but l or L 1104113266 M * Bertl but LIST is not what I want! 1104113279 M * dominance why not? 1104113290 M * dominance then just reply to the reply-to 1104113294 M * dominance by hitting r 1104113301 M * dominance that's what the ml does set it for 1104113306 M * dominance (even if that's broken) 1104113318 M * dominance list reply is L 1104113325 M * dominance just in case someone needs it 1104113345 M * dominance and that'd be the RFC-conforming version to go without Reply-To 1104113401 M * Bertl no, I want to reach all receipients of that mail (as is default on lkml) 1104113431 M * dominance that's the group reply.. but that's CCing me.. and i'm already receiving it thru the list 1104113440 M * Bertl without removing any cc or so .. because we never know who is subscribed and who is not 1104113450 M * dominance thus if you have a list setting the reply-to.. then you'd want a plain "reply" via "r" 1104113462 M * dominance for if i'd want CC then i'd set my reply-to and the list would append to it 1104113469 M * Bertl so I don't see a way to check that on my end? 1104113476 M * dominance nope, there's not 1104113491 M * dominance at least i wouldn't know how to "CC all on CC" but not include the sender 1104113491 M * Bertl but there is on your side, via procmail for example ... 1104113503 M * dominance which i do already *ggg* 1104113512 M * Bertl so why do you waste my time then? 1104113523 M * dominance yet my direct MX link is in 99.99% of all cases getting the mails BEFORE i receive them thru the ml 1104113532 M * dominance which does sort them into my private mail folder 1104113536 M * dominance and that is *BROKEN* 1104113549 M * dominance for it does belong into the ml folder with an X-List-Id header 1104113570 M * dominance or X-BeenThere and what all there exists.. 1104113622 M * dominance maybe lkml has a fancy way of adding a reply-to if the sender or one in CC is not on the list.. 1104113642 M * dominance yet if your ml-soft doesn't have that, then there's no way to have your reply-to point to "all not on the list plus the list itself".. 1104113653 M * dominance you might want to file that as a bug against mailman though :-P 1104113661 M * Bertl okay, let's move to something more productive ;) 1104113670 M * Bertl Schak: you are still here? 1104113700 M * Doener Bertl: vx_openfd_task vs. vx_nofiles_task... is that just a name change or what? 1104113738 M * Bertl basically yes, but it probably needs a separate implementation 1104113747 M * Bertl (i.e. it is probably wrong) 1104113762 M * Doener ok, so different purpose, but currently same code... 1104113784 M * Bertl yep, basically both should return the appropriate count for the given task 1104113801 M * Doener nofiles is? 1104113837 M * Bertl at least no error messages showed up recently 1104113850 M * Bertl (when leaving a context the values are reported, IIRC) 1104113921 M * Bertl kernel/vserver/limit_init.h 1104113928 M * Bertl vx_info_exit_limit() 1104114064 M * dominance alright.. going 2bed guys.. 1104114077 M * Bertl night dominance! and thanks for your time! 1104114079 M * dominance cu l8r =) 1104114096 M * dominance Bertl: i'd love to see the deb updated.. as i had already said at last linuxtag 1104114110 M * dominance Bertl: and if that means we gotta do that ourself, then that's what we do =) 1104114111 M * Bertl I hope we are getting there ... 1104114126 M * dominance once we have a ready-to-be-rolled-out deb, that's piece of cake 1104114149 M * Bertl k, let's keep working on it ... 1104114159 M * dominance but there is some design which needs to become packaing-ready which currently is a bit of un-intuitive.. 1104114163 M * dominance sure.. 1104114169 M * dominance cu l8r =) 1104114285 M * Bertl Doener: all kinds of shell pipes will trigger errors in accounting like: 1104114305 M * Bertl ls | chcontext --ctx 100 wc 1104114314 M * Bertl chcontext --ctx 100 ls | wc 1104114333 M * Bertl chcontext --ctx 100 wc /dev/null 1104114344 M * Doener with "nofiles is" i meant "what is nofiles for?" not "does nofiles really work?" ;) 1104114367 M * Bertl aah, okay, nofiles is number of files ;) 1104114367 Q * sannes Read error: Connection reset by peer 1104114369 Q * dsanta Ping timeout: 480 seconds 1104114385 M * Bertl and means the struct file handles ... 1104114461 M * Doener ah... i read it as 'no files' *g* 1104114592 M * Bertl no files anymore! ;) 1104114642 M * Bertl actually I wanted to use nrfiles but the no for number of was already used for the processes IIRC 1104114793 J * dsanta ~santa@c68.190.156.105.roc.mn.charter.com 1104114798 M * Bertl wb dsanta! 1104115477 J * Schak2 schak@dsl-213-023-243-081.arcor-ip.net 1104115621 Q * Schak Ping timeout: 481 seconds 1104116438 M * Doener i'm off to bed... night! 1104116443 N * Doener Doener_zZz 1104116468 M * Bertl night! 1104120625 Q * Schak2 Read error: No route to host 1104121501 J * sannes ~ace@home.skarby.no 1104121964 Q * tchan Quit: Lost terminal 1104123293 M * Bertl night folks! 1104123302 N * Bertl Bertl_zZ 1104130974 Q * _are_ Quit: Disconnecting 1104132725 Q * serving Ping timeout: 480 seconds 1104135913 J * _are_ ~are@mail.foehl.de 1104135918 M * _are_ hi 1104136132 J * rs rs@ice.aspic.com 1104136139 M * rs hi folks 1104136866 Q * t_ Ping timeout: 480 seconds 1104136885 J * t_ ~tnichols@CPE-139-168-209-155.sa.bigpond.net.au 1104139449 J * serving ~serving@213.186.189.201 1104140194 M * Val Hi 1104141958 M * Val why a bind9 server doesn't start properly when vserver start or restart but starts fine when entering this vserver and calling /etc/init.d/bind9 (start|restart) as root (which launch bind9 under 'bind' user) ? 1104141985 M * _are_ don't know the exact reason, but it is somewhere in the faq 1104142004 M * Val yes i looked that 1104142055 M * Val but is there a difference in calling init script automaticaly or manualy ? 1104142077 M * _are_ theoretically: no 1104142080 M * Val :) 1104142091 M * _are_ practically: other environment variables might beset 1104142101 M * Val may be 1104142115 M * _are_ you might have changed context / might *not* have changed context and similar stuff 1104142425 M * Val when i call 'vserver restart' i got 'localhost named[...]: could not listen on UDP socket: permission denied' and then bind9 refuse to listen domain ports. When i enter in the then call init.d bind9 script as root i don't see the error message and bind9 starts fine 1104142762 M * Val ok, adding CAP_SYS_RESOURCE solve bind9 start|restart problem 1104142771 M * _are_ :-) 1104142771 M * Val shame on ISC 1104142814 M * Val going to make a new bind9 debian package without this stupid compilation flag 1104142833 M * Val ...paul's one is to old 1104144428 M * sladen valid point 1104144491 J * Schak schak@dsl-082-082-156-253.arcor-ip.net 1104144506 M * Val :) 1104145721 M * Val http://vallar.linuxfr.org/debian/bind9-9.3.0-1.nocaps/ 1104147679 M * ndim Good "morning" everyone :) 1104149500 Q * grecea Remote host closed the connection 1104149631 J * grecea ~grecea@h-195-22-237-74.mdl.net 1104152341 J * tanjix tanjix@pD9FAC452.dip.t-dialin.net 1104152345 M * tanjix hi together 1104152921 M * Val Ola Lundqvist, kernel-patch-ctx debian maintainer, ask if quota patch for 2.4.X (q0.14) is stable enough to replace the normal ctx patch ? 1104152935 M * Val i think it is :) 1104152946 M * Val but is it realy ? 1104154238 J * mcp ~hightower@81.17.110.148 1104154404 J * Duckx ~duckx@195.75.27.158 1104155085 Q * Zoiah Ping timeout: 480 seconds 1104155117 M * Snow-Man erm, what's the graphviz stuff? 1104155514 M * ndim It lays outs graphs into graphical form. 1104155534 M * ndim It is used by doxygen while generating API docs. 1104155543 M * Snow-Man oh, pah. 1104155551 M * Snow-Man doxygen should use something free. 1104155552 M * Snow-Man :) 1104155558 M * ndim There is no such thing. 1104155570 M * Snow-Man bah. 1104157036 J * AnGeL4U` Angel@Cable-83-202.TopAllNET.Ro 1104157059 M * AnGeL4U` hi 1104157059 M * AnGeL4U` anyone online here? 1104157064 M * _are_ yes 1104157081 M * AnGeL4U` hi sir 1104157091 M * AnGeL4U` i wish more infos about the vserver project 1104157106 M * AnGeL4U` i can make that in my linux home? 1104157165 M * _are_ i guess so. i have all my info from http://www.linux-vserver.org/ 1104157177 M * _are_ you should be able to run it on your home box, as well 1104157179 M * AnGeL4U` yes sir i see 1104157187 M * AnGeL4U` but i wish anyone help me 1104157200 M * _are_ as in? 1104157255 M * AnGeL4U` example 1104157256 M * AnGeL4U` i have Fedora core 3 1104157279 M * AnGeL4U` is good the patch for kernel 2.6.9-1.667 1104157279 M * AnGeL4U` ? 1104157288 M * AnGeL4U` or need to change the kernel version? 1104157303 M * AnGeL4U` ah i see 1104157304 M * AnGeL4U` patch-2.4.28-vs1.29.diff 1104157311 M * AnGeL4U` need kernel 2.4.28 1104157314 M * AnGeL4U` right? 1104157329 M * _are_ uhm, no idea, the most recent development patch is for 2.6.10, if you try and apply it elsewhere, you might run into conflicts 1104157348 M * AnGeL4U` yes 1104157356 M * AnGeL4U` i will change kernel version 1104157363 M * _are_ depending on your knowledge, you might be able to resolve them. to my knowledge there are no premade patcheds for specific distribution kernels 1104157394 M * AnGeL4U` i will put 2.4.28 1104157401 M * AnGeL4U` is ok this kernel for vservers? 1104157435 M * _are_ no idea, my experience is with developemnt kenrels and kernel 2.6 only, as i run opterons and 2.4 opteron support is not that amazing 1104157460 M * AnGeL4U` aha 1104157461 M * AnGeL4U` so ... 1104157474 M * AnGeL4U` the vserver patch running in 2.6.& versions? 1104157496 M * _are_ yes, 2.4 and 2.6 1104157511 M * _are_ there is a stable patch (1.29) for both, afaik 1104157533 M * AnGeL4U` this ? 1104157534 M * AnGeL4U` patch-2.4.28-vs1.29.diff 1104157585 M * _are_ yes 1104157629 M * AnGeL4U` ok 1104157634 J * Niddle ~toto@62-197-114-54.teledisnet.be 1104157642 M * Niddle hello all 1104157647 M * _are_ Hi Niddle 1104157655 M * AnGeL4U` nned some scripts for make the virtual machine? 1104157667 M * Niddle no, help :) 1104157690 M * Niddle winnie:~# vserver yagonas start 1104157691 M * Niddle Starting the virtual server yagonas 1104157691 M * Niddle Server yagonas is not running 1104157691 M * Niddle Can't set the ipv4 root (Function not implemented) 1104157696 M * _are_ the util-vserver package should provide what you need 1104157699 M * Niddle idon't know why 1104157716 M * Niddle i triedto search on google, but could not find anythingreally relevant 1104157727 M * _are_ Niddle: you created the interfaces in advance? 1104157746 M * Niddle no, i migrated them from another system 1104157753 M * Niddle ii util-vserver 0.30-8 tools for Virtual private servers and contex 1104157756 M * Niddle they are installed 1104157765 M * Niddle yes 1104157767 M * Niddle interfaces 1104157776 M * Niddle thank you for the tip :p 1104158245 M * _are_ did the trick? 1104158679 M * Niddle no, unfortunately not 1104158729 M * AnGeL4U` Niddle u use graphic interface for vservers? 1104158751 M * Niddle AnGeL4U`, no, only command line 1104158766 M * AnGeL4U` aha 1104158774 M * AnGeL4U` ok 1104159470 N * Doener_zZz Doener 1104159521 M * Doener Val: which kernel and tools? is fakeinit enabled for that vserver? 1104159938 M * Val Doener : 2.4.27-vs1.29-q0.14 util 0.30, fakeinit enabled 1104160017 M * Doener Val: please enter the vserver and do "grep Cap /proc/self/status" 1104160255 M * Val CapInh: 0000000000000000 1104160255 M * Val CapPrm: 00000000fffffeff 1104160255 M * Val CapEff: 00000000fffffeff 1104160255 M * Val CapBset: 00000000fffffeff 1104160347 M * Doener yeah, thought so... 1104160534 M * Doener when you enter the vserver you don't lose your caps... that means your bind daemon was running with full caps, and so the start suceeded 1104160563 M * Val ok 1104160565 M * Val well 1104160656 M * Doener around line 702 in the vserver script, there's "case $f in"... add an empty case for fakeinit there to 'fix' that... 1104160675 M * Val hum 1104160681 M * Val ok 1104160757 M * Val around line 702 ? 1104160845 M * Val seems we don't have the same vserver script 1104160906 M * Doener hm, didn't think that changed too much from 0.29 ;) 1104160917 M * Val :) 1104160940 M * Val yep, but i found lots of "case $f in" in the script :) 1104160978 M * Doener hm, i just downloaded 0.30... it's line 701 there... 702 is "minit)" 1104160997 M * Val ouch 1104161002 M * Doener case $f in 1104161002 M * Doener minit) 1104161017 M * Val debian one is not a real "0.30" so 1104161029 M * Doener make that: 1104161030 M * Doener case $f in 1104161030 M * Doener fakeinit) 1104161030 M * Doener ;; 1104161030 M * Doener minit) 1104161037 M * Val ok 1104161074 M * Doener that's the first "case..." after "elif [ "$2" = "suexec" ] ; then" 1104161082 M * Val yep, founded 1104161091 M * Doener the second... 1104161341 M * Val trying with bind9-with-caps-enabled ... 1104161377 M * Val works ! 1104161384 M * Val Doener : thanks :) 1104161390 M * Doener "works" means "bind does not start"? 1104161398 M * Val bind does 1104161436 M * Val nice trick 1104161457 M * Doener hm... with that fix (and without CAP_SYS_RESOURCE) bind shouldn't start... 1104161475 M * Doener default bind9 that is... 1104161476 M * Val but is does 1104161482 M * Val iT 1104161507 M * Doener on "vserver ... start" or with "vserver ... enter"? 1104161526 M * Val on 'vserver ... start' now 1104161538 M * Doener hu? we didn't even touch that one... 1104161541 M * Val before only on 'vserver ... enter' 1104161572 M * Doener please enter the vserver and do "grep Cap /proc/self/status" again... 1104161584 M * Val CapInh: 0000000000000000 1104161584 M * Val CapPrm: 00000000d40c24ff 1104161584 M * Val CapEff: 00000000d40c24ff 1104161584 M * Val CapBset: 00000000d40c24ff 1104161704 M * Val S_FLAGS="lock sched nproc fakeinit" 1104161714 M * Doener what about caps? 1104161719 M * Val S_CAPS="CAP_NET_RAW" 1104161725 M * Val :-/ 1104161736 M * Doener strange... sec... 1104161891 Q * tanjix Ping timeout: 480 seconds 1104161923 M * Doener Val: please lookup bind's pid and do "grep Cap /proc//status 1104162054 M * Val CapInh: 0000000000000000 1104162055 M * Val CapPrm: 00000000d40c24ff 1104162055 M * Val CapEff: 00000000d40c24ff 1104162055 M * Val CapBset: 00000000d40c24ff 1104162060 M * Val for all named process 1104162062 M * Val es 1104162111 M * Val oops 1104162138 M * Val i removed '-u bind' param ... 1104162164 M * Val with '-u bind' named doesn't start properly 1104162172 M * Val localhost named[11695]: could not listen on UDP socket: permission denied 1104162191 M * Doener ah, ok... 1104162249 M * Val even if using init.d script inside vhost 1104162356 M * Val so patch on vserver script doesn't do anything ? 1104162386 M * Doener notice the difference in the Caps? 1104162411 M * Val yep 1104162425 M * Val there is a difference 1104162454 M * Val ...let's retry with nocaps bind9 1104162464 M * Doener before the fix you had full caps... if you had tried to shutdown your complete network, it would have suceeded 1104162761 M * Val the main problem with bind9.nocaps running inside a vserver is that running user is root..; 1104163682 M * Doener Val: could you strace the failing process? 1104163952 M * Val --disable-caps remove '-u ' flag support for daemon command line 1104164085 M * Val "On Linux, named uses the kernel's capability mechanism to drop all root privileges except the ability to bind() to a privileged port and set process resource limits. Unfortunately, this means that the -u option only works when named is run on kernel 2.2.18 or later, since previous kernels did not allow privileges to be retained after setuid()." 1104164154 M * Val 'm gonna use djbdns :p 1104164165 M * infowolfe val, good idea ;-) 1104164172 M * Val shame on isc 1104164179 M * infowolfe val, http://www.djbdnsrocks.org ;-) 1104164187 M * Val :) 1104164191 M * infowolfe val, i use djbdns, it's quite fast 1104164203 M * Val it runs well inside a vserver ? 1104164221 M * infowolfe Val, of course it does... so does qmail 1104164247 M * Val ok, let's kick out isc shit 1104164340 M * infowolfe Val, you should go to that site, the vegadns php djbdns admin stuff is pretty sweet in my book 1104165791 J * tchan ~tchan@c-24-13-81-164.client.comcast.net 1104167539 Q * rs Quit: home 1104168106 M * Val grumpf, djbdns does not work as a forwarder 1104168122 M * Val i'm too tired ... 1104168135 M * _are_ dnsmasq works to some extend 1104168356 Q * _are_ Quit: Disconnecting 1104168492 Q * Val Quit: zZz 1104168721 J * Zoiah Zoiah@matryoshka.zoiah.net 1104169121 Q * Duckx Remote host closed the connection 1104169198 N * Bertl_zZ Bertl 1104169222 M * Bertl morning folks! 1104169953 M * dominance hi Bertl =) 1104169964 M * dominance Bertl: looks like we unleashed a good discussion =) 1104169976 M * Snow-Man Bertl: heya. 1104169993 M * dominance hey snow-man.. 1104170009 M * Snow-Man dominance: heya. 1104170010 M * dominance snow-man: you are sure you don't even want to peek at my debs before commenting? 1104170031 M * Snow-Man dominance: What fun would that be? :) 1104170048 M * dominance good fun.. for you could comment straight into my debian/rules*gg* 1104170059 M * Snow-Man I looked through your TODO list and was commenting on things from there.. 1104170075 M * dominance your list of dirs is fine.. now someone needs to sort out which files is where and if it's correct there. =) 1104170079 M * Snow-Man dominance: My comments there would probably be something like 'uh, CDBS.' 1104170096 M * dominance hehe, that would indeed be a very funny comment =) 1104170102 M * Snow-Man Yes, it'd be nice if upstream would take care of installing things into the right places... :) 1104170108 M * dominance (especially since i don't do CDBS *g*) 1104170120 M * Snow-Man Well, CDBS wouldn't help with that part anyway. 1104170125 M * dominance right 1104170139 M * Doener Bertl: fyi http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2004-12/0390.html 1104170143 M * dominance and i like to have the ultimate control at my fingertips... 1104170328 M * Snow-Man Wow, good reason to load modules as the first thing when you boot before you start any other processes. :) 1104170338 M * Snow-Man Or just compile that stuff in, like I tend to do. 1104170348 M * Bertl hey somebody figured it out? ;) 1104170398 M * Bertl dominance: yes, as usual: talking get's folks together and gives new perspectives ... 1104170446 M * dominance Bertl: hehe, sure.. That's why we do this =) 1104170469 M * dominance and once we have all agreed we can propose a "debian-free and policy-clean" deb to ola.. 1104170481 M * dominance who'll be delighted to not have had the work with it 1104170483 M * dominance :-P 1104170590 M * Doener dominance: Snow-Man is right about the /var/lib stuff. fhs states that it should contain variable state information... 1104170607 M * Doener http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA 1104170615 M * Doener http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION 1104170619 M * dominance Doener: yep.. just someone needs to sort the files and tag them to the dirs.. 1104170633 M * dominance once this is checked and verified they are ok in that place, i have no problem with that.. 1104170690 M * Bertl ad library: as I already stated, I'd appreciate a devel package to be available for other tools (if done properly even for hack/test tools in the future) 1104170726 M * Bertl but that is something up to enrico (to make it usable) 1104170834 M * dominance but then we have to split out the lib and frost is right that the SONAME needs to be fixed for that to happen 1104170860 M * dominance and the fact that it's available from upstream does already offer hacking to happen.. 1104170892 M * dominance so i'm not sure that's really required "NOW()" on a packaging level.. yet i agree it's nothin special to accomplish, so that's no blocker anyway.. 1104170987 M * Bertl I'm fine when it isn't included now, but we should try to address this anyway, so now would be as good as anytime ... and the sooner it is done, the more devels might consider this interface, instead of coding their own stuff ... 1104171032 M * Bertl after all it should become something like the linux-vserver-glibc 1104171056 M * dominance sure 1104171728 P * Niddle Leaving 1104173187 Q * AnGeL4U` Quit: 1104173495 Q * serving Ping timeout: 480 seconds 1104175117 J * _are_ ~are@dsl-213-023-051-086.arcor-ip.net 1104175158 M * Bertl welcome _are_ 1104175238 M * Snow-Man Bertl: Don't forget- symbol versioning is good. :) 1104175296 M * Bertl huh? 1104175330 M * Snow-Man For the library. 1104175362 M * Bertl ah, well, don#t tell me, kernel uses versioned structures and syscall commands ... 1104175378 M * Snow-Man That's good. 1104176104 Q * DuckMaster Remote host closed the connection 1104176582 Q * Schak Ping timeout: 480 seconds 1104176786 M * dominance Snow-Man: you gotta tell ensc, not Bertl.. =) 1104176926 M * Snow-Man ok, ok.. :) 1104177092 M * _are_ hi 1104178114 J * duckx ~Duck@dyn-83-157-168-176.ppp.tiscali.fr 1104178125 M * Bertl welcome duckx! 1104178128 M * duckx yop 1104178149 M * duckx Merry christmas 9) 1104178175 M * duckx We had last week a network outage ... 1104178184 M * duckx Fiew services down ... 1104178206 M * duckx But ... the vservers are now back :) 1104178219 M * duckx thx :) 1104178281 M * duckx Hey ... 1104178287 M * duckx What this ng8.7 1104178296 M * duckx I muss have miss something right ? 1104178396 M * duckx 2.6.10 running like a charm ... 1104178451 M * Bertl the nget stuff is testing for the next generation networking 1104178460 M * Bertl not suited for production, but for testing ... 1104178469 M * duckx Ala VMware ? 1104178484 M * dominance ngnet can do ipv6 =) 1104178490 M * duckx lol 8) 1104178495 M * dominance in case u use that ;) 1104178510 M * duckx Not yet 8) 1104178528 A * dominance would also love to see the ipv6 in main vserver soon *ggg* 1104178556 A * duckx is charming its pc to make it run udev ... 1104178587 M * Bertl duckx: well, yes you have virtual interface in ngnet 1104178800 M * duckx Vlan support ? 1104178821 M * Bertl once it's finished, yes I'd say so ... 1104178834 M * duckx Cool :) 1104178851 M * duckx Well as far as we use it ... 1104178856 M * duckx We are pretty impressed ... 1104178863 M * duckx Running like a charm ... 1104179055 M * Bertl good to hear, you are selling vds to customers? 1104179072 M * Bertl (or what is your usage pattern for linux-vserver?) 1104179102 A * Bertl is always curious to know what the various applications for linux-vserver stuff are 1104179437 M * ndim duckx: Are you running vanilla kernel + vserver or additional patches? And what are your host and guest systems? 1104179881 M * duckx We got a bi Pentium III 1104179891 M * duckx With 2Gbits of ram .. 1104179909 M * duckx We are currently running 6 vservers .. 1104180048 M * Bertl duckx: 2Gyte I hope, using 2/2 split? 1104180060 M * Bertl s/2Gyte/2GByte/ 1104180075 M * duckx lol sure 1104180084 M * duckx Um 2/2 split right 1104180127 M * Bertl and disabled highmem? or highmem still active? 1104180135 M * duckx No highmem 1104180221 J * serving ~serving@213.186.188.15 1104180375 M * Snow-Man Does highmem cause a problem w/ vserver? 1104180384 M * duckx Don't know 1104180390 M * Bertl no, it's just a lot slower than lowmem 1104180393 M * Snow-Man erm, am I thinking highmem is something else? 1104180407 M * Snow-Man I always thought of highmem as what you need to get >960M or so 1104180413 M * Snow-Man Accessible by Linux anyway 1104180426 M * Bertl that is what kernel folks want to make you believe ... 1104180426 M * duckx But yes ... 1104180433 M * duckx I remember some trouble 1104180441 M * Snow-Man Bertl: errr... 1104180453 M * Bertl the thing is, the x86 arch allows for 4GB address space 1104180480 M * Bertl the linux kernel (and other kernels) separate the space into kernel and userspace 1104180499 M * Snow-Man Memory: 8108408k/8388608k available (1791k kernel code, 0k reserved, 959k data, 172k init) 1104180514 M * Bertl the default split is 1/3 which means you get 1GB kernel space and 3GB userspace 1104180552 M * Snow-Man It's an amd64 box tho, if that makes a difference. :) 1104180584 M * duckx Running 64bits ? 1104180589 M * Snow-Man yup. 1104180590 M * Bertl well, depends on the setup ... x86_64 has a larger address space 1104180597 M * Snow-Man Linux elros 2.6.9-9-amd64-k8-smp #1 SMP Wed Nov 10 16:46:48 CET 2004 x86_64 GNU/Linux 1104180605 M * Bertl if running in 32bit mode you will face the same issues 1104180608 M * duckx Rocks babe 8) 1104180619 M * Snow-Man duckx: Yeah, it's a nice box. :) 1104180623 M * Bertl so usually you get a little below that 1GB space for the ekrnel 1104180628 M * Snow-Man We've got two of them, plus a bunch of smaller ones. :) 1104180656 M * Bertl which results in the rest of the memory being unaccessable, unless you use additional mapping (highmem) 1104180696 M * Snow-Man Bertl: So what you're saying is that I should probably stay in 64bit mode. :) 1104180776 M * ndim In former days, "high memory area" was the memory above 2^20 which could still be addressed using the (2^16 * 4) + 2^16 segmented addresses... 1104180779 M * ndim :) 1104180780 M * Bertl well, I added some config options to allow to adjust the split thingy for linux-vserver kernels 1104180820 M * Bertl so you can choose to do 2/2 splits which allow you to utilize almost 2GB without the highmem mapping ... 1104181029 M * Bertl some things (kernel buffers and such) can not use highmem so they will use up the lowmem, which in turn, might cause issues ... 1104181422 M * _are_ Bertl: as an intermediate status: 2.6.10-vs1.9.3.14 seems to be quite ore stable than 2.6.10-rc3-vs1.9.11/12 on dual opteron. There is some real load on the box now like nfs-user-server, samba server, cyrus imapd, ... 1104181422 M * _are_ postfix/amavis/clamd and to have some extra fun a make -j bzImage (spawned ~360 processes on main server) 1104181462 M * Bertl sounds good, yes a few fixes got into 2.6.10 (not sure they are x86_64 related ...) 1104181506 M * _are_ well, smp fixes are there as well. Imanaged and hgave a system that collects all weaknesses in linux kernel at once ;) 1104181535 M * Bertl excellent for testing ;) 1104181565 M * _are_ yes, unfortunately the owner of the machine is forced to juse it in production :-> 1104181586 M * Bertl even better testing ground ;) 1104181586 M * _are_ (ok, extended testing ;) 1104181642 M * Bertl but for your information, I have a quad PIII machine running stress tests since almost 4 days now (linux-vserver specific stress tests) 1104181671 M * Bertl and it's running fine ... 1104181728 M * Bertl although I'm pretty sure we are not perfect (yet) 1104181993 M * _are_ well, I noticed I seem to run into bugs noone else complained about before ;) 1104182059 M * _are_ atm it is a pure64 system, tomorrow or wednesday there will be a few 32bit vservers running, too (oracle db, virus scanner, backup application) 1104182681 M * Bertl okay, I'm off to bed now ... good night everyone! 1104182687 M * _are_ nn Bertl 1104182697 N * Bertl Bertl_zZ 1104183262 M * duckx bye 1104184773 M * ndim What the heck is list@daffy.hulpsystems.net ? 1104184792 M * ndim X-Mailer: ispworks-spammgr 0.8 1104184798 M * ndim Not really? 1104185049 A * ndim reads up on failed attempts to control spam 1104185217 M * ndim I kind of wonder why my mails haven't gone through to the ML yet? 1104185397 M * ndim Oh. 1104185466 M * ndim OK, so that stuff is legitimate. 1104186389 Q * pizdec Quit: Client exiting 1104186498 J * DuckMaster ~Duck@dyn-83-157-159-223.ppp.tiscali.fr 1104186822 M * dominance ndim? 1104186833 M * ndim Yes, darling? 1104186865 M * ndim Oh. 2.6.10-vs1.9.4.14-ndim has finished building. 1104186929 Q * duckx Ping timeout: 480 seconds 1104186987 M * dominance ndim: cute.. 1104186998 M * dominance ndim: so what's that list@daffy? 1104187021 M * ndim I got four mails from there. One for each of my mails from the list. 1104187063 M * ndim Checking the MX for lists.linux-vserver.org results in a surprise, however: These are really mails from the listserver. :) 1104187133 M * dominance yes, daffy is the ml host.. 1104187142 M * dominance but why can't you send? 1104187266 M * ndim Because had not sent yet. 1104187799 M * ndim ARGH. I have built the wrong kernel because I mistakenly changed to the wrong directory. 1104187853 M * ndim Hmm. No. I built the right one but installed the wrong one... 1104187876 M * ndim I think I should do any more stuff as root tonight. 1104188723 M * dominance _not_ ;) 1104188729 M * dominance don't drink and root :-P 1104189007 M * ndim Well, ... I love 2.6.10. 1104189017 M * ndim I haven't seen such a broken kernel since a long time. 1104189026 M * ndim OK, maybe it was the vserver patch... 1104189046 M * ndim It started oopsing in event/0 1104189063 M * ndim Then it got around to oopsing in a few other processes. 1104189078 M * ndim It stopped oopsing with nautilus, and then resorted to a kernel panic. 1104189142 M * dominance for me 2.6.10 is just running smoothly.. 1104189220 M * ndim Well, this is a laptop with laptop-mode and other stuff. 1104189235 M * ndim I think I'm going to try a 2.6.10 without the vserver patch now. 1104189559 M * dominance ok 1104189568 M * dominance mmh, maybe i should also reboot my laptop into 2.6.10 1104190139 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de 1104190489 J * mikeb ~baptiste@64-40-83-12.dsl.mebtel.net 1104190812 M * mikeb Happy Holidays all. I've been working to setup vserver on a new Dual Opteron FC2 box all day and seem to have hit a snag I can't get out of. I'm running 2.6.9 with 1.9.3.14 and util-vserver 1.3.195 (196 would not compile due to 'nice') I'm creating a skeleton vserver (apt-get an x86_64 not happening) I used yum to install a minimal fc2 set of rpms which worked great (via --install-root) But when I try to start the vserver, chbind is seg fau 1104190813 M * mikeb lting when it tries to mount the proc, tmpfs, and dev file systems. I've searched all around trying to find any posts with similar behavior, but my googlefoo is failing me. Has anyone ever seen chbind segfaulting when processing the /etc/vservers//fstab file?