[00:00] a) good question - probably it is not needed on dummy0 (e0) - it is needed on eth0 to forward all packets from the lan [00:00] d) what implications would it ahve if the e0 is changed from a vserver? [00:00] [00:00] b) br0 will be the hosts default interface - eth0 has no ip address [00:01] can I set my reference vserver up to have the same IP as the host? [00:01] c) I gave CAP_NET_RAW to my vservers, works. I tried CAP_NET_ADMIN - configuring the interface gave me strange errors - wait a minute, I'll try it out [00:02] (strange error message inside the vserver, no way to disturb the others) [00:02] micah: sure, just make sure that you either do not start it, or 'reuse' the already configured ip ... [00:02] d) division by zero - question cannot be applied [00:02] Bertl: if I just enter and setup the IP to be the same, then it should be ok? [00:03] if done properly, yes [00:03] Bertl: but it has to be done outside of the vserver? [00:03] because inside, I get: [00:03] /sbin/ifconfig eth0:zunz 216.162.197.194 [00:03] SIOCSIFADDR: Permission denied [00:03] SIOCSIFFLAGS: Permission denied [00:04] you ahve to remove the eth0: part [00:04] from the config file ... [00:04] (that is what I meant with properly) [00:04] I've just got: [00:04] IPROOT="216.162.197.194" [00:04] IPROOTDEV="eth0" [00:04] in my .conf [00:04] IPROOTDEV="" would be okay [00:04] do I remove the IPROOTDEV? [00:05] ok, did that [00:05] it works :) [00:05] bengrimm (~ben@bengrimm-host225.dsl.visi.com) left irc: Ping timeout: 480 seconds [00:08] bengrimm (~ben@bengrimm-host225.dsl.visi.com) joined #vserver. [00:09] Bertl: I am trying to remove an oldvserver [00:10] but it wont let me rm -rf it [00:10] because: [00:10] /dev/pts and /dev/shm wont let me remove [00:10] rm: cannot unlink `pts/0': Operation not permitted [00:10] rm: cannot remove directory `pts': Device or resource busy [00:10] you didn't stop it properly and there are mounts left ... [00:10] umount /vservers/server/dev/pts [00:10] ah [00:12] I can't rmeove the proc stuff though [00:12] /vservers/server/proc [00:12] micah: what could be the solution? [00:12] well, umount /vservers/server/proc doesn't help [00:13] so you probably have processs still running in this vserver then? [00:13] no [00:13] but doing mv /vserver/server /vserver/foo and then rm -rf /vserver/foo worke [00:14] i had not run anything in the vserver [00:16] hmm, unusual ... [00:16] bertl: any idea what this means: "Unable to handle kernel NULL pointer deference at virtual adress" [00:16] a friends kernel hangs with this messages during boot [00:16] looks like a kernel bug, which kernel? [00:17] Method (Method@ip68-12-167-163.ok.ok.cox.net) left irc: Quit: AnacųnŠa · "Everything takes longer than you think" [00:17] and usually there is a long message (kernel oops) attached [00:17] JonB (~NoSuchUse@kg229.kollegiegaarden.dk) joined #vserver. [00:18] Bertl: sorry, I was away for a phonecall - in the meantime I tested ifconfig on the bridged dummy0 interface: [00:18] in vs4: ifconfig e0:vs4 192.168.124.227 [00:18] (e0 == dummy0) [00:18] and? [00:18] bertl: 2.4.20 (gentoo src) [00:18] SIOCSIFFLAGS: Cannot assign requested address [00:18] bertl: it is [00:19] BUT it changes the ip address of e0:vs4 on the host [00:19] hmm, okay, could you try giving the 192.168.124.227 to the vserver allowed ips too? [00:19] btw, where does gentoo keep list of patches in their kernels? [00:20] Hest (~NoSuchUse@129.142.112.33.ip.tele2adsl.dk) joined #vserver. [00:20] maharaja: well you can debug the oops with ksymoops, if you recompile the kernel accordingly ... [00:20] hi Hest! [00:23] Bertl: and now comes the very strange thing: [00:23] Bertl: "Hey, it's me George" [00:23] ifconfig on the host shows .227 - vserver vs4 exec ifconfig shows still the old .204 [00:24] if I change the ip back, everything works as before [00:25] Bertl: what do you mean by "allowed ips"? [00:25] Hest: hmm, George who? [00:25] Bertl: from the schweepes commercial [00:26] dilox (~dilox@host2-9.pool8249.interbusiness.it) joined #vserver. [00:26] JonB (~NoSuchUse@kg229.kollegiegaarden.dk) left irc: Ping timeout: 499 seconds [00:26] hi bertl [00:26] hi dilox! [00:26] Nick change: Hest -> JonB [00:27] ah, Jon in disguise ... [00:27] pazzo: the vserver has a list of allowed ips [00:28] IPROOT="192.168.124.227 192.168.124.204" would be interesting ... [00:28] IPROOT ? [00:28] this might allow you to switch between those two ips ... [00:28] Bertl: exactly [00:29] ok, ath the moment I have IPROOT="e0:192.168.124.204/255.255.255.0" - I'll test IPROOT="e0:192.168.124.204/255.255.255.0 e0:192.168.124.227/255.255.255.0" [00:31] no, forget the e0: [00:31] just leave that to the vserver ... [00:31] IPROOT="192.168.124.204/255.255.255.0 192.168.124.227/255.255.255.0" [00:31] this will not create/setup any e0 alias ... [00:32] so you preset the e0 before the start to one of those addresses [00:32] Bertl: this creates e0:vs4 and e0:vs41 [00:32] yeah, and we do not want that ;) [00:32] Doener (~doener@pD9588E0E.dip.t-dialin.net) left irc: Quit: Leaving [00:33] changing ip addresses works (I can use .204 and .227) [00:33] hehe, thought so ... [00:33] but there seems to be a bug: if I'm limited to the ip addresses in IPROOT - why can I change them anyway? [00:34] inside the vhost it gives me a deny and the address remains the same - but on the host the address IS CHANGED! [00:34] this is because this was never meant to happen, but some checks are already there [00:35] so basically we have half the way ... [00:35] aaaaaaaaaaaargh - and I can assign addresses to other interfaces!!! [00:35] of course ... [00:36] okay, now lets check the other end .... [00:36] what about that promisc settings ... what about moving eth0 ip to the bridge [00:36] ok, so we need to limit the view of the addresses - I've been able to do so using vproc - is that secure enough? [00:36] nope, but let us put that issue on hold ... for now [00:37] Zoiah (Zoiah@matryoshka.zoiah.net) joined #vserver. [00:37] Bertl: at the moment I have br0->192.168.124.222, eth0->0.0.0.0 promisc (from inside a vserver I changed this to 10.0.0.1), ... [00:37] example: [00:37] ...and vs1 - vs6 use e0:192.168.124.201 - 206 [00:38] what if you leave eth0 as w/o bridge and configure the dummy0 to a new ip [00:38] this way packets addressed to the dummy0 ip, will arrive at eth0 anyway, right? [00:38] then I have to use routing to allow the vservers access to my lan - I have to add another network segment or to do nat! [00:38] nope [00:39] just try it, configuring an ip on the dummy, automatically enables this ip [00:39] ok, slowly again - what would you like to do? [00:39] ok, wait a minute... [00:39] for example: ifconfig eth0:192.168.124.222 [00:39] ifconfig dummy0 192.168.124.204 [00:40] and the host will respond to a ping at .204 [00:40] all vservers stopped, I have only eth0 with 192.168.124.222 now [00:40] okay, now configure a dummy0 at .204 [00:40] then from outside the host (on the lan) try to ping that ip [00:41] aaaaah, cool - is dummy0 accessible from any network segment??? [00:41] how does this work? [00:41] it responds to pings from the lan [00:41] yeah [00:41] that is because addresses and interfaces are separated in the kernel [00:42] (at least if you do not disable that) [00:43] hmmmm... so can I assign dummy0:1 an ip address from a network segment on eth0 and dummy0:2 an ip address from another network segment on eth1 ? [00:43] sure ... [00:43] hmmm... and two routes for the sem subnet to two interfaces (eth0 and dummy0) cause no problems???? [00:44] I'm sure that would burn down any cisco router :o) [00:44] you do not need two routes ... as the outgoing interface is only eth0 [00:45] linux adds a route for 192.168.124.0/24 to dummy0 if I give it an ip address [00:45] and ther is also 192.168.124.0/24 on eth0 [00:45] yes, but that is interface specific ;) [00:45] the actual 'route' is the default route ... [00:45] serving (~serving@213.186.190.121) joined #vserver. [00:46] if I ping 192.168.124.123 I do not use the default route! [00:46] it might become a problem, if you use the same ip on both 'lans' internal and external [00:46] okay, let's see if the next step works ... [00:46] now use this dummy interface for a vserver ... [00:46] (I do not agree with this routing thing, but let's go on) [00:47] bengrimm (~ben@bengrimm-host225.dsl.visi.com) left irc: Ping timeout: 480 seconds [00:47] Doener (~doener@pD9588E0E.dip.t-dialin.net) joined #vserver. [00:47] ipv4root is now 192.168.124.201 [00:47] (vserver vs1 running) [00:48] can you bind that ip from inside, and does the bind actually work? [00:48] ...and it does all the networking staff [00:48] bengrimm (~ben@bengrimm-host225.dsl.visi.com) joined #vserver. [00:48] (I can ssh to it) [00:48] fascinating, isn't it? [00:48] and I can ping servers some hundred kilometers away [00:49] so let's make a short recapitulation ... [00:49] we have a 'separate' interface for the vserver [00:49] the vserver can change this interface in some ways ... [00:50] ettercap: [00:50] ec_inet_linux:237 ioctl(SIOCGIFADDR) | ERRNO : 99 | Cannot assign requested address [00:51] the interface works for the outside too, and it's visible on both the vserver and the host, right? [00:51] yes [00:51] (additionally there are many other interface visible, which will be corrected later) [00:51] ok [00:52] now the basic question, does this allow to sniff packages between servers and host or to the host? [00:52] see above: it results in a strange error [00:52] and more important, does it allow to tcpdump the vserver (something we would like) [00:52] give CAP_NET_RAW and tcpdump will work [00:53] it HAS CAP_NET_RAW [00:53] apt-get install tcpdump [00:54] tcpdump works - and see's no packet as before [00:54] does it see packets targeted at the vserver? [00:54] even not the packets directed to this vserver [00:55] (that would be nice to have) [00:55] okay, but did this work with the bridge setup? [00:56] no, this didn't work with the bridge setup - seems to be a dummy0 feature - let's try a tun/tap interface! [00:56] try, it will not work either ;) [00:57] shit, typing too fast - I've shut down something wrong, I'll be back soon! [00:57] is this forbidden by vserver or by dummy? [00:57] neither nor ... [00:58] it is an intrinsic feature of the network stack [00:59] ? [00:59] you can only tcpdump interfaces which are transporting packets [00:59] tell me more! [00:59] aaah! [00:59] both dummy0 and tun/tap do not transport any packets in your setup [00:59] then let's see if tun/tap transports packets [00:59] sure they don't? [01:00] try it out, can't hurt, can it? [01:00] I had to run downstairs to restart the server :o) [01:01] and I've had a snowboard accident, so running hurts since 3 weeks :-))) [01:01] that's bad, you should not leave your snowboard lying around on the stairs 8-) [01:01] hmm, you shouldn't put in on in the first place... [01:02] snowboard hurts :( [01:02] skiing is easy [01:02] snowboarding hurts... and learning it REALLY hurts ;) [01:03] snowboarding is real fun - learnig it was hard - but today - it is really great fun!!! [01:04] hmm... i wouldn't know - i tried learning the same way I learned to ski - I get on biggest hill around and tried riding down... [01:05] me too - it took me 2 hours :) [01:05] learning to ski is easy at the beginning - but it is difficult to become really good [01:07] Topic changed on #vserver by Bertl!~herbert@MAIL.13thfloor.at: http://linux-vserver.org/ || latest stable 1.26, devel 1.3.8, exp 0.09.8 [01:07] pazzo: problem was - I learned on blue track that was a bit icey.... anyhooo... 4hours later I was all wet and with few slightly fractured ribs and promised myself not to touch that evil board for at least another month;) [01:11] eyck: the first thing you have to know if you want to learn snowboarding: you have to be relaxed: Jaegermeister is your friend! [01:12] (or tequila, if you can find nothing else :o) [01:15] bertl? ever tried tcpdump -i eth0 ? [01:16] inside a vserver? [01:17] yes [01:18] IT WORKS [01:18] I've been testing with tun/tap, now I changed back to dummy0 - it still works [01:18] # tcpdump -i eth0 [01:18] tcpdump: socket: Operation not permitted [01:18] pazzo: what capabilities do you have assigned to that vserver? [01:18] CAP_NET_RAW [01:19] you forget that cap NET_RAW and other isn't secure atm [01:19] ok, and that's the big remaining problem [01:19] hmm [01:19] why would you give CAP_NET_RAW to vserver? [01:19] pazzo: yeah, hackers can always enter your server through the network, better remove the network from the server [01:20] pazzo: let us not be concerned with that issue atm ... [01:20] pazzo: but must hacking jobs are done from within the company itself, so, you better remove the keyboard as well [01:20] using dummy0, tun/tap, eth0 or whatever you want - all works mor or less the same but we can not assign CAP_NET_RAW until we have a limited view/access to only some interfaces [01:21] okay, so we actually have three remaining issues: [01:21] JonB: I would like to have CAP_NET_RAW - I don't like stupid daemons or userspace utilites just to have a working ping [01:21] a) tcpdump on the vserver interface doesn't work [01:22] b) we have to restrict access only to the 'allowed' interfaces and ips [01:22] c) we have to disallow the 'creation' of other interface ;) [01:22] pazzo: i can see that [01:23] pazzo: You're aiming for a fly with a nuclear missle by using CAP_NET_RAW for ping, hmm [01:24] pazzo: IMHO a) can be postponed (as a nice to have feature, right?) [01:24] hmm, i thinks it's rather general issue with CAPs granularity [01:24] eyck: that is why we now have vserver caps ;) [01:24] ouh, smeagol talk [01:25] hmm, we have vserver caps? [01:25] what vserver caps? [01:25] yes, we do ... [01:25] JonB: and do not really fear hackers (some time ago I was a little bit mor paranoid - I have a server without a graphic card, vga disabled in the kernel, no cdrom, bios password, no keyboard support - now I have to change this machine as it has more than 800 days uptime - it will be a mess to access this system - I was sooooo stupid) [01:25] Bertl: a) would be a nice to have feature, yes [01:26] pazzo: buy a new ? [01:26] but it shouldn't give you access to ethß [01:26] pazzo: hmm, that wouldn't be stupid if you had full-featured serial access... like SUN or SGI systems do. [01:26] so b) and c) is mandatory ... but after that, we have a solution which is what you where looking for, rifht? [01:26] eyck: this machine hase serial access - but not to the bios [01:26] eyck: i have serial access [01:26] oh [01:26] that much [01:26] eyck: todays server boards offer this too [01:26] realveasel [01:27] pazzo: exactly. not to the bios. damn PC shaizzz [01:27] damjan (~damjan@legolas.on.net.mk) left irc: Ping timeout: 480 seconds [01:27] pazzo: hmm, haven't seen proper serial access in servers around here... [01:27] I have two new servermicro boards (p4) here, it should work with the bios, I didn't try it out [01:28] HP/Compaq ships nice menagement interface though... [01:28] okay, I guess we all should think a little about the network stuff, and maybe we can talk again tomorrow ... [01:28] ehm - supermicro serverboards, not servermicro [01:28] eyck: realveasel, a add on card [01:28] Bertl: I agree with b) and c) [01:28] JonB: not available around here :( [01:29] it's easier to buy SGI server with proper serial then to buy such addon card;) [01:30] eyck: the point is: normal ping doesn't work without CAP_NET_RAW - customers complain "you give me a root server and even ping doesn't work? what a crap!" - there has to be a better solution, whatever it is! [01:30] found it [01:30] http://www.realweasel.com/pcivga.html [01:30] eyck: no addon card, motherboard! [01:30] pazzo: supermicro? hp/compaq doesen't sell those ;) [01:31] eyck: http://www.supermicro.com/PRODUCT/MotherBoards/875/P4SCE.htm [01:31] jes_ (~jes@cpc1-leed5-3-0-cust196.ldst.cable.ntl.com) joined #vserver. [01:31] evening all [01:31] hi jes! [01:31] heya Bertl [01:32] hmm, where can I find the docs about those new caps? wiki? [01:32] eyck: use the source ... [01:32] quick question...I've just managed to hide /proc/stat on my host by using setattr....doh! [01:32] how can I get it back? [01:32] eyck: These are the last server motherboards I bought some month ago - and the serial stuff should work, but as said before I still have to try it out [01:32] eyck: it's currently very experimental, and the caps are not fixed yet [01:33] jes_: completely, even for xid=1 [01:33] ? [01:33] yes Bertl [01:33] I did a "setattr --hide /proc/stat" [01:33] and now its gone ;) [01:33] that means reboot ... [01:33] lol damn [01:34] well, it might be that unmounting it completeley, from all mount points would help too [01:34] but that is basically not an option, as the host /proc will not want to unmount ... [01:34] bengrimm (~ben@bengrimm-host225.dsl.visi.com) left irc: Read error: Connection reset by peer [01:35] *nods* [01:36] I wonder how I managed to hide it [01:36] ok, I'll leave - have a good night! [01:37] because I hide /proc/cpuinfo and that worked fine [01:37] goodnight pazzo [01:37] goodnight jes! [01:37] bertl, eyck, JonB - cu! [01:38] night! [01:38] pazzo (~pazzo@host130-250.pool8172.interbusiness.it) left irc: Quit: there are only 10 kind of people on this world - those who understand binary and those who don't :o) [01:40] bengrimm (~ben@bengrimm-host225.dsl.visi.com) joined #vserver. [01:41] damjan (~damjan@217.16.68.253) joined #vserver. [01:41] cu [01:41] mcp (~hightower@wolk-project.de) left irc: Ping timeout: 480 seconds [01:49] ok, to hide it Bertl I do "setattr --hide /proc/stat" for example right? [01:49] depends on the version ... [01:49] alpha [01:49] .29.196 [01:49] with 1.3.8/vs0.09.x you have to deactivate the admin and watch flag to make it disappear [01:51] damjan (~damjan@217.16.68.253) left irc: Quit: Leaving [01:51] mcp (~hightower@wolk-project.de) joined #vserver. [01:52] so..."setattr --admin --watch --hide /proc/stat" ? [01:52] on 1.3.7 this will make it disappear [01:53] on 1.3.8 only for the vserver [01:53] ahhhh [01:54] the 'new' logic is explained on the wiki somewhere ... [01:55] but I'm on alpha [01:56] (kernel 2.6.3) [01:56] is that 1.3.8 logic? [01:57] again, depends on the version, latests 0.09.7/8 should have the new logic, not sure when it was introduced .. might be there since 0.09 ;) [01:57] lol ok ty [01:59] is there since 0.09 :) [02:00] jes_: that man should know it, he wrote the wiki page ;) [02:01] i actually tried it, i'm still on 0.09 [02:01] ;) [02:02] ahhhh ty Doener [02:06] ExpiryJames (~james@h24-71-63-164.ok.shawcable.net) left irc: Quit: Leaving [02:07] Bertl: have you read http://www.isi.edu/~johnh/PAPERS/Heidemann91a.html ? [02:07] hmm, not yet ... [02:09] Method (Method@ip68-12-167-163.ok.ok.cox.net) joined #vserver. [02:10] ok, so i made a chroot, the step by step guide says to check the config file but i have none [02:10] i don't see docs on creating one either [02:10] im currently buildng a BSD kernel with union mount support to play with it. its based off of the statcable filesystem paper. [02:11] stackable i mean. [02:11] 19:27 < Bertl> vserver TEST build -m skeleton --hostname TEST --netdev eth0 [02:11] --interface 192.168.0.1/24 --context 1001 --force -- -d gentoo [02:11] ok [02:12] Can not find vserver-setup [02:12] have a chat with enrico n(he should be around ensc) he probably knows the best way to do it ... [02:14] JonB (~NoSuchUse@129.142.112.33.ip.tele2adsl.dk) left irc: Quit: Leaving [02:14] Method: when do you see 'Can not find vserver-setup'? [02:14] bengrimm (~ben@bengrimm-host225.dsl.visi.com) left irc: Read error: No route to host [02:15] bengrimm_ (~ben@bengrimm-host225.dsl.visi.com) joined #vserver. [02:16] bengrimm_ (~ben@bengrimm-host225.dsl.visi.com) left #vserver. [02:16] nm [02:18] server gentoo-1 start [02:18] Action: ensc is using binutils in the vserver scripts? ;) [02:18] /usr/sbin/vserver: line 381: ip: command not found [02:18] Method: you need iproute(2) [02:18] Hmmm....just tried compiling http://www-user.tu-chemnitz.de/~ensc/util-vserver/alpha/util-vserver-0.29.197.tar.bz2 and get errors [02:18] oh, ok [02:18] Action: cdub tosses iproute2 at Method ;-) [02:18] jes_: where? [02:19] gcc -g -O2 -std=c99 -Wall -pedantic -W -o src/.libs/vunify src/vunify.o lib_internal/libinternal.a lib/.libs/libvserver.so -Wl,--rpath -Wl,/usr/local/lib [02:19] lib_internal/libinternal.a(matchlist-initmanually.o)(.text+0x356): In function `getConfigfileList': [02:19] lib_internal/matchlist-initmanually.c:133: undefined reference to `errno' [02:19] lib_internal/libinternal.a(matchlist-initmanually.o)(.text+0x6f4): In function `EreadAll': [02:19] ensc_wrappers/wrappers-io.hc:98: undefined reference to `errno' [02:19] lib_internal/libinternal.a(unify-deunify.o)(.text+0x298): In function `WwriteAll': [02:19] ensc_wrappers/wrappers-io.hc:33: undefined reference to `errno' [02:19] lib_internal/libinternal.a(unify-deunify.o)(.text+0x2b3):ensc_wrappers/wrappers-io.hc:35: undefined reference to `errno' [02:19] collect2: ld returned 1 exit status [02:19] make[2]: *** [src/vunify] Error 1 [02:19] .29.196 compiles fine [02:19] jes_: which compiler? with dietlibc? [02:20] no, without dietlibc.....doesn't compile with diet on my box for some reason [02:20] gcc 3.3.3 [02:22] strange... I verified it on debian-woody,sarge, fc1, fc1.90 and rawhide [02:22] this is Mandrake x86-64 [02:23] hmm, did you try the mandrake src rpm yet? [02:23] no [02:24] http://www.13thfloor.at/vserver/d_release/v1.3.8/util-vserver-0.29.196-1mdk.src.rpm [02:24] compiles here without any issues ... [02:24] yeah 196 works fine Bertl, it was 197 I was trying [02:24] jes_: made you a 'make clean' after your dietlibc experiments? [02:24] sorry I wasn't clear [02:24] just trying that now ensc ;) [02:25] http://vserver.13thfloor.at/Experimental/util-vserver-0.29.197-1mdk.src.rpm [02:26] gah....that was it ensc...doh! [02:26] yeah compiles fine [02:26] apologies ;) [02:26] but 0.29.197 will not work with 0.09.8 it requires some syscall commands not done yet [02:26] ahhh ok Bertl [02:26] Is there some sort of "table" somewhere that says what tools work with which patches? [02:27] not yet, but you can start one on the wiki ;) [02:27] Bertl: the tools for the new syscalls are there, but they are not used [02:27] lol...did I just shoot myself in the foot there? [02:28] hrm [02:28] what do you make of this [02:28] gentoo-1 / # ls proc [02:28] 1 22063 22078 mounts self [02:28] gentoo-1 / # ps -ef [02:28] Error: /proc must be mounted [02:28] To mount /proc at boot you need an /etc/fstab line like: [02:28] In the meantime, mount /proc /proc -t proc [02:29] ensc: hmm, in my tests 0.29.197 fails with 0.09.8, where 0.29.196 works fine [02:29] Bertl: which api version are you announcing there? [02:29] the new one ;) [02:30] chcontext is now a script which calls for chcontext-compat for <0x00010012 and is a noop (for now) else [02:30] (so probably my fault ;) [02:30] will be later a 'vcontext --create vflags ... vcaps ... vcontext --migrate' sequence [02:31] Oual (~val@valzone.zbla.net) joined #vserver. [02:31] hi [02:31] Nick change: Oual -> Val_ [02:32] hi Val_ ! [02:32] Bertl : hi, 2.4.25 vs1.26 & 2.6.3 vs0.09.8 works fine on debian boxes [02:32] Bertl : many thanks [02:32] Method: you'll need to make proc entries visible to the vservers. http://www.linux-vserver.org/index.php?page=Proc-Security [02:32] Bertl : you can add URL http://vallar.linuxfr.org/debian for all packages [02:32] s/\'ll// [02:33] Val_: please add a note/link to the wiki ... [02:33] hu, i have to register myself [02:33] ...ok i try [02:33] Doener: which ones are relavent? why aren't there reasonable defaults? [02:34] Bertl : in "Distribution specific stuff" [02:35] I'd say under Important Links ... [02:36] Method: i still haven't found the time to try out which ones are actually essential... for ps: stat, uptime, sys/, sys/kernel, sys/kernel/pid_max, meminfo ... [02:36] a good concept is /proc/*info and /proc/stat* [02:36] to find out what is needed i currently use: strace ps 2>&1 | grep proc ... maybe Bertl knows a better way :) [02:36] but that is not all ... [02:37] in 1.3.8 there is a 'trace' feature ... [02:37] you can enable the trace flag, and then any access to that entry will be logged [02:41] Bertl : done [02:42] okay, thanks ... [02:44] Bertl : I'll put a link to vserver on linuxfr.org main page [02:44] monrad (~monrad@213083190235.sonofon.dk) left irc: Quit: Leaving [02:45] great, thanks again! [02:45] Bertl : perhaps a big news on it too [03:20] Bertl : i submited a news about vserver on linuxfr.org, now waiting for moderators :) [03:20] great! [03:21] you'll be a star in France ;-) [03:34] bertl: thank you for making the new release [03:35] huh? why's that paul? [03:35] bertl: your effort is appreciated even if I'm still extremely annoyed over one little point [03:35] bertl: because you've put the time into doing it [03:35] bertl: and I now my post to the list isn't exactly positive [03:37] hmm, well as I explained several times, I do not see any reason for changing the interface again ... [03:40] paul (~irssi@195.202.59.90) left irc: Quit: leaving [03:43] so, time to sleep :) [03:44] Bertl : bye, i'll be back [03:44] bye all [03:44] Val_ (~val@valzone.zbla.net) left irc: Quit: zZz [03:46] sladen: but you comment isn't that negative anyway ... [03:46] jes_ (~jes@cpc1-leed5-3-0-cust196.ldst.cable.ntl.com) left irc: Quit: Leaving [03:48] Action: Doener decides to take a break and read up on that vshelper stuff... [03:48] sladen: do you really think that it is that essential to have the syscall (or kernel function?) which calls the vshelper for a 'reboot' in one of the arguments? [03:50] I cannot imagine any situation where a) an environmental variable wouldn't work, and b) I'd care which kernel function requests a reboot ... [03:51]