1136419251 P * stefani I'm Parting (the water)
1136419253 M * undefined bertl, bwana: what are the problems with the debian packages?
1136419280 M * bwana i hear they don't work
1136419302 M * undefined just curious as i'm using the 2.6.10 ubuntu kernel (can't remember what ubuntu release that was included in) and the 1.9.5 patch from kernel-patch-vserver in debian stable/sarge
1136419323 M * undefined the util-vserver package in sarge worked for me, too
1136419328 M * Bertl well, they fail in dubious ways ... and do not work on most archs, and, most improtant, they are outdated
1136419340 M * undefined i only backported the newer version because i wanted vhashify
1136419380 M * undefined bertl: yeah, outdated (vserver patch) i can attest to
1136419408 M * undefined bertl: haven't had a failure yet with 7 or so vservers on an amd64 host
1136419432 M * undefined but then again i'm not stressing them (yet)
1136419435 M * Bertl undefined: 0.30.204 tools?
1136419476 M * undefined bertl: don't remember, dont' have access to that box, and packages.debian.org is down currently
1136419497 M * undefined bertl: 208 i think is in sarge, with 209 in unstable (maybe?)
1136419511 M * Bertl you wish!
1136419545 M * undefined bertl: i just remember the 8 & 9 being the least significant digit (or at least i think that's what i remember ;))
1136419562 M * Bertl well, regarding the kernel patches, you can get a feeling here: http://linux-vserver.org/ChangeLog26
1136419743 M * undefined bertl: after the release of vserver 2.0 i patched ubuntu's "main" 2.6.12 kernel but haven't switched to that on my server as 2.6.10 works fine
1136419803 M * undefined bertl: i'm currently trying to backport 2.01 to 2.6.12 so i can stay with a distro-supported kernel but have the fixes of 2.01
1136419820 M * undefined bertl: is vserver kernel patches maintained in cvs?
1136419924 M * undefined bertl: in backporting 2.01 from 2.6.14 to 2.6.12 it would be helpful if i had some insight into what changes were made for what reasons, as i'm having difficulty trying to decipher which changes between 2.0 and 2.01 are because of bug fixes and which are because of the newer kernel
1136419958 M * undefined bertl: and i was hoping cvs (commit comments) could unlock that mystery
1136420098 M * Bertl undefined: no, cvs commits would not give you any insight
1136420117 M * Bertl aside from that, the patches are not maintained via cvs
1136420129 M * undefined bertl: ok
1136420149 M * Bertl but you can get better stuff from:
1136420163 M * Bertl http://vserver.13thfloor.at/Devel/
1136420194 M * Bertl each one of those patches should be 'obvious'
1136420202 M * undefined bertl: sorry, 0.30.204 in sarge (you were right), and 0.30.209 in unstableb (from http://packages.qa.debian.org/u/util-vserver.html)
1136420216 M * undefined bertl: thanks for the pointer, i'll have to look at that
1136420247 M * Bertl all patches in a dir should make up the relevant modifications regardless of the kernel version
1136420715 P * undefined 
1136421336 Q * Doener Quit: Leaving
1136422937 J * undefined ~undefined@adsl-68-93-109-94.dsl.rcsntx.swbell.net
1136423806 M * anonc Bertl: revisiting an old bugbear - does the cpu token bucket mechanism have any useful effects in limiting disk io hogs or are the various io schedulers currently a better place to go for a feature like that?
1136424027 M * Bertl recent devel versions have 'per-context' CFQ support
1136424049 M * Bertl (so you will get fair scheduling for I/O when you enable CFQ)
1136424196 M * anonc no /etc/vservers/... configuration required for that?
1136424207 M * Bertl nothing to configure :)
1136424242 M * Bertl it basically creates a cfq queue per context
1136424423 Q * bwana Quit: adios
1136424788 M * anonc huzza!
1136424883 M * anonc incidentally - you know that discussion about how the gentoo init-style has been removed from hollow's version of the tools. What would be the way to get the init output to display on the host console using the plain init style (its good to know when init scripts fail to start)
1136424898 M * anonc is that a distro specific thing or a vserver config thing?
1136425022 M * Bertl well, neither nor ... it is basically an init thing
1136425082 M * Bertl the sysv style is the only one which executes the scripts 'by hand' so there you will get the output of the scripts on stdout
1136425155 M * anonc so potentially it could be down to me changing the vserver baselayout to use an init that does what I want
1136425222 M * Bertl well, IIRC, then the gentoo init style was some attempt to get 'sysv' behaviour for gentoo dependancy stuff
1136425286 M * anonc ahh ok
1136425336 M * Bertl in the future we might attack this by 'adding' a virtual console/terminal (or soemthing like that)
1136425361 M * Bertl (but IMHO it's not worth the efford)
1136425408 M * anonc i understand
1136426023 N * lchvdlch lchvdlog
1136426100 M * lchvdlog Bertl: I'm going with cross fingers, hoping ext3 will do well
1136426102 M * lchvdlog g'nite all
1136426116 M * Bertl lchvdlog: night!
1136426221 M * anonc nite!
1136426247 P * anonc adios
1136426261 J * anonc ~anonc@staffnet.internode.com.au
1136426333 P * anonc adios
1136426340 J * anonc ~anonc@staffnet.internode.com.au
1136426452 J * aj__ ~aj@dslb-084-058-197-235.pools.arcor-ip.net
1136426876 Q * aj_ Ping timeout: 480 seconds
1136427191 Q * sladen Ping timeout: 480 seconds
1136427220 J * sladen paul@starsky.19inch.net
1136427280 J * aT\\Switch`aus ~snipernet@c210-49-18-45.hillc1.qld.optusnet.com.au
1136427289 Q * aT\\Switch`aus Quit: 
1136428347 Q * hwarrier Quit: 
1136436392 Q * anonc Quit: adios
1136437190 J * stefani ~stefani@c-24-19-46-211.hsd1.wa.comcast.net
1136439258 P * stefani parting (is such sweet sorrow)
1136439573 M * Bertl okay, enough for today ... off to bed now ... have a nice whatever everyone!
1136439580 N * Bertl Bertl_zZ
1136440261 Q * marl_ Ping timeout: 480 seconds
1136440624 J * tudenbart ~willi@xdsl-213-196-252-179.netcologne.de
1136441061 Q * dothebart Ping timeout: 480 seconds
1136441284 P * undefined 
1136441847 J * infowolfe_ infowolfe@209-112-210-87-cdsl-rb1.nwc.acsalaska.net
1136441928 Q * Chris^ Read error: Connection reset by peer
1136442163 J * Chris^ ~chris@nightcrawler.symour.hu
1136442217 Q * infowolfe Ping timeout: 480 seconds
1136443989 J * balbir ~balbir@59.145.136.1
1136444051 Q * _are_ Quit: bbl
1136444708 J * cryo ~say@212.86.233.146
1136451245 Q * derjohn Remote host closed the connection
1136452154 J * meandtheshell ~markus@85-124-12-17.dynamic.xdsl-line.inode.at
1136453646 J * shedi ~siggi@tolvudeild-201.lhi.is
1136454731 J * prae ~prae@ezoffice.mandriva.com
1136454924 J * marl ~matt@84.92.193.226
1136455776 J * Smutje ~Smutje@xdsl-87-78-40-19.netcologne.de
1136455886 Q * Smutje_ Ping timeout: 480 seconds
1136456930 J * Doener doener@i5387D65F.versanet.de
1136458780 J * lilalinux ~plasma@80.69.35.186
1136459006 Q * shedi Ping timeout: 480 seconds
1136459647 J * shedi ~siggi@tolvudeild-197.lhi.is
1136461068 Q * cryo Remote host closed the connection
1136463657 J * cryo ~say@212.86.233.146
1136471517 J * wes weasel@asteria.debian.or.at
1136471696 P * Chris^ 
1136472732 Q * cryo Ping timeout: 480 seconds
1136473149 J * menomc ~amery@200.75.27.90
1136473256 Q * mnemoc Ping timeout: 480 seconds
1136473257 N * menomc mnemoc
1136473474 Q * wes Ping timeout: 480 seconds
1136473485 J * cryo ~say@212.86.233.146
1136473652 Q * Vudumen Ping timeout: 480 seconds
1136473878 J * Vudumen vudumen@perverz.hu
1136473987 J * spd1snd ~psingh@68-232-133-13.chvlva.adelphia.net
1136474084 M * spd1snd i created a new vserver on my gentoo box using one of the stage3 builds-- followed the gentoo howto.... now i cant get apache to start inside the vserver. it seems to think that something else is bound to the IP... there is no other websrver in this vserver or on the host machine it self ... any ideas?
1136474666 M * dreamist what is your Listen statement in your httpd.conf?
1136474767 M * spd1snd Listen IP:80 ... so if ip was 12.34.56.78, then it looks like Listen 12.34.56.78:80
1136474808 M * spd1snd sorry, and its set to the IP of the vserver guest that apache is installed inside of
1136474844 Q * mugwump Ping timeout: 480 seconds
1136474973 Q * balbir Quit: Leaving
1136475093 J * PilatomiK ~tek@ADijon-151-1-141-101.w86-204.abo.wanadoo.fr
1136475124 M * PilatomiK hello
1136475273 M * PilatomiK I would like use mount -t shfs on vserver system's but I read on the net it's not possible. it's true ?
1136475954 Q * PilatomiK Remote host closed the connection
1136476016 J * mugwump ~samv@watts.utsl.gen.nz
1136476021 N * lchvdlog lchvdlch
1136476028 M * lchvdlch morning all
1136476566 N * Bertl_zZ Bertl
1136476570 M * Bertl morning folks!
1136476578 J * shuri ~shuri@64.235.209.226
1136476605 A * Bertl .o( what is shfs? )
1136476653 M * Bertl welcome shuri! LTNS!
1136476682 M * SiD3WiNDR filesystem over ssh
1136476716 M * Bertl aha, and where does it plug into the kernel (if at all?)
1136476944 M * shuri Hola Bertl 
1136476954 M * shuri YES LTNS
1136476962 M * shuri still alive:)
1136477074 M * SiD3WiNDR no idea Bertl 
1136477076 M * SiD3WiNDR shfs.sf.net
1136477085 M * SiD3WiNDR I just dpkg-buildpackage it ;)
1136477175 M * Bertl shuri: here because of issues? or just visiting?
1136477204 M * Bertl SiD3WiNDR: Shfs is a simple and easy to use Linux kernel module ...
1136477247 M * shuri visiting :)
1136477255 M * Bertl so the answer is, well, if you make the code linux-vserver secure, yes, you can use it
1136477305 M * shuri Bertl, we running 2.6.14.3-vs2.0.1 without any issues
1136477339 M * Bertl excellent!
1136477340 M * shuri good worlk as always
1136477352 M * Bertl thanks!
1136477421 M * SiD3WiNDR 2.6.14.5-vs2.0.1 here, also running great
1136477505 M * shuri still running 2.4.30-vs1.2.10 on some prod server
1136477517 M * Bertl yeah, I compiled a 2.6.14.5-vs2.0.2pre yesterday, works great too :)
1136477562 M * Bertl SiD3WiNDR, shuri: positive feedback _is_ really appreciated, it gives a good bias for reported issues ...
1136477582 M * Bertl (i.e. where to look first, system or patches :)
1136477599 M * SiD3WiNDR I ran an rc before and didn't patch the sendfile thing, that majorly broke my proftpd though ;)
1136477743 M * Bertl yeah, not unexpected ... more and more apps start using sendfile
1136477791 M * SiD3WiNDR well it broke in a weird way
1136477802 M * SiD3WiNDR just kept sending more and more data, I dunno where it came from
1136477811 M * SiD3WiNDR a file of 3MB kept going after 700MB I stopped it ;)
1136477861 J * _are_ ~are@62.112.159.81
1136477955 M * dreamist Bertl: the UP kernel crashed last night eventually also ;-)
1136478085 M * Bertl dreamist: ah, good, so we are now down to driver and hardware, yes?
1136478149 J * MHGuest728 ~MHGuest72@212.122.237.46
1136478182 M * Bertl welcome MHGuest728!
1136478191 M * MHGuest728 thanks
1136478206 M * _are_ hi
1136478214 M * MHGuest728 i have a question all
1136478219 M * MHGuest728 if any body can help me
1136478241 M * MHGuest728 it' about the AT commands
1136478377 M * Bertl hey _are_!
1136478380 M * _are_ i am sure we can't answer unless you posted the question :-)
1136478393 M * MHGuest728 :D
1136478393 M * Bertl MHGuest728: I don't remember linux-vserver using AT commands?
1136478401 M * MHGuest728 i am just waiting if any one say that he cn help
1136478402 M * MHGuest728 :D
1136478412 M * MHGuest728 no it's not a linux server
1136478415 M * MHGuest728 ita GPRS modem
1136478441 M * MHGuest728 i want to make it ping automaticly on a certine IP
1136478452 M * MHGuest728 any one know this command
1136478459 M * MHGuest728 or if it's possible or not
1136478460 M * MHGuest728 ?
1136478464 M * Bertl you should try the #offtopic channel
1136478481 M * _are_ afaik this has nothing to do with AT commands. you use the AT command to dial up, but you need some ping-utility to do the ping
1136478504 M * mnemoc i guess all know that
1136478535 M * mnemoc but how that relates to vserver?
1136478539 M * MHGuest728 but i am already have a command that i put i nthe chat script
1136478541 M * MHGuest728 in the route
1136478543 M * MHGuest728 ran d i can ping
1136478553 M * MHGuest728 but only one ping nad i want it infinty
1136478565 M * MHGuest728 sorry for that
1136478574 M * MHGuest728 i just don't know any rom that i cn g 
1136478582 M * MHGuest728 it my frist day in that website
1136478589 M * MHGuest728 thanks any way
1136478593 M * MHGuest728 i will try this room
1136478594 M * MHGuest728 byebye
1136478605 M * Bertl MHGuest728: well, I know, this is a very friendly channel, and there are many people here, but you should really look for a channel where this would be on-topic
1136478636 M * MHGuest728 i will
1136478636 M * Bertl MHGuest728: we wish you luck in your search, may you find all your answers!
1136478642 M * MHGuest728 thanks  for ur advice
1136478647 Q * blackfire Ping timeout: 480 seconds
1136478655 M * MHGuest728 i wish :)
1136478843 J * stefani ~stefani@superquan.apl.washington.edu
1136478871 M * Bertl welcome stefani!
1136479036 M * Bertl okay, off for dinner, back shortly ...
1136479040 N * Bertl Bertl_oO
1136479170 J * blackfire blackfire@dp70.internetdsl.tpnet.pl
1136479180 M * stefani salut
1136479622 Q * MHGuest728 Quit: MHGuest728
1136479860 J * wasser ~wasser@ip86.ipax.at
1136480261 Q * Doener Ping timeout: 480 seconds
1136480297 J * Doener doener@i5387D8E7.versanet.de
1136480594 Q * shedi Quit: Leaving
1136482110 J * undefined ~undefined@adsl-68-93-109-94.dsl.rcsntx.swbell.net
1136482110 Q * ntrs Read error: Connection reset by peer
1136482111 J * ntrs ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com
1136482171 Q * aba Write error: connection closed
1136482245 Q * zobel Write error: connection closed
1136482266 J * ntrs_ ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com
1136482321 Q * ntrs Read error: Connection reset by peer
1136482637 J * zobel zobel@zobel.irc.ftbfs.de
1136483068 J * aba ~aba@eos.turmzimmer.net
1136483301 Q * _are_ Ping timeout: 480 seconds
1136483872 J * shedi ~siggi@inferno.lhi.is
1136484146 P * spd1snd 
1136484231 Q * prae Quit: Execute Order 69 !
1136484359 J * _are_ ~are@62.112.159.81
1136485134 J * dothebart ~willi@xdsl-213-196-251-195.netcologne.de
1136485575 Q * tudenbart Ping timeout: 480 seconds
1136486511 J * emp ~emp@70.57.239.35
1136486565 M * emp what is the best table to put a rule in IP tables to mark a packet coming from a vserve?  I tried mangle/prerouting but that did now work..
1136486575 M * mnemoc mangle
1136486592 M * emp err now -> not
1136486622 M * mnemoc mangle works here
1136486683 M * emp hmm
1136486963 M * emp is there a difference in how ip rules would be applied to a vserver client vs a machine NATed behind the host vserve?
1136487236 J * prae ~benjamin@sherpadown.net
1136487266 M * mnemoc i see no difference
1136487289 M * mnemoc welll, yes. vserver doesn't NAT 
1136487303 M * mnemoc as routers don't NAT... unless you set it to do that
1136487331 M * emp I have the host vserver setup to do SNAT w/ iptables
1136487496 M * mnemoc yes
1136487650 M * emp well it does looks like I am getting packets that are tagged... maybe it is the ip rule that is not picking them up like I want ?
1136487807 M * mnemoc probably
1136487830 N * Bertl_oO Bertl
1136487839 M * Bertl back now .. after a nice bath :)
1136487852 M * mnemoc thanks god
1136487861 M * harry i can [sm|t]ell
1136487862 M * harry ;)
1136488512 M * bubulak :)
1136488525 M * bubulak plastic duck its best :)
1136488737 M * emp what is the best way to configure a vserver to use a custom routing table
1136488786 M * mnemoc -s $vserver_ip
1136488789 M * Bertl emp: http://archives.linux-vserver.org/200311/0470.html
1136488856 M * mnemoc nice 'mini-howto'
1136489596 M * Bertl soo, have you folks (currently here) some time to talk about a new virtual filesystem for linux-vserver?
1136489653 M * Bertl I'm especially intested in comments from eyck, mnemoc, shuri ...
1136489668 M * mnemoc new virtual filesystem for linux-vserver?
1136489684 M * Bertl the idea is to move the stuff from proc elsewhere
1136489727 M * Bertl (and in this process cleanup the interfaces and extend the available information)
1136489825 M * Bertl .o( hey MM's birthday and viva plus celebrates it :)
1136489827 M * mnemoc why not at proc? all linux have /proc
1136489829 M * dhansen Bertl: any reason it needs to be a _new_ filesystem?
1136489854 M * Bertl dhansen: well, the problem with proc is that it is very complicated and inefficient (legacy issues)
1136489869 M * mnemoc i thought you were talking about a fs for /vservers/*/ :p
1136489884 M * Bertl dhansen: so I've been investigating the debugfs for some time now, and something like this seems very appropriate
1136489889 M * mnemoc Bertl: is /sys better ?
1136489933 M * Bertl mnemoc: sysctl (/sys) will be used for the debug options and such (the interfaces there seem quite optimal to me)
1136489943 M * dhansen Bertl: I have been planning to go make proc mountable multiple times
1136489961 M * dhansen so, each vserver would get a real, private, /proc
1136489962 M * Bertl dhansen: well, we already do that for 3 years?
1136489995 M * dhansen I mean in mainline :)
1136490035 M * mnemoc linux mainline or vserver mainline? what do you mean?
1136490038 M * Bertl yeah, no problem with that, for process isolation that would be a good idea, but IMHO /proc is for processes. period.
1136490042 M * dhansen Linux mainline
1136490081 M * Bertl so, I'm not taling about moving the processes out of /proc, I want to move the /virtual and /virtnet out of proc
1136490086 M * Bertl *talking
1136490104 M * dhansen ahh, ok.  yeah, those do need to go
1136490114 M * mnemoc Bertl: mount /dev/vserver/$xid /etc/vservers/$name/info ?
1136490126 M * dhansen  /sys is the place for those, especially since virtnet is a device
1136490139 M * Bertl dhansen: it is?
1136490154 M * dhansen Bertl: if it's a device, it needs to go in /sysfs
1136490162 A * Bertl .o( I must have missed some parts of my code then :)
1136490163 M * dhansen then, you get all of the stuff like hotplug events for free
1136490187 M * dhansen ... out to lunch, be back in a bit
1136490190 M * Bertl dhansen: virtnet is basically the same for network contexts :)
1136490198 J * Aiken ~james@tooax8-209.dialup.optusnet.com.au
1136490218 M * Bertl welcome Aiken! care to join our discussion?
1136490225 M * mnemoc .oO( please, no for dirs at / )o
1136490244 M * Aiken what is the topic of discussion?
1136490289 M * Bertl http://irc.13thfloor.at/LOG/2006-01/LOG_2006-01-05.txt (start at 1136489596
1136490363 M * mnemoc Bertl: what are exactly your goals for this?
1136490404 M * Bertl there are different motivations: (I'll try to describe them)
1136490440 M * Bertl - in the future, we might have completely virtualized PIDs and such, this will complicate vps (as it is done now)
1136490487 M * Bertl - the procfs is strange and special in the way it uses/generates the inode numbers (which complicates adding info for virtual contexts)
1136490529 M * Bertl - the single superblock procfs requires us to do a lot of 'unnecessary' checks for virtual entries
1136490551 M * Bertl - there is no good reason to have 'host' procfs info available inside a guest
1136490570 M * emp I added the ip rule to set the route table for a vsever's IP address, and ping and traceroute seem to work as expected, however asterisk does not want to connect now... * says my voip gateway is unreachable... i've restarted everything a couple times, any ideas?
1136490578 J * tso ~tso@rev.193.226.232.31.euroweb.hu
1136490580 M * tso hi all
1136490588 M * Bertl - we want to switch to sequencer files in the near future (for kernel robustness)
1136490603 M * Bertl welcome tso! care to join our ongoing discussion?
1136490623 M * tso i'm listening, and see irc logs ;)
1136490640 M * Bertl emp: upload the relevant info somewhere (e.g. routing tables and ip addr ls info) I'll look at it ...
1136490657 M * Aiken Bertl I don't know enough to say yay or nay about moving virtual and friends out of proc, to me proc just seemed natural
1136490663 M * mnemoc Bertl: for procs i think you only need a /proc/$pid/xid
1136490669 M * Bertl tso: okay, http://irc.13thfloor.at/LOG/2006-01/LOG_2006-01-05.txt (start @ 1136489596)
1136490681 M * emp ok, thanks Bertl 
1136490681 M * Aiken considering everything else that is also in proc
1136490708 M * Bertl Aiken: yes, but think usbfs for example? or sysfs?
1136490720 M * mnemoc Bertl: interfacing to /sys
1136490722 M * jsaw re
1136490741 M * Bertl wb jsaw! care to join our ongoing discussion?
1136490749 M * mnemoc wb jsaw :)
1136490752 M * jsaw I always found /proc the wrong place for system control, it's process information not system control...
1136490762 M * Bertl precisely
1136490763 M * Aiken I never liked usbfs
1136490794 M * mnemoc what from context can't be moved to sysfs?
1136490798 M * Bertl mnemoc: yes, I totally agree, xinfo and ninfo might be okay for procfs too
1136490798 M * Aiken took me longer than it should have to get usb support working because I never considered having to mount another filesystem under /proc
1136490802 M * jsaw hey, Bertl, mnemoc, Aiken etal
1136490852 M * Bertl Aiken: well, yes, agreed, if you are used to 'just' proc, it's kind of unusual, but it has major advantages to separate it out ...
1136490853 M * mnemoc basicly proc is for /proc/$pid/*, nothing else
1136490874 M * Bertl advantages would be:
1136490885 M * Bertl - a much simpler implementation 
1136490893 M * Bertl - increased security 
1136490906 M * mnemoc cleaning vserver code is a great advantage
1136490909 M * Bertl - simpler inode assignment, i.e. more flexibility
1136490926 M * Bertl - probably more features if we do it right
1136491001 M * mnemoc Bertl: aditionally to /proc/$pid/*, what other vserver inode doesn't fit to sysfs?
1136491009 M * jsaw can entries be hidden from sysfs or proc in vserver?
1136491035 M * mnemoc sysfs on guest?
1136491054 M * Bertl mnemoc: sysfs is limited in the types, entries like the /proc/virtual<xid>/limit would not fit there very well
1136491073 M * jsaw yes, on guest
1136491095 M * Bertl jsaw: proc yes, but only for all guests at once
1136491139 M * jsaw and sysfs ?
1136491159 M * Bertl sysfs is not suited for guests atm
1136491177 M * jsaw I meant, could it be done, not if it is done
1136491190 M * Bertl sure, why not ...
1136491212 M * jsaw easier than with procfs ?
1136491228 M * jsaw yeah, well, you answered that one already
1136491242 M * Bertl well, I'd use the same method than with procfs, so the 'hiding' would be identical
1136491282 M * Bertl the advantage of a separate filesystem (not sysfs) would be that we could simply deny it to guests
1136491319 M * Bertl (once procfs becomes 'secure' in mainline, it would eliminate the procfs hiding/checks too)
1136491328 M * tso well, 'hiding' maybe can work with other patches, like grsec, pax...
1136491340 M * tso i think many vserver users use them also
1136491358 M * Roey hi
1136491367 M * Roey Bertl, tso, jsaw, mnemoc: hi!
1136491371 M * tso hi Roey 
1136491376 M * jsaw hi Roey 
1136491387 M * Bertl some of them, and maybe in the near future, michal_? and I could make something happen there :)
1136491388 M * Roey how do I get OpenVPN running under VServer?  After all, openvpn needs to be able to open the tunN devices.
1136491414 M * tso and if for example grsec would be broken, than the whole system may be not as secure as now
1136491427 M * Bertl Roey: not in a secure way, I'll explain it to you after our ongoing discussion, yes?
1136491436 M * tso so if we put the hole thing from procfs
1136491456 M * tso than maybe we can find out how to work with other patches too
1136491461 M * Roey Bertl:  okay, thank you :)
1136491512 M * Bertl so, IMHO the best way is to go for a separate virtual filesystem (also makes us immune against procfs changes)
1136491596 M * Bertl for me the main questions are: 1) what data shall we put there? 2) what structure to we give it? 3) for whom do we design it - man or machine or both?
1136491642 M * Aiken dumb question of the moment, why not the current format?
1136491672 M * tso Bertl you know that with this changes, vserver could not to mainline kernel soon... or there is no plan for it?
1136491700 M * Bertl Aiken: yes, that's an option, but we might want to extend that ... and when we change, we should do a single change not every month another one
1136491703 M * tso ...could not 'go' to...
1136491769 M * tso well if we talking about data, maybe symlinks from etc should go there
1136491792 M * tso with limits dev etc
1136491794 M * Bertl tso: why?
1136491812 M * Bertl (that why was regarding mainline)
1136491894 M * Bertl tso: aside from the fact that I do not base my designs on acceptability for mainline inclusion :)
1136492001 Q * blackfire Ping timeout: 480 seconds
1136492009 M * Bertl Aiken: for example, once pid virtualization is done or virtual network support (ngnet) is there, you would probably like a way to 'view the whole picture' on the host, but there is just no way with the current structure/data
1136492068 M * tso Bertl some weeks ago was a thread about a driver, which good - as users said - but it can't be in mainline, because some procfs issues, the point was that keep the rules about procfs for example
1136492119 M * Bertl tso: ah, so you are basically arguing _for_ a move away from procfs, did I get that right now?
1136492207 M * tso Bertl no, i'm sure that is good for vserver security to move it outside the procfs, but i think maybe we can make the helpers to other patches could work, over(?) the vserver too, like pax, grsec
1136492208 J * blackfire blackfire@dp70.internetdsl.tpnet.pl
1136492255 M * tso Bertl the mainline thing doesn't matter, i just thought there was a plan about it
1136492266 M * Bertl tso: I agree, no problem with interworking and cooperation with security related projects (that's why I always try to get in contract with folks like michal_)
1136492292 M * tso well back to your 3 points
1136492310 M * Bertl welcome blackfire! care to join our little discussion?
1136492336 M * tso i think if we build a new vserver-procfs there are some settings, or information that could go there from etc
1136492343 M * Aiken is the dumping of everything in /proc just a linux thing?
1136492353 M * tso like limits, run infos etc
1136492357 M * dhansen Aiken: an outdated Linux thing
1136492357 M * Bertl Aiken: yes, it was basically abused'
1136492366 M * dhansen but, similar abominations have arisen in other UNIXes
1136492392 M * Bertl tso: ah, so you are thinking about config data too?
1136492402 M * tso yes, like sysctl
1136492419 M * Bertl tso: well, the main issue there is, virtual filesystems are not persistent
1136492438 M * Bertl (and for the configuration the syscall interfaces are much better)
1136492468 M * Bertl tso: so IMHO, /etc has it's justification in the fact that this data _is_ persistant
1136492523 M * dhansen Bertl: is there any reason that you can't have both?  /sys is where the _interfaces_ to power mangement are, but the policies are all in /etc
1136492525 M * tso Bertl it can be used for 'boot' settings, but maybe can this values changeable, which can be go to newproc
1136492575 M * Bertl dhansen: well, let's take a concrete and simple example, the 'limits'
1136492579 M * Aiken things like cpu/memory limits so they can be changed at run time
1136492591 M * Bertl Aiken: they can already be changed at runtime
1136492644 M * Aiken ok, I need to look at that a bit more, I only remember changing cpu limits in /etc and restarting the vserver
1136492645 M * Bertl dhansen, tso: limits example, let's say for nproc
1136492658 M * Bertl (number of processes per context)
1136492709 M * Bertl there is currently the interface in /proc/virtual/<xid>/limit
1136492730 M * Bertl there you can _read_ the current, max, limit and hits
1136492754 M * Bertl they can be configured via the syscall switch at _any_ time
1136492781 M * Bertl (the vlimit tool allows to adjust them)
1136492799 M * dhansen Bertl: wouldn't it just be easier to get rid of the syscall?
1136492814 M * dhansen and allow writes in to the fs files?
1136492821 M * Bertl dhansen: no, definitely not, as the syscall _is_ required for a lot of other things
1136492834 M * Bertl dhansen: what would you write there?
1136492854 M * dhansen you'd do what they do in sysfs.  one value per file
1136492871 M * Bertl dhansen: reminds me of the early scsi approaches .. echo "scsi add single device 0 0 0" >/proc/scsi/scsi
1136492876 M * dhansen what is the format of  /proc/virtual/<xid>/limit
1136492878 M * dhansen ?
1136492888 M * Bertl http://linux-vserver.org/Resource+Limits
1136492932 M * dhansen the important part in sysfs is that you only ever write one value to a file
1136492938 M * dhansen as a rule
1136492982 J * cd_rom cd_rom@user-375.lns1-c7.dsl.pol.co.uk
1136493010 M * dhansen  /proc/virtual/<xid>/limit/nr_processes/current
1136493014 M * dhansen  /proc/virtual/<xid>/limit/nr_processes/max
1136493015 M * dhansen  /proc/virtual/<xid>/limit/nr_processes/min
1136493017 M * dhansen etc...
1136493033 M * dhansen Instead of having a single file do it all
1136493057 M * dhansen It actually makes writing tools much, much easier
1136493088 M * Bertl dhansen: well, shell scripts, yes, but it's a hell in kernel code (i.e. a lot of _useless_ code just to split that out)
1136493106 M * Bertl dhansen: also it really hogs kernel memory to break down at this level
1136493130 M * dhansen Bertl: there are a number of sysfs functions to make it quite simple code-wise
1136493141 M * Bertl dhansen: and finally, you loose the 'overview' because you need a tool to show something like the current limit
1136493162 M * dhansen It doesn't really hog kernel memory, either.  They're just dentries :)
1136493185 M * Bertl dhansen: and if you say, a tool is not the problem, then we can forget about the filesystem at all, the syscall already provides suitable information at this granularity
1136493189 M * dhansen yes, you do end up needing tools to show the 'overview', but you tend to need those anyway
1136493193 M * dhansen a la 'top' :)
1136493312 M * Bertl dhansen: as I said, in this case we can forget about the filesystem interface, as it is not required
1136493391 M * Bertl dhansen: regarding sysfs functions, I know, I already use them :)
1136493394 M * dhansen I think the kernel community decided to keep the number of syscalls down
1136493437 M * dhansen precisely because everybody wants their own :)
1136493504 M * dhansen I really did resist doing memory hotplug in sysfs because it was a fair bit of code.  But, I wrote it once, and really left it after that.  It was virtually zero maintenance.
1136493570 M * Bertl dhansen: we already have a registered syscall :)
1136493572 M * dhansen To, me "custom" syscalls just add a level of complexity in tools to get _anything_.  sysfs is nice because you can get _something_ with cat
1136493614 M * dhansen Bertl: you're right.  why do you need a new fs again? ;)
1136493636 M * Bertl let me look up the arguments :)
1136493652 M * Aiken I also like being able to get info out of proc and sysfs with cat, it is handy and simple to write scripts for
1136493708 M * Bertl dhansen: http://irc.13thfloor.at/LOG/2006-01/LOG_2006-01-05.txt starting with 1136490874
1136493742 M * Bertl and also (1136490404-1136490588)
1136493776 M * Bertl Aiken: yes, for the _read_ part I agree that especially 'overviews' are interesting in something like 'proc'
1136493787 M * tso Aiken well, in new procfs maybe you could do it as well
1136493827 M * dhansen Bertl: I was envisioning actually giving /proc more than one superblock.  truly _separate_ proc mounts
1136493941 M * Bertl dhansen: yeah, sounds interesting for the pid virtualization approach
1136493957 M * dhansen One serious argument I can see against /sys is that it has the same "single mount" problem as /proc
1136493973 M * dhansen and we certainly don't want to expose the vserver controls to each vserver
1136494001 M * daniel_hozac why would a vserver need /sys anyway?
1136494013 M * Bertl dhansen: for me the sysfs interface is excellent for _simple_ things but a perversion for complicated structures ... 
1136494049 M * Bertl dhansen: for example, the global debug flags (for linux-vserver) are in sysfs. works great.
1136494180 M * dhansen Bertl: the bus layout of the whole machine is pretty complicated :)  works pretty well in /sys
1136494307 M * Bertl dhansen: okay, how do you change the PCI timer info, for example?
1136494350 M * dhansen Bertl: I don't know what that is
1136494376 M * Bertl well, doesn't matter, the thing is, we both know that _all_ strutures can be mapped to sysfs
1136494395 M * dhansen yup, it's just a matter of how much you convolute it in the process
1136494489 M * Bertl things which sysfs cannot do are passing files and sockets, but that is something we should not really miss
1136494527 M * Bertl nevertheless, sysfs is not suited for overviews
1136494531 M * dhansen Bertl: is that handy for sharing between vservers that don't share filesystems otherwise?
1136494581 M * Bertl don't know, didn't try yet :)
1136494602 Q * cd_rom Quit: 
1136494688 M * Bertl okay, let's put the decision which filesystem to use aside for a moment, and try to focus on the contents
1136494719 M * dhansen deal :)
1136494729 M * Bertl we probably want to get at least the same information we have now ... so I just assume that the current information has to be mapped somehow
1136494748 M * Bertl a) what could we improve there?
1136494759 M * Bertl b) what other information is missing right now?
1136494896 M * mnemoc can be designed just thinking in cleaner implementation?
1136494925 M * mnemoc what's the cleaner way to have waht we have, even if it's on a different place?
1136495011 M * dhansen mnemoc: It would also be handy to take a hard look at what some other people like openvz are doing and ensure that we can use the same interfaces
1136495052 M * Bertl sure, that's an aspect, but let's do some brainstorming to get a picture of what we would like to see (regardless of implemenation and complexity)
1136495082 M * mnemoc vserver giving interfaces to openvz or vserver using the same 'API' openvz use?
1136495102 M * Bertl dhansen: do we really want to have the same API?
1136495111 M * mnemoc i doubt
1136495130 M * dreamist nifty.. running memtest-86 makes my machine intermittently shut off in the middle of a test
1136495131 M * dhansen Bertl: for the same functionality, why not?  You could even potentially share tools.
1136495138 M * Bertl dhansen: we tried to keep compatible interfaces with FreeVPS, which resulted in a lot of legacy code
1136495172 M * dhansen Bertl: I wouldn't suggest conforming to their interfaces, just making sure that whatever you come up with can be _used_ by them as well
1136495176 M * dhansen even if they never use it
1136495192 M * mnemoc let's cut legacy, even if it bleed :p
1136495255 M * Bertl dhansen: I see it more like this: if that happens, no problem, but OpenVZ has some 'restrictions' because they need/want to be 'compatible' to the comemrcial product (to some extend), so they will not change their interfaces even if it would make good sense ... which in turn would force us to use a bad interface, just to be compatible :)
1136495296 M * mnemoc vserver 2.2 compatible with vserver 2.2!
1136495313 M * mnemoc but clean and smooth
1136495324 M * Bertl dhansen: don't get me wrong, when OpenVZ folks _want_ to design a common/interchangeable interface ... I'm all open for it ...
1136495385 N * Roey ElPistoleroRoey
1136495385 M * mnemoc Bertl: why $xid/limits + new tools doesn't fit sysfs ?
1136495391 M * dhansen Bertl: I'm just thinking of this from the mainline perspective.  Even if we have a big patch, if there are 3 or 4 external projects using it, that is a much stronger argument than any single project.
1136495465 M * mnemoc been less intrusive is stronger imo
1136495489 M * Bertl dhansen: well, the aims of OpenVZ and Linux-VServer are quite different, and the implemenations even more ... what am I missing in your 'big patch' scenario?
1136495554 M * dhansen not much :)
1136495586 M * dhansen So, say vserver and openvz implement a given feature with two completely separate code bases.
1136495622 M * dhansen Somebody comes along and implements it in a third way, and makes sure that it would be functional for vserver and openvz
1136495635 M * dhansen the third way happens to get merged into the mainline kernel
1136495639 M * Bertl dhansen: okay, as I said, things like pid virtualization, once there _is_ some kind of agreement to get it into mainline, I'm all for a common implementation, which can be reused by all projects
1136495649 M * dhansen wouldn't openvz and vserver be crazy not to use it eventually?
1136495693 M * Bertl dhansen: I'm the first one to use a mainline kernel implementation/feature when it makes sense, we had a deep look at ckrm, but honestly it just sucks :)
1136495706 M * dhansen you don't have to convince me that ckrm sucks :)
1136495723 M * dhansen I sit next to the guy who implemented most of it
1136495743 A * Bertl was hoping to replace the resource management of linux-vserver with ckrm sooner or later
1136495776 M * dhansen yeah, I really wish they'd get their show on the road and thow away their crappy code
1136495790 M * dhansen it is never going to get merged no matter how many band-aids get put on it
1136495895 M * Bertl mnemoc: <xid>/limit is an overview, how to fit that into sysfs?
1136495922 M * mnemoc Bertl: overviews can be generated
1136495928 M * mnemoc on userspace
1136495940 M * Bertl mnemoc: in this case, we do not need sysfs at all :)
1136495964 M * Bertl mnemoc: check out vlimit, it uses the syscall interface
1136495972 M * mnemoc we need to query something to get the info to generate the overview :)
1136495980 M * mnemoc oh
1136496010 P * meandtheshell 
1136496016 M * mnemoc i would move as much as possible to user space
1136496077 M * Bertl mnemoc: go crazy, I'll test your tools :)
1136496106 M * mnemoc give me the interface and a helper and i do bash
1136496121 M * Bertl you already got vlimit :)
1136496153 M * dhansen Bertl: as far as the overviews, why don't we just implement top in the kernel?  'cat /proc/top' and have it write to the tty
1136496154 M * Bertl (even has some kind of overview, although it seems broken, somewhat)
1136496162 M * dhansen I don't know a good answer other than it's harder to do in the kernel :)
1136496172 M * mnemoc if you want, i code the tools (on clean bash)
1136496185 M * Bertl dhansen: well, there is a difference between top and the /proc info top is reading ...
1136496200 M * Bertl dhansen: why not move the info top reads to sysfs?
1136496213 M * mnemoc but only if its desired
1136496214 M * dhansen Doesn't top provide an overview of a bunch of stuff from /proc?
1136496237 M * dhansen Bertl: some of it probably could be.  But, it makes sense to keep process information in the process filesystem
1136496253 M * Bertl dhansen: mainly cat /proc/*/stat
1136496265 M * dhansen However, things like /proc/meminfo would be better off in /sys, if it wasn't for compatability
1136496306 M * Bertl dhansen: what about /proc/slabinfo?
1136496318 M * Bertl (this is an interface which was recently added :)
1136496318 M * mnemoc i though we are standing on the fact that compatibily would be lost
1136496342 M * Bertl mnemoc: well, we do not care too much about compatibility 
1136496344 M * dhansen slabinfo has been around as long as I can remember.  3 or 4 years at least, right?
1136496367 M * dhansen longer than sysfs at least :)
1136496462 Q * lilalinux Remote host closed the connection
1136496517 M * Bertl dhansen: yeah, but in terms of /proc additions this is recently, no?
1136496544 M * Bertl nvertheless, let's get back to the information part ...
1136496570 M * Bertl mnemoc, your position is, we do not need any fs interface at all, right?
1136496591 M * Bertl dhansen, you would like to see a tree based interface in sysfs
1136496613 M * Bertl but what I don't know yet is _what_ information do we put there?
1136496627 M * mnemoc Bertl: beside /proc/$pid/ and whatever can't be done using syscalls
1136496637 M * dhansen Bertl: that would be my first approach.  it might bomb, in which case a custom fs would be my next preference
1136496664 M * Bertl mnemoc: everything can be done via syscalls
1136496675 M * Bertl mnemoc: even if the kernel folks want to tell you different
1136496732 M * mnemoc Bertl: so yes, no fs interface at all
1136496747 M * dhansen Bertl: of course everything can be don via syscalls :)  It's just a matter of what is maintainable over a long period of time.   sysfs could end up being a huge disaster
1136496785 M * mnemoc Bertl: or sysfs to what fits there
1136496810 M * dhansen Bertl: I'm just looking at the do_vserver() switch statement.  That's where I'd start
1136496814 M * waldi Bertl: ppc64 support for 2.6.15 is still missing?
1136496833 M * mnemoc Bertl: using sysfs should be lighter than triggering the helper that do syscalls
1136496834 M * Bertl waldi: mainline?
1136496852 M * waldi vserver patch?
1136496863 M * Bertl mnemoc: only if you call the helper every time ...
1136496885 M * Bertl waldi: not that I know of, but ppc64 is not tested, as I have no access to such a machine
1136496894 M * waldi Bertl: you need access?
1136496913 M * Bertl if you want something tested, yes :)
1136496921 M * waldi no problem
1136496930 M * waldi ssh key?
1136496975 M * mnemoc Bertl: so, procfs for process, sysfs for iterables and syscalls for the rest?
1136497037 M * dhansen insead of sysfs, we can also consider configfs
1136497044 M * dhansen ckrm uses it, and they're pretty happy
1136497049 M * dhansen it got rid of their custom fs
1136497063 M * michal_ ckrm with vserver, nifty idea, i like it
1136497065 M * Bertl dhansen: ah, any details about configfs?
1136497066 M * mnemoc yet-another-thing-mounted ?
1136497088 M * Bertl michal_: well, Planetlab tried it, they are now back to 'plain' vserver
1136497091 M * mnemoc sysfs is 'mostly' already there, like dev and proc
1136497106 M * michal_ lol
1136497107 M * dhansen Bertl: in CKRM, to create a new class, it's just a mkdir
1136497138 M * dhansen I need to see what kind of layout they use
1136497141 M * Bertl dhansen: yes, something I consider abuse of filesystem interfaces
1136497239 M * Bertl dhansen: but hey, it looks cool and intersting :)
1136497288 M * mnemoc *g*
1136497355 M * michal_ yeah, so cute ;p
1136497370 M * Bertl okay, looks like we will not get to the point where we could discuss contents, not layout ...
1136497372 M * dhansen Bertl: ever seen a Plan9 system? ;)
1136497404 M * Bertl dhansen: no, but read about it ...
1136497440 M * dhansen Bertl: horrible abuse of filesystem interfaces, but really neat stuf
1136497529 M * michal_ i have once tried plan9
1136497534 M * michal_ and am recovering still ;p
1136497799 M * Bertl ElPistoleroRoey: okay, what was your question?
1136497808 Q * jeeves Quit: Leaving
1136499825 J * nahual ~nahual@gentoo.charanda.sandino.net
1136499827 M * nahual hello
1136499867 M * Bertl welcome nahual!
1136499869 M * nahual is my first vserver read the documentation but Im stuck, i recompiled the kernel worked out fine, and compiled the utils
1136499872 M * nahual hey Bertl!
1136499883 M * nahual BUT the infamous testme.sh drops me the chbind: vc_set_ipv4root(): Invalid argument
1136499886 M * Bertl nahual: good, did you boot the new kernel?
1136499900 M * nahual yes machine is with the kernel right now
1136499924 M * Bertl okay, the testme.sh gives you a line starting with VCI, could you paste that one here?
1136499929 M * nahual shure
1136499957 M * nahual VCI:  0002:0001 236 03000016
1136499973 M * nahual actually to be more complete line before is
1136499974 M * nahual Linux 2.6.14.4-vs2.1.0 x86_64/0.30.209/0.30.209 [Ea] (0)
1136499974 M * nahual VCI:  0002:0001 236 03000016
1136499977 M * nahual if that helps
1136500076 M * Bertl yes, it does, just a second
1136500217 M * Bertl nahual: could you upload the output of 'vserver-info - SYSINFO' somewhere (e.g. pastebin.com)?
1136500303 M * nahual shure
1136500613 M * nahual http://venus.sapotek.com/vserver.txt
1136500752 M * nahual anything on why testme.sh drops?
1136500852 M * mnemoc connection refused
1136500859 M * nahual lemme restart
1136500864 M * nahual retry
1136500865 M * nahual :D
1136500879 M * nahual since i dont use web there ... well had it stoped and only started it for a bti
1136500880 M * nahual bit
1136500935 J * tso_ ~tso@rev.193.226.232.31.euroweb.hu
1136500942 Q * tso Quit: BitchX Lite I said!
1136501052 J * Smutje_ ~Smutje@xdsl-87-78-3-224.netcologne.de
1136501109 M * Bertl nahual: well, first, you should really use dietlibc :)
1136501133 M * nahual stucked with libc owner of server doesnt like dietlibc :(
1136501152 M * nahual (I know i should change Ill might just sneak it LoL!)
1136501157 M * Bertl well, then you must expect certain things to fail ...
1136501161 Q * Smutje Ping timeout: 480 seconds
1136501200 Q * prae Quit: Pwet
1136501208 M * nahual that is the problem?
1136501221 M * nahual so if I install dietlibc everything should work nice?
1136501283 M * daniel_hozac nahual: did you disable dynamic IDs in the kernel configuration?
1136501348 M * Bertl very likely
1136501394 M * nahual Hmmmmm lemme fastly check .. probably ... I have to have that enabled right?
1136501407 M * daniel_hozac if you want to use Enrico's utils, yes
1136501435 M * nahual yep is disabled
1136501464 M * nahual what other stuff should i enable?
1136501478 M * Bertl nahual: enable that and it should work, everything else looks good
1136501488 M * nahual great!!! thanks!!!
1136501515 M * nahual BrB .. thank you so much :D
1136501517 M * Bertl nahual: but be aware that without dietlibc, the tools will fail in certain situations, and they are basically insecure
1136501517 Q * nahual Quit: thx
1136502407 Q * Doener Quit: Leaving
1136502934 P * stefani I'm Parting (the water)
1136503027 J * Doener doener@i5387D8E7.versanet.de
1136504036 J * Aiken_ ~james@tooax6-195.dialup.optusnet.com.au
1136504157 M * Bertl wb Doener! Aiken_!
1136504170 M * Doener hidiho
1136504284 M * Aiken_ hi
1136504351 Q * Aiken Ping timeout: 480 seconds