1120348815 J * monrad ~monrad@213083190130.sonofon.dk
1120349080 M * Hollow Bertl, Doener: a multi tool app would be ok with me (afaiu vserver <command> foo bar)
1120349132 M * Doener Hollow: i think Bertl means something like showattr/setattr (same file, different name -> different behaviour)
1120349162 M * Greek0 what is the actual difference between bcaps and ccaps?
1120349166 M * Vudumen_ if anyone interested i created debian packages from hollows' libvserver -> http://vudumen.hu/vserver/
1120349173 M * Hollow bcaps = system caps, ccaps = context caps
1120349195 M * Hollow Vudumen_: heh
1120349202 N * Vudumen_ Vudumen
1120349207 M * Greek0 yes, I've read the flower page too. those names don't really tell me more though.
1120349230 M * Bertl Greek0: bcaps are the 'normal' capabilities (or to be precise, the upper bound)
1120349232 M * Vudumen Hollow: these are working packages but are far away from being 100% correct ;)
1120349235 M * Vudumen but it works for me fine
1120349243 M * Doener ccaps are subsets of the linux capabilities, CAP_NETRAW is too mighty, but without it ping does not work, so there's a ccap that just allows ping to work, but doesn't give the other privileges of CAP_NETRAW
1120349281 M * Bertl well, not necessarily subsets ... but yes
1120349317 M * Doener Hollow: will you be around tomorrow? then we could discuss some direction for the lib...
1120349325 M * Greek0 do ccaps have any meaning in the vanilla kernel, or are they a vserver thing?
1120349346 M * Hollow Doener: sure
1120349371 M * Bertl Greek0: they are a vserver only thing ...
1120349374 M * Doener great, guess I'll be around from 10am CEST
1120349385 M * Hollow ok
1120349409 M * Hollow dunno if i make it at 10am, but around 11am i should be available
1120349438 M * Doener i know that I'll be up... my girlfriend's sleeping here, so she'll wake me ;)
1120349472 M * Doener I'm off to bed then, see you tomorrow and have a good one!
1120349479 M * Bertl night Doener!
1120349498 M * Doener night Bertl, Hollow, #vserver
1120349509 M * Hollow n8 Doener 
1120349614 M * Greek0 ah, ok. after some more digging in the source I finally understood it.
1120349670 M * Greek0 I had the wrong assumption at first that ccaps and bcaps are the same constants with the same meanings, just different scope or something
1120349679 M * Hollow Vudumen: i added your link to the wiki ;)
1120349711 M * Vudumen Hollow: ohh thanks :)
1120349734 M * Hollow Vudumen: so you could have edited it yourself ;)
1120349781 M * Vudumen well it's true :) i tried to find it but i didn't found :(
1120349787 M * Vudumen i searched for xnull :)
1120349799 M * Hollow well... i just gave anonymous the right to post :P
1120349807 M * Hollow ah, you didn't find the wiki?
1120349814 M * Hollow http://dev.croup.de/proj/libvserver
1120349829 M * Vudumen ahh this wiki :) i searched linux-vserver.org :)
1120349839 M * Hollow heh
1120349895 M * Greek0 hmm. libvserver sounds nice. very nice..
1120349919 M * Hollow Vudumen: oh.. and the download section is not home.xnull.de but http://dev.gentoo.org/~hollow/vserver/libvserver/ could you change it in the package plz?
1120349929 M * Vudumen Hollow: yes :)
1120349931 M * Hollow home.xnull.de is my desktop machine, this url should not be spread everywhere ;)
1120349937 M * Vudumen ohh ok :)
1120349943 M * Bertl Hollow: too late :)
1120349946 M * Hollow :P
1120349955 M * Hollow i know it's too late but anyway...
1120349960 M * Hollow it's not official in any way
1120350055 M * Bertl hmm, indeed, google only shows 462 hits ...
1120350257 M * Vudumen Hollow: i updated the packages
1120350262 M * Hollow thx
1120350269 M * Vudumen 1 min update, 3 mins copying through 4 machines :)
1120350528 M * Greek0 should I include some discussion of [bc]capabilities on <URL:http://linux-vserver.org/Step-by-Step+Guide+2.6>, or should I make a new page and just add a link?
1120350741 M * Bertl http://linux-vserver.org/HowTo+Read+ProcFS (jsut an idea)
1120350830 M * Bertl IMHO several smaller, linked pages are preferable over an all-in-one doc, but that's just my preference
1120350913 M * Greek0 I'd write about the configuration side.
1120350970 M * Hollow imo there is too little (and often the same) info on too many pages
1120351147 M * Greek0 I really like the Step-by-Step guide, since it gets you started really well (though I might be slightly biased here)
1120351155 M * Bertl yeah, that's right, page consolidation should be  done now and then ...
1120351186 M * Bertl but I understand that folks prefer to write something new, than to clean up/consolidate old pages
1120351224 M * Bertl IMHO most of the howtos could be reduced to a 3-4 essential howto pages
1120351239 A * Hollow nods
1120351471 M * Greek0 why isn't the flower page on the wiki actually?
1120351491 M * Greek0 what I'd like to write here is really just an addition to a topic where the flower page doesn't go into much detail
1120351518 M * Bertl well, enrico auto generate(d) the page from the soruces
1120351537 M * Bertl (there is an xml version in the source)
1120351662 M * Greek0 so would it would probably be the best to submit a patch against the .xml?
1120351678 M * Bertl Greek0: but it might be a good idea to write a simple converter ... to get a wiki version?
1120351756 M * Greek0 probably also possible.
1120351764 M * Greek0 that way we'd even get rid of the stylesheet ;)
1120351784 M * Bertl hehe, well it was fun back then :)
1120351786 M * Hollow i like the stylesheet
1120351790 M * Hollow :))
1120351805 M * Bertl Greek0: and which one do you mean?
1120351821 M * Bertl s/mean/refer to/
1120351830 M * Greek0 I didn't know how to change stylesheets in firefox, so I downloaded it and stuffed it on my server, just to get rid of the stylesheet .. :)
1120351844 M * Greek0 the default (hemp) stylesheet
1120351850 A * Hollow prefers "gras" though weedpage is nice too ;)
1120351926 M * Bertl gras1 is my current setting ...
1120351972 M * Hollow hehe
1120352063 M * Hollow kiffen is evil...
1120352066 M * Hollow really
1120352098 M * Greek0 Bertl: do  VXC_QUOTA_CTL VXC_BINARY_MOUNT and VXC_SYSLOG work at the kernel level?
1120352112 M * Greek0 I just saw them in the kernel, but they're not supported by the tools atm
1120352124 M * Bertl yes, they work
1120352138 M * Hollow Bertl: did you update the headers?
1120352158 M * Bertl vs2.0-rc5 has new headers, yes
1120352177 M * Bertl (with the changes we discussed)
1120352247 M * Greek0 ok, I'm off to bed. cu
1120352265 M * Bertl night Greek0!
1120352430 J * eXplasm2 explasm@p549F7220.dip.t-dialin.net
1120352485 Q * eXplasm2 Remote host closed the connection
1120352706 J * rs ~rs@imhotep.rhapsodyk.net
1120352779 M * Bertl morning rs!
1120352861 Q * eXplasm Ping timeout: 480 seconds
1120353070 Q * daniel_hozac Ping timeout: 480 seconds
1120353399 J * daniel_hozac ~daniel@h56n2fls32o829.telia.com
1120353449 M * Bertl wb daniel_hozac!
1120353456 M * daniel_hozac thanks.
1120354170 M * Vudumen Hollow: are you here?
1120354238 M * Bertl looks like he is over there ...
1120354404 M * Bertl just because I'm watching stuff from live8, have folks looked at the page and considered signing the list?
1120355534 M * daniel_hozac what was the URL?
1120355551 M * Bertl live8live.com
1120355566 M * daniel_hozac thanks.
1120355571 M * Bertl yw
1120356916 M * micah Bertl: I tried to find the live video, but couldn't
1120356965 M * Bertl aol has/had a live feed ...
1120357037 M * micah oh yeah
1120357038 M * Bertl but several satellite channels either transmitted it live or timeshifted
1120357041 M * micah their site crashes my browser
1120357047 M * micah :P
1120357074 M * micah busy preparing UK servers for indymedia protest reporting
1120357432 M * Vudumen good night allz
1120357440 M * Bertl night Vudumen!
1120358318 M * Bertl okay, I'm off to bed now too .. have a nice one everyone!
1120358333 N * Bertl Bertl_zZ
1120358985 J * mrplum ~m@H80.C211.tor.velocet.net
1120359161 M * mrplum Where can I learn about how to setup networking inside the vserver?
1120359495 M * daniel_hozac you setup the networking outside the vserver.
1120359522 M * daniel_hozac check vserver - build --help for the network related options.
1120359849 M * mrplum does that mean I should have done it when I built the vserver? easiest to start over or is there another way
1120360361 M * micah mrplum: you can do it afterwards
1120360529 M * mrplum If I could find an example SERVER.conf file to go by I think I'd be good
1120360554 M * mrplum I'm using the debian packages, I must be missing out on a lot of info 
1120360587 M * micah mrplum: sounds like you are using 1.2 vserver?
1120360599 M * micah mrplum: which debian package?
1120360787 M * mrplum whatever is in sarge
1120360795 M * mrplum i'll check
1120360828 M * mrplum 1.9.5.3
1120361125 M * mrplum Do SERVER.conf files no apply to the 1.9 versions anymore? is that why you say that?
1120362170 J * AprilDL_ ~chatzilla@ip68-9-200-247.ri.ri.cox.net
1120362250 Q * mrplum Quit: Leaving
1120362357 Q * AprilDL Ping timeout: 480 seconds
1120363414 M * micah monrad: no, they dont
1120363417 M * micah err
1120369715 J * shuri shuri@64.235.209.226
1120369717 Q * shuri Quit: 
1120370800 J * AprilDL__ ~chatzilla@ip68-9-200-247.ri.ri.cox.net
1120370801 N * AprilDL__ AprilDL
1120371115 Q * AprilDL_ Ping timeout: 480 seconds
1120375024 J * Doener` ~doener@p548758A8.dip.t-dialin.net
1120375027 J * Aiken ~james@tooax6-102.dialup.optusnet.com.au
1120375472 Q * Doener Ping timeout: 480 seconds
1120379312 M * Hollow morning
1120379409 M * daniel_hozac morning
1120380787 Q * Hollow Remote host closed the connection
1120380830 J * Hollow ~Hollow@home.xnull.de
1120380927 Q * Hollow Remote host closed the connection
1120380940 Q * complexho Ping timeout: 480 seconds
1120381024 J * Hollow ~Hollow@home.xnull.de
1120381156 J * complexho ~mark@funk.gotadsl.co.uk
1120382018 Q * rs Quit: rs
1120382264 J * aba_ ~aba@eos.turmzimmer.net
1120382264 Q * aba Read error: Connection reset by peer
1120382838 J * AprilDL__ ~chatzilla@ip68-9-200-247.ri.ri.cox.net
1120382881 Q * Hollow Remote host closed the connection
1120382922 J * Hollow ~Hollow@home.xnull.de
1120383115 Q * AprilDL Ping timeout: 480 seconds
1120383813 J * AprilDL___ ~chatzilla@ip68-9-200-247.ri.ri.cox.net
1120383815 N * AprilDL___ AprilDL
1120383911 Q * Hollow Remote host closed the connection
1120384031 J * Hollow ~Hollow@home.xnull.de
1120384195 Q * AprilDL__ Ping timeout: 480 seconds
1120384318 Q * Hollow Remote host closed the connection
1120385384 J * Hollow ~Hollow@home.xnull.de
1120385611 M * Hollow morning Doener` 
1120385678 M * DaPhreak lo ;)
1120385788 M * Doener` ah, there he is :)
1120385797 M * Doener` morning
1120385821 A * Doener` always looked at the irc window when Hollow had quit once again ;)
1120385837 M * Hollow just has to restart X some times ;)
1120385839 M * Hollow *had
1120385931 M * Hollow so ein fuck
1120385945 M * Hollow erm.. such a fuck *g*
1120386124 M * Hollow so what about the lib?
1120386131 M * Hollow Doener`, DaPhreak ..
1120386170 M * DaPhreak yeah .. no idea. that why i was asking Doener` and today you ;)
1120386190 M * Hollow heh
1120386209 M * Doener` ok, one thing i noticed yesterday is that the current library functions offer no convinience enhancement over the functions the kernel provides
1120386220 A * Hollow nods
1120386246 M * Hollow imo the primary question is: seperate lib and tools?
1120386264 M * Doener` f.e. a userspace function still needs to pass a vhi_names struct (field + name) to get the name, which is rather annoying ;)
1120386287 M * Hollow you want it to accept strings?
1120386291 M * Hollow with flags..
1120386337 M * Doener` i'd like to have get_vhi_name(xid_t xid, int field, char *name)
1120386367 M * Hollow mhm
1120386419 M * Hollow i'm fine with that
1120386421 M * daniel_hozac you'd probably want a size_t length there as well ;)
1120386437 M * Doener` that the syscall needs that struct that combines field and name is because we're limited to 3 arguments ;)
1120386463 M * Doener` Hollow: ok, i just wanted to make sure, because you said you want to stay as close to the kernel interface as possible
1120386474 M * Doener` lunch time... back in a few
1120386522 M * Hollow Doener`: yup, but this doesn't mean an 1:1 copy...
1120386914 M * Doener` ok
1120386975 M * Doener` hm, tools and lib separation...
1120386983 M * Hollow I'd just like to stay with the names and logic as far as possible, so peepz won't get confused
1120387011 M * daniel_hozac hmm, how about some convenience typedefs?
1120387015 M * DaPhreak lunch time ;)
1120387035 M * Hollow pfft... who does lunch for me? :(
1120387054 M * Doener` you can get mine... didn't like it too much
1120387067 M * Hollow heh
1120387075 M * daniel_hozac struct vcmd_vx_info_v0 is a bit too specific, IMO.
1120387082 A * Hollow nods
1120387095 M * Hollow as i said, this is nearly a 1:1 copy of the kernel interface...
1120387226 M * Greek0 what do you want to do with the lib in the end? build tools over it? then the question arises if you want to do them in c, or if you prefer writing some simple bindings for a scripting language and code the tools there.
1120387253 M * daniel_hozac should vdlimit really accept a command?
1120387286 M * daniel_hozac i mean, vdlimit isn't altering the current process' like most of the tools.
1120387291 M * Hollow Greek0: i'd really like to have bindings... especially for ruby
1120387299 M * daniel_hozac Python!
1120387317 M * Hollow yup, but please don't support php ^^
1120387327 M * daniel_hozac probably worth to look into swig or some other binding generating utility.
1120387328 M * daniel_hozac hehehe.
1120387330 M * Greek0 not that I'd have anything to say, but I'd prefer python too ;)
1120387377 M * Greek0 daniel_hozac: well, I don't really know if it's worth it to support multiple languages, at least for the tools themselves. I mean, we/you probably don't want the tools to be in python/ruby then, but only one of them
1120387416 M * daniel_hozac but having bindings for multiple languages means people can use them for their own homebrew management stuff.
1120387422 M * Hollow tbh i'd like to have the tools in C but bindings for e.g. vserver webapps etc
1120387424 M * Greek0 yup
1120387432 M * daniel_hozac without coercing them into some weird language like ruby ;)
1120387439 M * Hollow ruby rocks
1120387454 M * Hollow this is true OOP, not python-wishy-washy
1120387469 M * Greek0 I haven't seen too much of ruby yet, but it looks quite reasonable
1120387473 M * daniel_hozac i hate OOP with a passion :)
1120387481 M * Hollow then stick with python!
1120387483 M * Hollow :P
1120387491 M * Greek0 ok, can we defer the python/ruby flamewar a bit?
1120387501 M * Greek0 and do the tools in c/scripting language flamewar now? ;)
1120387502 A * Hollow doesn't see a flame
1120387539 A * Greek0 was joking a bit and forgetting his smilie
1120387545 M * Hollow heh
1120387556 M * Greek0 anyway, I'd prefer to have the tools in some scripting language..
1120387556 M * Hollow daniel_hozac, Greek0: btw, you want to help? ;)
1120387568 M * Greek0 I think it's just much more productive then to do them in c
1120387592 M * Hollow Greek0: but then you have to add much more common functionality to the lib imo
1120387593 M * daniel_hozac the tools themselves ought to be in C, IMO.
1120387604 M * Greek0 Hollow: depends on my interest in this in the future. Unfortunately my attention span wrt. software projects isn't very large.
1120387607 M * daniel_hozac with some higher level script.
1120387621 M * Greek0 but at the moment it sounds pretty cool, and I'd probably want to support it
1120387623 M * daniel_hozac (or C daemon, or whatever)
1120387625 M * Hollow daniel_hozac: just like it is now..
1120387639 M * Hollow lib + c tools + bash scripts
1120387641 M * daniel_hozac yeah, well, it works.
1120387682 M * Greek0 after having looked at the current tools, I'm not in favor of that approach ;)
1120387688 M * daniel_hozac Doener`s daemon sounds like a step forward though.
1120387690 M * Hollow heh
1120387697 M * Hollow daniel_hozac: yep, i like it very much
1120387708 M * Greek0 which daemon?
1120387731 M * Hollow a daemon listening on a unix socket executing all vserver commands..
1120387745 M * daniel_hozac http://www.13thfloor.at/~doener/vserver/tools/vservd-0.02.tar.bz2
1120387775 M * Greek0 like the x11 approach?
1120387777 M * Hollow this would be realy cool wrt rpc/soap to handle multiple hosts through one machine
1120387944 M * Greek0 well, what about extending the lib to the point where it encapsulates more or less that, what the current c tools in util-vserver do.
1120387960 M * Greek0 then we could have thin wrappers around them to get commandline versions
1120388012 M * Greek0 and still could call them directly from the driver scripts, given we do them in some language that supports c bindings
1120388015 M * Doener` i don't think the lib should have built-in support for any configuration format, should it?
1120388026 M * daniel_hozac i think it should.
1120388045 M * Greek0 no, I think that's a job for the driver scripts actually
1120388066 Q * Aiken Quit: Leaving
1120388103 M * Greek0 I mean, just get the whole business-end stuff into the lib and additionally higher-level functions, that do stuff like that what vattribute, reducecap, .. do atm.
1120388125 M * Greek0 and then use them from a scripting language that drives the whole process
1120388134 M * daniel_hozac then the tools won't be able to take vserver names as --xid arguments.
1120388152 M * Greek0 why?
1120388177 M * Doener` daniel_hozac: the tools can still implement some configuration scheme... i'm talking about the plain library
1120388177 M * daniel_hozac because they are on a lower level than the driver scripts.
1120388223 M * daniel_hozac well, if the tools (as in v*, no scripts) implement a configuration scheme, it ought to be in the library.
1120388233 M * Greek0 daniel_hozac: no, IMHO not
1120388235 M * daniel_hozac so the higher level utilities can use the same scheme.
1120388250 M * Greek0 I think the library should just provide a high-level interface to the kernel functions
1120388256 M * daniel_hozac so you'd rather have two sets of configuration data?
1120388260 M * Greek0 everything else should be handled in the scripts
1120388277 M * Greek0 eg. reducecap doesn't read any configfiles. neither does vattribute, ...
1120388295 M * daniel_hozac except, when you use a name argument to --xid.
1120388316 M * Greek0 daniel_hozac: any why shouldn't that name be handled in the scripts
1120388322 M * Greek0 I mean, that's really trivial
1120388333 M * daniel_hozac v* aren't scripts.
1120388336 M * Hollow apropos... Doener`: will the context field in vhi be used to set a context name per id?
1120388346 M * Greek0 IMHO the lib shouldn't know anything configuration
1120388346 M * Doener` Context: /etc/vservers/naucki
1120388357 M * Doener` that's what util-vserver puts there
1120388375 M * Greek0 daniel_hozac: forget about what the v* executables do now. just think in terms of functionality.
1120388382 M * daniel_hozac i am.
1120388398 M * daniel_hozac without configuration accessibility from the v* tools, --xid cannot accept name arguments.
1120388406 M * DaPhreak back ,..
1120388481 M * Hollow we should really use VHIN_CONTEXT imo
1120388500 M * Greek0 the lib should just provide an interface to the kernel, high-level enough for us
1120388508 M * Greek0 and the scripts should then call that library.
1120388517 M * Doener` IMHO the libvserver should not contain knowledge about configuration, the tools (that may accompany libvserver) may have such knowledge and could even provide another lib (libvtools or whatever) that contains functions regarding that configuration format
1120388520 M * Greek0 and stuff like --xid can and should be handled in the helper scripts
1120388540 M * Doener` Hollow: VHIN_CONTEXT does not help when it comes to Name->XID lookups
1120388549 M * Doener` just the other way round works
1120388550 M * DaPhreak Doener`: yeah, that how I thought
1120388568 M * Greek0 Doener`: yep, sounds nice
1120388568 M * Hollow hm
1120388569 M * daniel_hozac so, you'd have a syscall wrapper, a library wrapper, a binary wrapper...
1120388617 M * Greek0 yeah, 4 layers more and we're OSI compliant ;)
1120388660 M * Hollow reminds me of apr/apu
1120388679 M * daniel_hozac having a separate library for the configuration format seems pretty useless to me.
1120388694 M * Greek0 who said that we want such a thing daniel_hozac?
1120388706 M * daniel_hozac Doener` ;)
1120388718 M * Greek0 ah, overread that part
1120388725 M * DaPhreak _could_ ;) not should *g*
1120388741 M * Hollow imo the low-level tools should not be able to take a context name as argument
1120388743 M * Greek0 well, it could be done. at least it should be made modular..
1120388754 M * Greek0 Hollow: ack
1120388755 M * daniel_hozac Hollow: that'll suck for people with dynamic contexts.
1120388763 M * Hollow daniel_hozac: people shouldn't use them
1120388775 M * daniel_hozac right, but they do.
1120388780 M * Hollow their problem
1120388786 M * Greek0 daniel_hozac: I really don't see your problem. the name->xid mapping can be trivially done in _any_ wrapper.
1120388803 M * daniel_hozac but you shouldn't need that extra wrapper.
1120388810 M * Hollow Greek0: to know the xid of a name yo have to look at the config
1120388816 M * Greek0 daniel_hozac: we need a wrapper for the library anyway
1120388819 M * daniel_hozac you already have a wrapper that's doing essentially nothing.
1120388831 M * Greek0 unless you somehow teach bash how to call into a library from the commandline directly
1120388872 M * notasnark Hi Hollow.
1120388878 M * Hollow hi notasnark 
1120388887 M * notasnark Thanks for the Gentoo docs you wrote... I got vserver running last night for the first time.
1120388895 M * Doener` if someone disagrees with the chosen configuration format and thinks he can do better, he should still be able to take advantage of the lib, he just has to do the configuration part again...
1120388897 M * Hollow with baselayout-vserver?
1120388904 M * notasnark Yes.
1120388914 M * notasnark Though syslog-ng doesn't start.
1120388914 M * Hollow everything running fine?
1120388924 M * Hollow notasnark: did you remove the klog part from src?
1120388932 M * notasnark Yes.
1120388935 M * Doener` libvserver is there, then you can use vtools, vutils, my-mighty-vconf-is-better-tools or whatever...
1120388960 M * Doener` (once we got libvserver to not bail out when linked dynamically...)
1120388961 M * Hollow notasnark: any log entries? ah.. without syslog.. just jocking
1120388964 M * Hollow ;)
1120388970 M * notasnark I had installed baselayout first, then unmerged it and emerged baselayout-vserver. Not sure whether that caused problems.
1120388979 M * Hollow notasnark: probably.
1120388982 M * notasnark The lack of logs has been a problem :-)
1120389004 M * Hollow notasnark: why didn't you try the stages?
1120389027 M * Greek0 Doener`: yeah, it's ok to make it very modular. if it's worth to build a full library of it (nailing the fact that we need to do it in c more or less) is another question IMHO
1120389036 M * notasnark Stages? I used the vserver stage3 tarball: stage3-i686-2005.0.tar.bz2
1120389062 M * Greek0 I think it would be enough to just have a configuration.py/configuration.ruby or something, with a well defined interface, that can be easily exchanged
1120389067 M * Hollow notasnark: hm.. these stages contain baselayout-vserver, why did you unmerge it?
1120389084 M * Hollow Greek0: to do waht?
1120389085 M * notasnark Because I'm stupid? :-(
1120389100 M * Hollow notasnark: did you unmerge baselayout or baselayout-vserver?
1120389141 M * notasnark I followed the Gentoo install instructions, and blindly emerged baselayout when it said to, then afterwards remembered that there was a basaelayout-vserver. So I unmerged the baselayout and then did an emerge of the baselayout-vserver.
1120389179 M * Hollow hm, so did you follow my guide or the install handbook?
1120389181 M * Hollow ;)
1120389181 M * Greek0 Hollow: so users can use their own config format, if they want to. Doener` seems to be interested in it.
1120389193 M * notasnark http://www.gentoo.org/doc/en/vserver-howto.xml
1120389199 M * Hollow i am too, cause the current configuration layout is just A MESS!
1120389212 M * Hollow 1000+ files wtf!
1120389233 M * Greek0 Hollow: I think we can just get that really easy if we just make it modular at a source code level, without splitting it out into a seperate library
1120389257 M * Greek0 Hollow: I didn't have too much problems with it yet.
1120389262 M * Hollow we should just provide a config wrapper, so i could store vserver configs in mysql as well
1120389297 M * Hollow notasnark: then i don't understand where did you emerge baselayout?
1120389306 M * Greek0 Hollow: IMHO it's just enough to have a config.py/config.ruby file that can be easily exchanged, and that's used by the scripts
1120389328 M * Greek0 I've also thought of the possibility to store the config data in LDAP or an SQL db.
1120389331 M * Hollow i personally don't like config files embedded in the scripting lanuage
1120389344 M * Greek0 Hollow: no, that's not what I mean
1120389355 M * Greek0 config.py/config.ruby would just be a parser for the data
1120389362 M * Hollow aah
1120389365 M * Greek0 but modular, contained in one file, with a well defined interface
1120389365 M * Hollow got that rong
1120389370 M * Greek0 and thus easily to exchange
1120389379 M * Greek0 s/ly//
1120389397 M * Hollow imo we'd just need sth like AdoDB but for other backends as well
1120389416 M * notasnark Hollow: At the point it says to follows the Gentoo handbook from chapter 5.b to chapter 7.a. That includes section 6.e "Upgrading the baselayout". There is says to emerge baselayout, so I did.
1120389434 M * Greek0 AdoDB?
1120389440 M * Hollow so you can just use sth like this: config_set(int option, char *value) or so
1120389458 M * Hollow Greek0: sql database abstraction layer
1120389469 M * Doener` active database objects?
1120389473 M * Hollow notasnark: oh.. this section is new then...
1120389481 M * Greek0 hmm. sounds a bit like overkill to me, really.
1120389506 M * notasnark Ah. That explains the problem :-)
1120389507 M * Greek0 I think we could just be done with Init(..), ShutDown(..), Query(s: string);
1120389531 M * Hollow Greek0: just think of a storage backend to use with plaintext files, ldap, sql, berkdb and such
1120389531 M * Greek0 or some Query(..) function that fits us
1120389535 M * notasnark Should I try another install and ignore the baselayout this time?
1120389547 M * Hollow notasnark: no, try the following:
1120389568 M * Hollow CONFIG_PROTECT="-*" CONFIG_PROTECT_MASK="-*" emerge -C baselayout baselayout-vserver
1120389575 M * Hollow cd /etc
1120389581 M * Hollow rm make.profile
1120389592 M * Hollow ln -s ../usr/portage/profiles/vserver/x86 make.profile
1120389596 M * Hollow emerge baselayout-vserver
1120389608 M * Hollow etc-update
1120389651 M * Hollow this should install a clean baselayout
1120389665 M * Greek0 Hollow: I just think it sounds like overkill. IMHO the config interface should be really simple/stupid.
1120389668 M * Hollow just ignore all the errors popping up during the second emerge
1120389678 M * Greek0 just init/shutdown and a query function or something
1120389702 M * Hollow Greek0: if you like it simple then you can use the plaintext backend ;)
1120389721 M * notasnark emerge baselayout-vserver fails with lots of errors when it tries to merge to /
1120389728 M * Greek0 no, I'm talking about the interface tools/config.(py|ruby)
1120389738 M * Hollow but think of bigger vps installations where e.g. customers can change their settings through a webinterface... handling plaintext files this way is really hard
1120389749 M * Hollow and you have to give the webapp access to every vserver host
1120389756 M * Greek0 Hollow: that doesn't have any inpact on that interface
1120389767 M * Hollow notasnark: it fails, or just prints many errors?
1120389807 M * notasnark Probably just printing errors.... http://www.glendale.org.uk/~sam/errors.txt
1120389816 M * Greek0 think about it from the tool side. do you really want to startup an adodb session every time you need a mapping ctxname <-> xid or something?
1120389830 M * Greek0 or want to get the initstyle?
1120389840 M * daniel_hozac ... yes.
1120389845 M * Hollow notasnark: hum...
1120389877 M * Greek0 I'm just in favor of doing this the simplest way that can possibily work
1120389885 M * Hollow Greek0: do you really want to open a file descriptor and parse every byte if you want to look ti up?
1120389912 M * Greek0 Hollow: that would all be hidden in config.py/config.ruby
1120389925 M * Doener` Greek0: it always depends on the usage, thus let's have the user choose which backend he wants
1120389927 M * Hollow so why don't hide some sql commands there as well?
1120389957 M * Doener` Greek0: and if my daemon ever gets finished, it could hold the adodb connection and act on behalf of the tools...
1120389974 M * daniel_hozac Doener`: wouldn't it be the tool?
1120389981 M * Greek0 just init(), where it opens the db connection or the file, and possibly reads and caches everything (if we want that), then query(), where a value is returned to the tools, and shutdown or something, where we clean up.
1120389999 M * Greek0 Doener`: I'm talking about a generic interface to config.py here
1120390001 M * Hollow Greek0: that's how backends work ;)
1120390017 M * Hollow give a generic api to many different backend apis ;)
1120390033 M * Greek0 I'm not talking about a specific config.py. if you query LDAP or open a textfile, it doesn't matter
1120390047 M * Greek0 yeah, but AdoDB sounds a bit like overkill for that interface
1120390055 M * Hollow adodb _is_ overkill
1120390060 M * Hollow was just an example
1120390062 M * daniel_hozac AdoDB would be _a_ backend.
1120390063 M * Doener` daniel_hozac: regarding the actual work, yes. with "tools" i meant some (probably multi-name) executable that talks to the daemon
1120390070 M * Greek0 Hollow: ah, ok
1120390090 M * Greek0 I really thought you wanted to make config.py have the adodb interface or something
1120390108 M * Hollow it can support adodb, but i won't code it :P
1120390113 M * Doener` what is config.py?
1120390120 M * Hollow the storage backend
1120390122 M * Hollow ;)
1120390126 M * Greek0 Doener`: your drop-in configuration libary
1120390128 M * Greek0 +a
1120390155 M * Greek0 it would be just as exchangeable as a library, and we aren't forced to write the whole thing in c
1120390176 M * Greek0 especially since the config stuff can be quite string-processing based, which sucks to do in c IMHO
1120390180 M * daniel_hozac instead, we are forced to write it in some scripting language.
1120390189 M * Hollow i'd prefer C
1120390191 M * Doener` would prefer c...
1120390206 M * Greek0 I just think that you're not as productive in c.
1120390232 M * daniel_hozac i'm far more productive in C ;)
1120390243 M * Greek0 I mean, c is a great language, but doing eg. heavy string processing in c is just a pain to code.
1120390250 M * daniel_hozac (i don't know ruby, and i'm just starting to learn Python...)
1120390253 M * Doener` depends on the configuration format... i guess the util-vserver format is really easy in C
1120390271 M * Hollow at least the 1000+ files approach
1120390309 M * Greek0 yeah, but then, on the other hand, it's about 10 lines in shell to parse that config files. and perhaps about as much in python
1120390340 M * notasnark Hollow: I'm going to try a rebuild from fresh, and this time I'll leave the baselayout alone! Didn't take too long last time.
1120390342 M * Hollow who cares
1120390347 M * Doener` if it' an .ini file, it's one line in php ;)
1120390353 M * Hollow notasnark: yup
1120390364 M * Greek0 python has it's .ini parser module too ;)
1120390366 M * Hollow php sucks
1120390368 M * Hollow ^^
1120390378 M * Greek0 I think we can all agree on that ;)
1120390391 M * Hollow hehe
1120390407 M * daniel_hozac PHP is nice :)
1120390434 M * Greek0 I mean, I don't hate c or something, I just think it's easier to write code in languages like python or ruby.
1120390447 M * Greek0 there are just less details to pay attention to
1120390488 M * daniel_hozac well, making a config library with Python callouts wouldn't be hard.
1120390510 M * Greek0 that's why I try to minimize the code written in c most of the time.
1120390554 M * Greek0 daniel_hozac: ack. but we don't really want to use the config from the c library, but rather from the driver scripts.
1120390556 M * Hollow Doener`: your approach would be sth more like this (just to see if i get it right).. http://phpfi.com/68114
1120390571 M * Greek0 and it would be easy the other way around too, call c from the config.py file
1120390588 M * Doener` Hollow: checkout changeset 20... http://dev.croup.de/proj/libvserver/changeset/20
1120390596 A * Doener` felt free to just commit it ;)
1120390635 J * ascendancy ~mirc@dev.smallfryhosting.co.uk
1120390639 M * Hollow heh
1120390751 M * Doener` i think flags/caps should stay as 'all-on-one', not single flags/caps at a time, just get rid of the structs
1120390766 M * Hollow imo we should first talk about where the lib goes, before we argue about which config backend the high-level app uses ;)
1120390787 M * Greek0 Hollow: yep
1120390799 M * Doener` as you can see in the vuname.c stuff, the struct didn't fit the code very well, code length was reduced quite a bit
1120390940 M * Doener` we could also add a get_all_vhinames() (which would just move the code from vuname.c to cvirt.c) to have a function that reads all the values, but i'm not sure that it's worth it...
1120390993 M * Hollow the question is: do we keep the lib simple and clean towards the kernel api, or do we integrate extra functionlity making life with vserver in other apps easier
1120391059 M * Doener` IMHO the latter, to some extend... otherwise we could as well just release a header file that does a bunch of #define's
1120391095 M * Hollow mhm, but the again i'd prefer to not distribute any tools with the lib
1120391121 M * Doener` if you want to split those two, that's fine with me
1120391129 M * Doener` you added them in the first place ;)
1120391140 M * Hollow primary just to test the lib ;)
1120391154 M * Doener` thought so
1120391182 M * Hollow .oo( libvserver, vserver-tools, vserver-utils )
1120391200 M * Doener` hm, what's the difference between the last two?
1120391224 M * Doener` and vserver-tools is a bad name, IIRC Jack's tools were called like that
1120391229 M * Hollow tools = vcontext, vuname etc & utils = vserver command, storage backend etc
1120391291 Q * maple Remote host closed the connection
1120391303 Q * [maple] Remote host closed the connection
1120391341 M * Doener` ok, what about the following: we keep the tools that are currently in there, to have something to test with and see what functions we want the library to expose. later we can still move the tools into a separate package
1120391354 J * eXplasm explasm@p549F7220.dip.t-dialin.net
1120391356 M * Hollow yup
1120391393 M * Doener` hm, well, we could already move them... shouldn't be much of a problem, but it makes testing easier if someone changes the lib unless we put the other package into the same svn repository
1120391426 M * Doener` i.e. easier to follow api changes, the one who changes something also has to fix the tools ;)
1120391460 M * daniel_hozac yeah, the tools are good as a test suite.
1120391470 M * Hollow Doener`: so maybe we can leave them there as well ;)
1120391480 M * Hollow we'll see
1120391636 M * Doener` ok, I'll prepare some suggestions for the basic functions...
1120391669 M * Hollow k
1120392070 M * Greek0 what url do I need to check out libvserver from svn?
1120392081 M * Doener` http://dev.croup.de/proj/libvserver/wiki/SvnAccess
1120392140 M * Doener` Hollow: hm, guess you wouldn't like almighty structs v_context and struct n_context, right?
1120392152 M * Doener` (not sure they would be a good idea anyways...)
1120392161 M * Hollow what would they contain?
1120392230 M * Doener` everything context/network context related... but I think it would lead to some confusion anyways, as the functions would only work on parts of it... just forget it ;)
1120392285 M * Hollow :)
1120392448 M * notasnark Hollow: Yay! I've finished the install (2nd attempt), and this time I ignored the new bit in the docs about messing with baselayout. Everything seems to be up and running now. Thanks!
1120392473 M * Hollow notasnark: good! i will update the doc asap
1120392588 M * notasnark Now, what is the easiest way to create a new virtual server based on that one? Presumably I don't need to build another instance from scratch again?
1120392641 M * Hollow notasnark: http://home.xnull.de/work/gentoo/vserver/tools/vserver-new
1120392651 M * Hollow bash script to clone vservers
1120392696 M * notasnark Excellent, thanks very much for all your help. I'll have a play...
1120392710 M * Hollow sure, np
1120392743 Q * nox Remote host closed the connection
1120392767 J * nox ~nox@noxlux.de
1120393426 P * notasnark Kopete 0.10 : http://kopete.kde.org
1120393641 M * Hollow off for now.. maybe back online in an hour if i find an access point.. cya
1120393652 M * Doener` cya
1120393869 J * prae ~prae@sherpadown.net
1120394955 M * complexho hi Doener  -I have a quick question for you if that's ok 
1120394963 M * Doener` sure
1120394972 M * Doener` that's what irc is for, right? ;)
1120395029 M * complexho I am trying to follow progress on libvserver and your new daemon wondered if there was any crossover planned between the two...?
1120395125 M * Doener` once we got some more or less stable base in libvserver, i'll make the daemon use that. most of the current code in the daemon will probably be removed later.
1120395153 M * Doener` the tools that accompany libvserver atm, will probably be removed/moved into an own package later
1120395263 M * complexho so is libvserver an 'official' next generation tool (or alternative at least..) for vserver? 
1120395397 M * complexho The reason I wonder is because it is likely that we will put some significant devel effort into what we do with vserver, and tools are very high on our agenda.  But I would prefer to workin harmany with the vserver project rather than in parallel
1120395401 M * Doener` libvserver will probably just be a library that eases writing of tools, we had a small discussion about what we actually want it to be earlier today, but AFAICT we didn't find a compromise yet
1120395415 M * complexho yes I was watching :)
1120395492 M * complexho quite an interesting conversation, we have been having thoughts about the configuration aspect too, like possibly looking ito LDAP or SQL
1120395523 M * complexho which is why I am interested in your daemon - especially if you are planning to make it network accesible too
1120395679 M * complexho did you take a closer look at the vsd code yet?
1120395716 M * Doener` no, spent most of my time on libvserver yesterday, as that will become a pre-requisite for the daemon
1120395957 M * complexho is there a status page up for libvserver yet, or any goals set?
1120396248 M * complexho sorry looking at wiki now - still a fair way to go :)
1120396429 M * Doener` feel free to make suggestions, I'm currently preparing some api suggestions for the basic functions
1120397214 M * _are_ no idea if that would be related anyway: I'd like to be able to have some perl-interface to it, but probably this is not the interface stuff that is discussed atm ;)
1120397255 M * complexho ok I'll be back on later (going to go and grab some sun on the beach before dinner :)
1120397269 M * complexho have got a few ideas to share I am sure...
1120397280 M * Doener` ok, have fun
1120397371 J * Hollow|mobile ~bene@p5497997E.dip0.t-ipconnect.de
1120397374 M * Hollow|mobile lo
1120397379 M * Doener` wb
1120397535 T * Hollow|mobile http://linux-vserver.org/ | latest stable 1.2.10, devel 1.9.5, 2.0-rc5, ng9.5  -- He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;)
1120397538 M * Hollow|mobile btw..
1120397543 M * Hollow|mobile just saw it ;)
1120397576 M * Doener` -rc5?
1120397580 M * Hollow|mobile yup
1120397871 M * Doener` Hollow|mobile: any idea what the rlimit mask does?
1120398094 M * DaPhreak 12.2 ? eh ...
1120398115 M * Doener` hm?
1120398131 M * DaPhreak yeah :) 2.6.12.2 .. seems like i missed something ;)
1120398138 M * Doener` ah, i c
1120398143 A * DaPhreak 's still at 2.6.11.11
1120398151 M * Doener` 2.6.12 here...
1120398157 M * Hollow|mobile Doener`: i'm no expert with these m just start to understand ;)ask flag things.. i
1120398160 M * Hollow|mobile argh
1120398174 M * Hollow|mobile hope you can read it ^^
1120398190 A * Doener` does some parser adjustments
1120398209 M * Doener` now you h all the time ;)ave to write like that
1120398224 M * Hollow|mobile lol.. i just accidently hit my touchpad :P
1120398246 M * DaPhreak heh ;) yeah .. shitty notebook *g*
1120398835 M * Greek0 I've made available an interface to a guest, but I only want it to be able to listen on port 80 there. is there a way to get this? perhaps via an iptables trick?
1120398847 M * Greek0 or do I have to give the guest a seperate ip for this to work?
1120398890 N * Bertl_zZ Bertl
1120398896 M * Doener` i'd suggest a separate ip address, then you could only do nat on port 80 and be done with it
1120398899 M * Doener` morning Bertl
1120398904 M * Bertl morning folks!
1120399003 M * DaPhreak lo Bertl 
1120399015 M * Greek0 do I have to modify the host config too, or is it sufficient to just use another ip in the client?
1120399029 M * Greek0 127.0.0.2 could probably work..
1120399049 M * Bertl hmm .. those are special (local addresses)
1120399065 M * Bertl (i.e. the kernel handles them specially)
1120399157 M * Greek0 hmm. so just leaving the host config as is (except adding a NAT rule), just giving the client lo/127.0.0.2/255.255.255.255, and firewalling everything from that address but port80 doesn't work?
1120399188 M * Doener` using 10.0.0.2 or sth. like that should work
1120399214 M * Greek0 but the host doesn't need to be configured for that address?
1120399281 M * Hollow|mobile morning Bertl 
1120399322 M * Doener` Greek0: the tools handle that for you
1120399338 M * Doener` of course you need to set the iptables rules yourself
1120399384 M * Greek0 mhm. and do I need nodev in that case or not?
1120399415 Q * eXplasm Quit: Verlassend
1120399426 J * eXplasm explasm@p549F7220.dip.t-dialin.net
1120399427 M * Doener` if you want the tools to setup the address on start and tear it down on stop, you don't want nodev
1120399441 M * Greek0 or, more generally, what should dev be? eth0 (ie. the hosts standard network interface), or eth1 (which I don't really have)?
1120399459 M * Doener` eth0 should be fine
1120399462 M * Bertl Greek0: only devices you have make sense there
1120399467 M * Doener` eth1 won't work
1120399468 M * Greek0 ok
1120399475 M * Bertl Greek0: some folks use dummy0 for 'local' ips
1120399507 M * Greek0 but I won't be able to really transmit data through that, right?
1120399531 M * Bertl no, but the host won't do that for local traffic anyways
1120399585 M * Doener` the routing uses the interface that seems to be able to reach the destination, not the one on which the address is configured
1120399590 M * Greek0 uh, will nat work then? ie a rule that says: port80 -> -o dummy0 guest_ip/80
1120399609 M * Doener` no, dummy0 won't be the out interface
1120399610 M * Bertl no, won't work ...
1120399627 M * Doener` make the nat work on the address/port combination, forget about the interface
1120399714 M * Greek0 but if I configure guest_ip on dummy0, and then make setup nat to forwart to guest_ip/80, it works?
1120399728 M * Doener` yes
1120399747 M * Doener` 	0 - (default) The kernel can respond to arp requests with addresses
1120399748 M * Doener` 	from other interfaces. This may seem wrong but it usually makes
1120399748 M * Doener` 	sense, because it increases the chance of successful communication.
1120399748 M * Doener` 	IP addresses are owned by the complete host on Linux, not by
1120399748 M * Doener` 	particular interfaces. Only for more complex setups like load-
1120399748 M * Doener` 	balancing, does this behaviour cause problems.
1120399778 M * Doener` (from Documentation/networking/ip-sysctl.txt -- section on arp_filter)
1120399805 M * Greek0 ok, so the network stack in the kernel actually doesn't care about interfaces at all?
1120399842 M * Greek0 it's just a bit non-obvious what should happen in the case where you forward to an ip/port that's also present on the same host
1120399847 M * Doener` with the default settings, yes, i'd say so... maybe there are other places where it actually cares
1120399869 M * Doener` you don't forward it, you change the target address before it is routed at all
1120399882 M * Doener` the rule goes into the PREROUTING chain
1120399885 M * Greek0 *bam*
1120399894 M * Greek0 of course..
1120399920 A * Greek0 was thinking too much in terms of NAT, and not in terms of iptables rules
1120399925 A * Doener` just happened to finally understand why Bertl always stresses the fact that packets aren't forwarded :)
1120400022 M * Greek0 judging from what I've seen at bertl's presentation at the local debian user group, I think that quite a lot people have problems wrapping their head around this network stuff
1120400084 M * Doener` Bertl was at a debian user group?
1120400091 A * Doener` adjusts his view on the world...
1120400094 M * Doener` *g*
1120400095 M * Bertl *ssht!*
1120400106 A * Greek0 whistles innocently ;)
1120400270 M * Greek0 should the guest_ip be in the local network range (ie. 192.168.0.0/24 here)?
1120400297 M * Greek0 hmm
1120400316 M * Greek0 or if I use a dummy interface, should dummy0 be created on the host, or is it handled by the tools
1120400415 M * Doener` guest ip can be anything (except from 127.0.0.0/8), if you use an address that's reachable from the other hosts, you can skip the nat part and only block the other ports (of course you then have it listening on that other address)
1120400443 M * Greek0 thanks
1120400505 M * Doener` Bertl: what tells me the result from vc_get_rlimit_mask? i don't really get the meaning behind the values returned in the struct...
1120400592 M * Bertl it returns the 'supported' limits (or it is supposed to do so)
1120400624 M * Bertl 0 = not supported, 1 = supported (limit = n, bit 2^n)
1120400726 M * Doener` what are minimum and softlimit reserved for?
1120400961 Q * nox Quit: leaving
1120400971 M * Bertl for exactly that, min is 'guarantee', soft-limit means penalization, but not resource denial ...
1120400990 J * nox ~nox@noxlux.de
1120401053 M * Bertl okay, off for now, back in an hour or so ...
1120401061 N * Bertl Bertl_oO
1120401135 A * Doener` .oO( hmm, how does that translate to a mask? )
1120401386 M * Greek0 I'm not sure I understand it, but this is my interpretation
1120401407 M * Greek0 vcmd_ctx_rlimit_mask_v0 has 3 members, all uint32_t
1120401428 M * Greek0 those are bitmasks, where the bit is set if the corresponding limit is supported
1120401429 M * Doener` yes, and the maximum field tells which rlimits are supported
1120401444 M * Doener` the minimum and the softlimit are currently set to 0
1120401472 M * Doener` what i don't understand is, in the future, what would a non-zero minimum tell me?
1120401479 M * Greek0 I'm not sure how min makes sense..
1120401481 M * Greek0 yep :)
1120401490 M * Greek0 softlimit seems to make some sense, but I don't get mint
1120401491 M * Greek0 -t
1120401513 M * Doener` what would a nonzero softlimit mask tell me?
1120401542 M * Doener` i know what a nonzero minimum/softlimit for a specific rlimit tells me, but not within the mask...
1120401578 M * Doener` if it means "for rlimit X there is a minimum/softlimit set" then that would have different semantics than the maximum field...
1120401579 M * Greek0 you mean how support for min/softlimit of a specific rlimit translates to the mask?
1120401596 M * Doener` ah! d'oh!
1120401604 M * Greek0 are we talking about the mask or about the limits itself?
1120401629 M * Doener` currently there's no support for the min/softlimit values, and they might get added one-by-one, so you can ask whether each one is supported...
1120401637 M * Doener` damn, i'm so stupid sometimes...
1120401654 M * Greek0 exactly (i mean your technical description, not your later assertation) ;)
1120401667 M * Doener` heh :)
1120401709 M * Greek0 (2 << VLIMIT_NSOCK) & mask.softlimit
1120401711 M * Greek0 e.g.
1120401728 M * Doener` s/2/1/
1120401736 M * Greek0 d'oh
1120401741 M * Greek0 of course :)
1120401775 A * Doener` likes to mess up 2^X and 1 << X, too
1120401783 M * Doener` (^ = to the power of)
1120401792 M * Doener` s/mess/mix/
1120401801 M * Greek0 oh, 2^X is really evil in c
1120401836 M * Doener` yeah, evil binary operations
1120401862 M * Doener` i didn't mean C's ^, but pow(2,X) looks strange ;)
1120401878 M * Greek0 yep
1120401881 M * Greek0 python has 2**x
1120401917 M * daniel_hozac well, C has 1 << X ;)
1120401927 M * Doener` see above ;)
1120401952 M * Greek0 daniel_hozac: well, python also has 1<<X, but also 3**17 or 3513**5
1120402153 M * Greek0 port forwarding is now working, but it doesn't work from the local machine. is there some evil iptables trick I can pull to achieve that?
1120402733 J * rs ~rs@sat78-1-82-232-43-227.fbx.proxad.net
1120402867 Q * matti Ping timeout: 480 seconds
1120402896 J * matti matti@linux.gentoo.pl
1120403802 Q * Hollow|mobile Quit: Leaving
1120404199 Q * rs Ping timeout: 480 seconds
1120404604 J * [maple] ~maple@strace-nat0.ua-online.net
1120405383 N * Bertl_oO Bertl
1120405400 M * Bertl Greek0: what is your 'forwarding' rule?
1120405717 M * Greek0 iptables -t nat -A PREROUTING -p tcp --dport 88 -j DNAT --to 10.0.0.2
1120405727 M * Greek0 port 88 instead of 80 for testing.
1120405749 M * Greek0 but it doesn't work from localhost, since outgoing packets don't go through prerouting iirc
1120405774 M * Bertl you want to mangle local packets?
1120405876 M * Greek0 yeah, when I type nc 127.0.0.1 88 or nc 192.168.0.2 88 (both the same), I want to get a connection to the apache running on 10.0.0.2:88
1120405921 M * Bertl well, ahve you local mangling enabled in the kernel?
1120405946 M * Bertl (IIRC it's now called full NAT and/or ETB tables)
1120405964 M * Greek0 no, but I can. I think I'll recompile my kernel anyway, to get the dummy network device
1120406002 M * Bertl okay, in this case you want a mangle rule (on output)
1120406009 J * rs ~rs@sat78-1-82-232-41-50.fbx.proxad.net
1120406054 M * Bertl evening rs!
1120406060 M * rs hi bertl
1120406063 M * Bertl okay, dinnertime ... back later ...
1120406070 M * Greek0 thanks Bertl
1120406070 N * Bertl Bertl_oO
1120406076 M * rs enjoy your meal
1120411059 Q * Greek0 Quit: leaving
1120411344 J * Greek0 ~greek0@81.189.246.175
1120413589 J * pzYsTorM schak@dsl-213-023-233-143.arcor-ip.net
1120413682 M * pzYsTorM hi, short question. i habe enabled CAP_NET_RAW and tcp_dump displays ALL traffic (from the host, too!)... although if i bind to the vserver-interface... bug or feature? ;)
1120413685 M * pzYsTorM -b+v
1120413796 M * daniel_hozac that's why CAP_NET_RAW is strongly discouraged ;)
1120413814 M * pzYsTorM but... how do i make tcpdump display only the v-traffic?
1120413938 M * pzYsTorM if i disable CAP_NET_RAW i cannot execute tcpdump
1120413953 M * Doener` that's a nogo until ngnet is ready
1120414024 M * pzYsTorM what is ngnet?
1120414048 M * Doener` next generation networking
1120414065 M * pzYsTorM hehe ok
1120414174 M * pzYsTorM and when will this be?
1120414177 M * pzYsTorM approx.
1120414371 Q * rs Quit: rs
1120414391 M * DaPhreak when it's done ;)
1120414421 M * DaPhreak Bertl said once, (yeah i know _once_) he would like to do this after the release of 2.0
1120414532 M * pzYsTorM *sigh*
1120415288 Q * ascendancy Quit: —I-n-v-i-s-i-o-n— 2.0 Build 3515
1120415292 M * DaPhreak but thats only *AFAIK*
1120415571 M * Doener` he also said that it would be a good idea to reimplement it on 2.6.12+ because a) the patch got broken and b) there are some changes in the network code in the vanilla kernel
1120416497 J * rs ~rs@sat78-1-82-232-43-227.fbx.proxad.net
1120417478 M * Hollow Doener`: didn't you want to write a prototypes suggestion?
1120417493 M * Doener` still at it, girlfriend came for a visit
1120417508 M * Hollow oh, too bad ;)
1120417512 M * Hollow babes are evil
1120417513 M * Doener` not at all
1120417514 M * Hollow ;)
1120417545 Q * rs Quit: rs
1120418029 M * Doener` Hollow: http://www.13thfloor.at/~doener/vserver/tools/proto
1120418093 M * Doener` i removed some functions that are using old versions of the same function, made some calls accept more parameters instead of a struct and added some typedef's
1120418113 M * Doener` the typedef's could probably as well be self-defined structs...
1120418150 M * Hollow yup... i'm thinking of sth like using own structs and define them depending on the choosen API
1120418164 M * Hollow just wrt api compatibility
1120418176 M * eXplasm i have a problem ... on a server reboot, the screen is full with "eth0: NULL pointer encountered in Rx ring, skipping" msgs ... totally crashed
1120418192 M * eXplasm is that an vserver bug/problem?
1120418201 M * Doener` hm, if the lib changes its struct in some unfortunate way, all the programs using the lib will break...
1120418247 M * Doener` eXplasm: does not look like one... kernel version?
1120418263 M * eXplasm 2.6.11 or so =D i dont know
1120418289 M * Doener` uname -r?
1120418309 M * eXplasm i have no access to the server at the moment
1120418333 M * eXplasm your friend Mr Oliver Dzombic is working on it *fg*
1120418335 M * Doener` what nic?
1120418366 M * eXplasm thats a very good question, wait
1120418400 M * eXplasm nobody knows it, damn
1120418421 M * Doener` google says the sis900 driver is broken and may lead to that in some cases...
1120418459 M * eXplasm hmm, i thought that there are an sis board, with an nic onboard
1120418464 M * eXplasm think
1120418541 M * Hollow Doener`: with shared libraries you can just simply bump the version if the api changes, and let your programs decide to which library to link
1120418614 M * Doener` Hollow: as of now, we don't have one ;) but right...
1120418619 Q * prae Quit: Pwet
1120418619 M * Hollow haha, right ;)
1120418872 M * Doener` defining our own structs is needed then anyways, as we can no longer afford to have a connection to the kernel headers should they ever change in a significant way...
1120418886 M * Doener` like struct X becoming X_v0
1120418949 M * Doener` Hollow: any objections against the prototypes? if not, i'll change that stuff (including the drop of old functions)
1120418976 M * Hollow wait a sec
1120418978 M * Doener` (btw, i didn't touch the dlimit stuff and left out the vc_net_{add,remove} functions)
1120418996 A * Doener` will wait a minute
1120418998 M * Hollow what are these for?
1120419000 M * Doener` ;)
1120419019 M * Hollow you're so generous ;)
1120419022 M * Doener` vc_net_*? ngnet IIRC, not implemented yet
1120419035 M * Hollow hm
1120419053 M * Doener` for the dlimit stuff, i've just been lazy ;)
1120419071 M * Doener` but would end up with a temporary typedef as well i guess...
1120419085 M * Hollow is the stuff in network_cmd.h really ngnet? i don't think so
1120419094 M * Doener` not all, but parts of it IIRC
1120419270 M * Hollow isn't this the stuff chbind is supposed to use (though it uses legacy code...)
1120419472 M * Doener` that is vc_set_ipv4root
1120419480 M * Doener` there's no non-legacy network code yet
1120419559 M * Hollow but network.c and ngnet.c don't look similar in any way...
1120419631 M * Doener` because network.c is the legacy code and ngnet.c is, well, ngnet
1120419654 M * Hollow the legacycode is in legacynet.c
1120419715 M * Doener` hm, that was moved then (maybe even some time ago... i just didn't notice)
1120419752 M * Hollow Bertl_oO: please comment on legacynet.c and network.c difference...
1120419766 M * Hollow afk now... i'm hungry
1120419785 M * Doener` enjoy your meal
1120420032 M * Hollow ha! have to make it first...
1120420045 M * Hollow damn
1120422349 M * Hollow Doener`: http://home.xnull.de/work/libvserver/prototypes.h
1120422564 M * Doener` any significant changes? (except the _t suffixes)
1120422588 M * Hollow s/vc_/vs_/
1120422594 M * Hollow own struct names
1120422640 M * Hollow and changed sched struct to bucket
1120422658 M * Hollow s/net/ntx/
1120422670 M * Hollow that's it
1120422724 M * Doener` hmm... typedef struct vc_cflags cflags_t;
1120422733 M * Doener` where does struct vc_cflags come from?
1120422883 M * Hollow has to be defined
1120422918 M * Doener` hm, then we could scrap the typedef...
1120422981 M * Doener` those were just there to hide the vcmd_* structs
1120423010 M * Hollow yup
1120423097 M * Doener` btw, the vx_/nx_ prefixes were chosen because the kernel uses those. and IMHO struct vx_caps is better than struct ccaps, because ccaps is just part of the struct
1120423108 M * Doener` (in my prototypes that is)
1120423180 M * Hollow hm
1120423196 M * Hollow so prefix all structs with vx_?
1120423199 M * Hollow or nx
1120423216 M * Doener` vx_ for the process contexts, nx_ for the network contexts
1120423239 M * Doener` i.e. instead of cflags/nflags, we get vx_flags, nx_flags
1120423479 M * Hollow ok
1120423544 M * Hollow reload the file
1120423671 M * Doener` you changed just the first two, right?
1120423674 M * Hollow yup
1120423681 M * Doener` ok, just verifying ;)
1120423689 M * Hollow ;)
1120423732 M * Doener` now the bucket thing. we might later get more token buckets, not just the current scheduler token bucket...
1120423742 M * Hollow i.e.?
1120423746 M * Hollow erm..
1120423748 M * Hollow e.g. ;)
1120423784 M * Doener` let me check irc logs...
1120423830 M * Doener` Jul 05 00:36:51 <Bertl> for example to protect agains fork bombs in an effective way ...
1120423850 M * Doener` Jul 05 00:44:55 <Bertl> so, to get to the point, my idea is to use token buckets for such system intense operations ...
1120423883 M * Doener` Jul 05 00:45:27 <Bertl> for example, a context gets 100 tokens per second for forking, and requires 1 token for each fork ...
1120423883 M * Doener` Jul 05 00:45:52 <Bertl> a total of 500 tokens can be accumulated ...
1120423910 M * Hollow ah.. ok
1120423937 M * Doener` maybe vx_sched_bucket?
1120423969 A * Hollow nods
1120424026 M * Hollow should we prefix functions with vs_ or vc_?
1120424061 J * yarihm ~yarihm@80-218-6-221.dclient.hispeed.ch
1120424076 M * Doener` the kernel has vc/vx/nx and AFAIK those mean: vc = "vserver call" (since we have only one syscall), those are the functions you "call from userspace"
1120424081 M * Doener` vx = context related
1120424087 M * Doener` nx = network context related
1120424101 M * Hollow so maybe we'd name them vc_
1120424127 M * Doener` vc_ would be nearest to the kernel
1120424253 M * Doener` we could also make those vx/nx, as we don't really have the vc_ semantics in the lib... opinions will differ ;)
1120424287 M * Doener` i.e. vx_create, nx_create, vx_info, nx_info, vx_get_flags, nx_get_flags (note the missing n/c in front of "flags")
1120424298 M * Doener` s/i.e./e.g./
1120424304 M * Hollow mhm
1120424314 M * Hollow i'd like this approach
1120424367 M * Doener` it's more centered around the entities we have (vx and nx)
1120424672 M * Hollow Doener`: ok, take another look
1120424834 M * Doener` looks good
1120425129 M * Hollow will bcaps remain bcaps or is the name still a subject of change?
1120425208 M * Doener` hm, that was only subject to change in the util-vserver configuration, wasn't it?
1120425285 M * Hollow ah ok..
1120425298 M * Hollow do we leave it as bcaps? ;)
1120425306 M * Doener` i'd say so
1120425324 M * Hollow ok
1120425400 Q * _ag_ Ping timeout: 480 seconds
1120425454 M * Doener` ok, should one of us do the vx stuff and the other one the nx stuff?
1120425491 M * Hollow nx is quite small isn't it?
1120425509 M * Hollow the rlimit struct confuses me
1120425596 J * _ag_ ag@caladan.roxor.cx
1120425621 M * Doener` heh :) check irc logs from today ;)
1120425626 M * Hollow yeah.. :P
1120425681 Q * _ag_ Quit: 
1120425689 J * _ag_ ag@caladan.roxor.cx
1120425815 J * are|lunch ~are@dsl-084-056-149-128.arcor-ip.net
1120425912 M * Hollow Doener`: reload
1120426051 M * Doener` looks good
1120426062 M * Doener` now we need the dlimit stuff, for which i've been too lazy ;)
1120426067 M * Hollow heh
1120426205 Q * _are_ Ping timeout: 480 seconds
1120426231 M * Doener` hm, struct vx_dlimit and vx_dlimit_base and just copy the other structs I'd say...
1120426280 M * Doener` hm, the #ifdefs don't make much sense the way they are...
1120426307 M * Doener` if we don't #define API20, vx_get_info will throw an error, because struct vx_info is not defined
1120426308 M * Hollow Doener`: yep :P
1120426322 M * Hollow configure should set API20 in config.h
1120426332 M * Hollow Doener`: reload, i added dlimit
1120426574 M * Doener` hm, if i'd knew how the name is related to the rest in the dlimit structs i could say if it's fine with me to move that outside the struct ;)
1120426720 A * Hollow shrugs
1120426732 M * Hollow name is the mountpoint now?
1120426737 M * Hollow or the dir to limit
1120426766 M * Doener` dunno... never took the time to read the dlimit code
1120426799 M * daniel_hozac mountpoint.
1120426813 M * daniel_hozac (which is the dir to limit ;))
1120426859 M * Hollow yup..
1120426918 M * Hollow so the prototype should be ok
1120426982 M * Hollow but why is there "flags" in the dlimit struct...
1120426991 M * Hollow isn't it enough to pass it to the dlimit_base struct?
1120427310 Q * _ag_ Quit: leaving
1120427472 Q * yarihm Quit: Leaving
1120427572 J * _ag_ ag@caladan.roxor.cx
1120427594 M * daniel_hozac i don't think the dlimit's flags are used anywhere.
1120427777 N * aba_ aba
1120428031 M * Hollow Doener`: ok.. prototypes.h is finished.. at least wrt to me
1120428033 M * Hollow ;)
1120428082 M * Greek0 Hollow: where is it available?
1120428092 M * Hollow http://home.xnull.de/work/libvserver/prototypes.h
1120428130 A * Doener` doesn't like the API20 defines...
1120428137 M * daniel_hozac why no int?
1120428169 M * Hollow no int?
1120428177 M * daniel_hozac return value
1120428185 M * Hollow oh..
1120428186 M * Hollow *g*
1120428192 M * Hollow we forgot the return values
1120428209 M * Doener` i left those out, because all were ints... didn't intend to have my version because an actual header file ;)
1120428232 M * Doener` Hollow: btw, you have a lot whitespace in your code ;)
1120428238 M * Doener` >---
1120428238 M * Doener` >---/* type definitions */
1120428238 M * Doener` >---typedef uint32_t xid_t;
1120428238 M * Doener` >---typedef uint32_t nid_t;
1120428238 M * Doener` >---
1120428264 M * Doener` (the >--- are tabs)
1120428288 M * daniel_hozac why doesn't vx_dlimit have a flags field?
1120428328 M * daniel_hozac and maybe name should be mount_point or something more descriptive than name (for dlimit, iattr, etc.) ;)
1120428330 M * Hollow Doener`: yup, and i hate to not indent empty lines in a block
1120428373 M * Doener` any specific reason why?
1120428393 M * Hollow because you indent the rest of the block too
1120428424 M * Hollow ok, i removed the API20 defines for now
1120428498 M * matti Hollow: ;)
1120428498 M * Hollow gtg to bed... history test tomorrow... and i learned absolutely nothing haha
1120428508 M * matti Doener`: ;)
1120428509 M * Doener` good luck then
1120428519 M * Doener` matti: :]
1120428524 M * matti ;]
1120428528 M * Hollow pray that my niehgbour has learned :P
1120428539 M * matti Hollow: I'll cross my fingers ;]
1120428542 M * matti Hollow: Hehhee.
1120428542 M * Hollow heh
1120428588 M * Hollow n8 all
1120428602 M * matti Hollow: Sleep well.
1120428606 M * Doener` g'night
1120428829 J * Aiken ~james@tooax7-041.dialup.optusnet.com.au
1120428890 J * rs ~rs@m216.net81-66-20.noos.fr
1120429099 Q * rs Quit: 
1120430202 J * ShoX0Shadow ~test@0x503e21ac.arcnxx10.adsl-dhcp.tele.dk
1120430244 P * ShoX0Shadow 
1120431776 J * shuri shuri@64.235.209.226
1120432461 Q * pzYsTorM Quit: 
1120434051 Q * click Read error: Connection reset by peer
1120434054 J * click click@dsl-static-122-208.aal.tiscali.no
1120434600 Q * Pazzo Quit: bye
1120434908 J * rs ~rs@m216.net81-66-20.noos.fr