[00:24] strange. [00:27] Action: vat has to get some sleep... [00:40] Doener_zZz (~doener@pD95888F8.dip.t-dialin.net) joined #vserver. [00:40] Nick change: Doener_zZz -> Doener`` [00:46] Nick change: noel- -> noel [00:47] Nick change: Bertl_oO -> Bertl [00:47] hey Bertl [00:47] kungfuftr: short visit .. very tired ... [00:47] hi jon [00:48] Doener (~doener@p5082D68A.dip.t-dialin.net) left irc: Ping timeout: 492 seconds [00:48] Nick change: Doener`` -> Doener [00:56] okay, have a good wossname, I'm off to bed ... [00:56] cu tomorrow ... [00:56] Nick change: Bertl -> Bertl_zZ [01:51] suhcoolbro (~Suh@216-161-89-245.ptld.qwest.net) joined #vserver. [02:17] JonB (~NoSuchUse@129.142.112.33.ip.tele2adsl.dk) left irc: Quit: Leaving [02:22] grepmaster (~jeffrey@66-101-59-71.oplnk.net) joined #vserver. [02:23] grsecurity for 2.4.24 + vs1.24 is out [02:37] Simon (~sgarner@apollo.quattro.net.nz) joined #vserver. [02:38] grepmaster (~jeffrey@66-101-59-71.oplnk.net) left irc: Quit: BitchX: your way, right away [02:56] suhcoolbro (~Suh@216-161-89-245.ptld.qwest.net) left irc: Quit: NO CARRIER [03:23] Sh[a]de (shade@cpe109.bb101.cablesurf.de) left irc: Quit: Excursion (On IRC.BONGSTER.DE [#wwip, #german-elite and #lov]) [03:43] kungfuftr (~scott@jadis.narnia.org.uk) left #vserver. [05:44] Doener (~doener@pD95888F8.dip.t-dialin.net) left irc: Read error: Connection reset by peer [05:56] . [05:56] hi all [05:56] pidof: can't read sid from /proc/4/stat [05:57] and few others like at startup of a vserver [05:59] . [05:59] a lot more at vserver vs stop [06:01] hmm [06:02] removed contents of /vservers/vs/proc/ [06:02] solved [06:02] thanx for your help [06:02] np [06:02] any time [07:48] vat (vat@pD9E3736A.dip0.t-ipconnect.de) left irc: Ping timeout: 480 seconds [07:49] vat (vat@pD9E3749C.dip0.t-ipconnect.de) joined #vserver. [08:07] SG1 (~sgarner@apollo.quattro.net.nz) joined #vserver. [08:07] Simon (~sgarner@apollo.quattro.net.nz) left irc: Read error: Connection reset by peer [08:13] SG1 (~sgarner@apollo.quattro.net.nz) left irc: Quit: so long, and thanks for all the fish [10:20] noel- (~noel@pD9E0945A.dip.t-dialin.net) joined #vserver. [10:21] Nick change: Bertl_zZ -> Bertl [10:28] noel (~noel@pD9FFAD5A.dip.t-dialin.net) left irc: Ping timeout: 504 seconds [11:33] Nick change: Bertl -> Bertl_oO [12:11] morning.. [12:34] kestrel (athomas@dialup51.optus.net.au) joined #vserver. [12:41] Nick change: Bertl_oO -> Bertl [12:41] hi all! [12:49] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [13:00] hello herbert [13:00] hi alec! [13:34] huhu herb [13:34] hi vat! [13:35] short question... ipv6 and khttpd does not work with the 2.4.22-vs1.22 patch.. can you say me why? ;) [13:35] http://cvs.x-bone.de/errors.txt [13:39] simple tcp_ip stuff. [13:42] looks nice ;) [13:50] i really don't know why, but okay ;). [13:51] well,looks like ipv6 without tcpip ... [13:59] BobR (~georg@MAIL.13thfloor.at) joined #vserver. [14:02] yep.. dunno why :) [14:02] http://www.devilnet.net/rfc3203/PoS-InternetDraft.txt - hm. should try this :P [14:03] avian carrier is better ;) [14:04] http://www.faqs.org/rfcs/rfc1149.html [14:07] hehe ;) [14:09] depmod: *** Unresolved symbols in /lib/modules/2.4.22-vs1.22/kernel/net/8021q/8021q.o [14:09] depmod: dev_change_flags [14:09] depmod: vlan_ioctl_hook [14:09] narf. [14:09] br0ken. [14:10] hmm, why are you bashing at 2.4.22/vs1.22? [14:10] just for testing some old stuff.. [14:11] hmm .. interesting ... [14:18] maybe just a problem with the ipv6 file patches... [14:19] will return in about 30min [14:19] Nick change: Bertl -> Bertl_oO [14:19] oki :) [14:39] say_out (~say@212.86.243.154) left irc: Ping timeout: 480 seconds [14:42] ehhhh. [14:46] 2.4.22-vs1.22 is b0rken *hmpfz* [15:00] Bertl_oO, strange. 2.4.22-vs1.21 works without any problem.. and ipv6 works also ;) [15:43] Nick change: Bertl_oO -> Bertl [15:43] vat: this is the debian stuff, I guess?! [15:45] maybe. [15:46] hmm you don't know, which kernel this is? [15:46] 2.4.22 of kernel.org ;) [15:46] hmm, okay .. seems you managed to confuse me?! [15:47] hrhr ;) [15:47] http://www.13thfloor.at/vserver/s_release/delta/delta-2.4.22-vs1.21-vs1.22.diff.asc [15:47] this is the change between 2.4.22-vs1.21 and 2.4.22-vs1.22 [15:48] ah. [15:48] now those changes could never-ever affect ipv6, right? [15:49] yep. [15:49] i really don't understand why it isn't working.. [15:49] but okay. it's linux. [15:49] now it works, life and development goes on ;) [15:50] I would search between monitor and chair ... ;) [15:51] hmm.. many bottles of beer (yesterday evening). [15:52] ;) [15:52] 1 [15:52] (/me) [15:52] hmm?! [15:52] and 1/3rd bottle of tequilla [15:52] what about you vat [15:53] Action: Bertl had 2 and 1/2 litre ... [15:54] cola of course ;) [15:56] :D [15:56] i should eat more before i start drinking ;) [15:56] or at least something [15:57] ...had "Starkenberger"..for thinking to herb :P [15:58] but it would be better to drink the local "Ahornberger" next time again ;)) [16:00] hmm, didn't like the tyrolian beer? [16:01] nah ;) [16:01] time for a curry sausage now... brb ;). [16:06] hi [16:07] i've a problem with multiple IPs on one vserver [16:07] the doc's say: IPROOT="1.2.3.4 2.3.4.5" [16:07] but in my case only the last ip is working and ifconfig shows 4(!) interfaces [16:07] i use 1.24 [16:15] ah damn typo ;) [16:15] rmoriz, normal ;) [16:15] at least the "default" broadcast value was not correct [16:31] kestrel (athomas@dialup51.optus.net.au) left irc: Quit: Hey! Where'd my controlling terminal go? [16:39] say_out (~say@212.86.243.154) joined #vserver. [16:43] rmoriz: please show me your config ... [16:59] serving (~serving@213.186.190.24) left irc: Read error: Connection reset by peer [17:00] mhm, now that i cleaned up my flat, i noticed the gin stuff i had too [17:01] kestrel (athomas@dialup51.optus.net.au) joined #vserver. [17:23] hm. 2.6.2-rc1 *thinking over*. [18:23] bertl: i've been thinking of some method to validate packets for vservers easier... [18:28] hmm, packets or packages? [18:29] packets tcp/ip [18:29] udp [18:29] okay, let's hear ... [18:30] how they are transferred to each vserver, meaning how they are checked [18:30] well, today, the stack checks the packets for destination-stamps, and checks each vserver? [18:30] hmm, well no [18:31] old docs? [18:31] :) [18:31] hmm, which docs? [18:31] okay, let's hear it anyway ... maybe it's useful ... [18:34] ok.. If I understood the information regarding how ctx handles packets(network data) the kernel handles a list of all interfaces (as usual in the rootserver), and each interface is checked towards the responding vserver. As the ctx handles it towards the respective interface in the vserver there should be a possibility to maintain an internal structure of 'used' and 'unused' ip's in the root-server as well, avoiding latency on the check for where a packet sh [18:35] a simple structure in the ctx-part that says 'interface off' of 'interface on', and also having a genuine 'context' id for each interface [18:36] hmm, okay let me explain what vserver networking currently does, as far as I understood it ;) [18:36] please do, as I'm a bit confused about it. [18:36] there is chbind, and it adds a structure to the current process, which contains a list of ip addresses ... [18:36] I've got ideas up my sleeve, but I just need a proper info on how things are handled. [18:37] nothing else is done at the chbind invocation ... [18:37] hm, that's where I want to at a context/structure management, avoiding the 'which ip do you want' for the vservers. [18:37] now, when the process (or a child, as this struct is inherited), creates a socket and tries to 'bind' it to an ip ... [18:38] Yeah, THATS what I was thinking about [18:38] the list of 'allowed' ips is checked, and the bind is rejected if it can't be found ... [18:38] Rephrase from me here! [18:38] but this has nothing to do with incoming packets ... [18:38] nonono, it's filtering [18:39] see, what I was thinking about is: [18:39] the packet traverses the network stack the same way it would on a non-vserver host ... [18:39] 1) 254 ip's in a vserver... [18:39] vserver or host? [18:39] vserver [18:39] okay [18:39] not the host [18:39] each ip is checked isn't it? [18:39] well on a bind, yes [18:39] according to the web about more than 16 ip's blabla [18:40] well ok, THATS where we couyld cut in a few checks [18:40] -y [18:40] okay ... [18:40] and how? [18:40] you said that chbiond allocates just a simple list of ip's available right? [18:40] *chbind [18:41] yes [18:41] ok, what if the vs can allocate these themselves, and in a different structure than chbind? [18:41] avoidiong chbind, but still allowing the root-server to route packets to the respective interfaces [18:42] thus, making a superstructure for each vs, allowing them to allocate the bind-areas for the respecitve ip's themselves [18:42] then binding a process to an ip would be done by the vs, not chbind allowing it or disallowing it [18:44] well the vserver processes can decide which addresses to bind to .. so the 'allowed' range check would only be a more general way of specifying ip's but the same checks would be required as with the ips atm [18:44] it might sound stupid, but the bottleneck for vhosting-servers, having more than 16 ip's, is the chbind checking [18:45] you can't allow the vserver to bind to arbitrary ips ... because this would be a security issue ... [18:45] no, not to arbitrary ones, only to those in its cfglist [18:45] okay, that is what currently is done ... [18:46] maybe I just don't understand where you want to go ... try again ... [18:46] ok. again. [18:48] chbind allocates each vs'es interaces, and checks for processes binding to it, right? [18:48] http://www.13thfloor.at/vserver/d_release/v1.3.5/split-2.4.24-vs1.3.5/07_2.4.24_net.diff.asc [18:48] that is the current devel code ... [18:51] tcp_addr_in_list [18:51] does the checking (for tcp and udp) [18:51] it's a little below the middle .. [18:58] serving (~serving@213.186.190.24) joined #vserver. [18:58] yup, found it [18:58] reading up on it now [18:59] well, it's quite simple, it's a sequential check ... [18:59] mnemoc (~amery@200.75.4.104) joined #vserver. [18:59] hi [18:59] hi Alejandro! [19:00] :) [19:00] syncing up on vserver? [19:00] yep [19:00] i have a question [19:01] is vr-tools included in vserver-utils-0.27? [19:01] go ahead, ask ... [19:01] let me check, I'm not sure ... [19:02] nope, doesn't seem so, enrico? [19:03] so the packages must be: [19:03] vserver=kernel patch + vserver-utils + vkill + vproc [19:03] vquota=kernel patch + cq-tools + vr-tools + CONFIG_QUOTA + CONFIG_*_VROOT [19:04] the vkill and vproc are included in the latest util-vserver tools IIRC [19:04] hm, doing a sequential check might not be the best optimized method imho.. [19:04] mnemoc: honestly, I don't know why the vrsetup wasn't included yet [19:05] bertl: can't it be implemented as a listcheck, allocated to each context instead? or is it linked to each context already? [19:06] well it is linked to each network-context (chbind) so this is similar to context, but not identical ... [19:07] hm, it should be linked to each context directly to avoid the sequence-checking [19:08] but that might be a trickier solution to add [19:08] that would not help ... [19:08] assume the ip-list would be per context ... [19:08] mhm [19:08] what would it buy you for a bind? [19:09] you'd have to walk it, the same way it is done now, just to check, that the bind is okay?! [19:10] mnemoc: you should talk to enrico, he is currently finishing his next generation tools ... they'll not only support future vserver interfaces/functionality, but also include some 'new' creation tools ... [19:10] s/finishing/finalizing/ [19:10] hm.. [19:10] *thinking* [19:11] There's got to be some way to get that part done quicker. [19:11] I'll dig some more into my own head for a solution on that part [19:11] if you want to support more ips per vserver (I don't see any reason for doing so), you'll ahve to find a clever way (like a tree, or just ranges) to speed up that check ... [19:12] hm, well, most vservers with larger pools of ip's allocate them using ranges. [19:12] what is the reason for doing more than 16ips or maybe 32ips on one vserver? [19:12] shellhosting, for instance [19:13] Bertl: do you plan to merge vquota into vserver soon? (<2 month) [19:13] OOOOUCH! [19:13] Darned cat. [19:14] enrico's nick? [19:14] Put her claws in my jeans, directly into my foot. [19:14] mnemoc: hmm good question ... well the devel branch will get it, the stable I guess not so soon (enrico = ensc) [19:14] click: shellhosting means what exactly? [19:15] irc-shells with different hosts outbound for all users [19:16] irc_shells? what's that? on one vserver? [19:18] yeah, we've put all the shell-accounts onto a vserver, splitting it from the other daemons (apache, mail etc) [19:18] thus avoiding users trying to exploit those services from their shells [19:18] okay shell is something like ssh access for me, what does shell mean for you? [19:19] ssh access/telnet/ftp [19:19] and this is to one vserver, but for different ips? [19:19] if they want to use irc, they can choose from all the hosts bound to the vserver [19:19] xx.xx.xx.11-xx.xx.xx.199 [19:19] where is the sense in using different ips? [19:20] getting different hostnames on irc [19:20] allowing each user to bind to whatever hostname they see fit for their bots, irc-clients, irc-servers etc [19:20] hmm, okay that I can understand ... [19:21] well, and I guess I ahve a solution for that 'special' case too ... [19:21] that's why I've been thinking of the 16 ip limit-restriction, and how to optimize the handling there [19:22] just add a (net)mask and apply that before each check ... [19:22] this way you can permit entire network ranges via one ip ... [19:36] okay, have to leave now, will be back around 23:00 CET ... [19:36] cu later ... [19:36] Nick change: Bertl -> Bertl_oO [20:40] Doener (~doener@pD95888F8.dip.t-dialin.net) joined #vserver. [20:42] hi [20:53] Nick change: noel- -> noel [22:14] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Quit: Tak ja padaaaaM [22:24] mcp (~hightower@wolk-project.de) left irc: Ping timeout: 492 seconds [23:36] JusHal (~justin@node152cb.a2000.nl) joined #vserver. [00:00] --- Thu Jan 22 2004