[00:54] JonB (~jon@129.142.112.33) left irc: Quit: Client exiting [01:13] ]righto, sparc testing... [01:13] hmm ... this means you started testing on sparc? [01:13] i'm about to start sparc64 [01:14] just finding your list of tests in the ml [01:14] pefect, let me know how it works out ... [01:14] shall do [01:14] 1.1.3 is the latest i assume? [01:14] anyone know any{one, place} to stay in {Brussels,Amsterdam} tomorrow night ? [01:15] hi paul! sorry no info ... [01:17] Action: Zoiah is only a mere 200km away from Amsterdam. ;) [01:17] hello bertl. :-) Yeah, I have Eurostar tickets London -> Brussels but nowhere to stay yet! [01:17] zoiah: tell me more! I have a ticket that lets me go to *any* station in .nl [01:18] cool, we tried once to buy a power distributor at the airport, but no luck ... ;) [01:19] (in amsterdam, and because we forgot ours, I mean ;) [01:26] I have a 4-way with UK sockets on it which I hacked to take a IEC kettle lead [01:29] well, I don't know the uk sockets (yet) ... [01:32] Nick change: kestrel -> kestrel-idle [01:33] still compiling herbert [01:33] dum de dum [01:33] speedy [01:33] Nick change: kestrel-idle -> kestrel [01:39] well, maybe you could reduce the compile time, by removing unnecessary parts (filesystems, special network stuff ... ) [01:39] or at least compiling them as modules? [01:41] okay guys, I'm off to bed ... trying to cure my cold ... [01:41] later Bertl [01:41] Action: WSU_ is back (gone 70:32:45) [01:42] Nick change: WSU_ -> WSU [01:42] any last questions? [01:42] not at the moment [01:42] perfect ... [01:42] Nick change: Bertl -> Bertl_zZ [01:43] bye herbert [02:03] Nick change: riel -> unriel [02:12] kestrel (~athomas@202.139.83.4) left irc: Ping timeout: 492 seconds [05:34] say-out (~say@212.86.243.154) joined #vserver. [05:35] say (~say@212.86.243.154) left irc: Ping timeout: 493 seconds [06:17] kestrel (~athomas@o2rosock0a.optus.net.au) joined #vserver. [06:27] infowolfe (infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) joined #vserver. [06:27] anybody awake? [06:27] Bertl_zZ, ping? [08:02] loger joined #vserver. [08:12] infowolfe (infowolfe@68.33.215.209) joined #vserver. [08:13] Bertl_zZ, when you wake up, check your email, i'm having issues with gentoo, /dev/initctl and possibly more by the time you're awake [08:13] oooooh yeah, it's rc-script debugging time :-p [08:24] still getting the /dev/initctl problems... :( [09:15] loger joined #vserver. [09:47] Last message repeated 1 time(s). [09:47] infowolfe (infowolfe@68.33.215.209) left irc: Quit: Trillian (http://www.ceruleanstudios.com) [09:47] infowolfe (infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) joined #vserver. [10:32] anybody alive/awake? [11:37] re [11:37] mhepp (~mhepp@213.211.38.19) joined #vserver. [12:00] say_ (~say@212.86.243.154) left irc: [12:11] mcp (~hightower@81.17.110.148) left irc: Ping timeout: 492 seconds [13:13] Xorader (~xor@81.18.128.249) joined #vserver. [14:02] serving (~serving@213.186.191.21) left irc: Ping timeout: 480 seconds [15:54] serving (~serving@213.186.191.15) joined #vserver. [16:17] MedivhWrk (MedivhWrk@gw-mcb-briteline.multimedia-centrum.de) joined #vserver. [16:24] mhepp (~mhepp@213.211.38.19) left irc: Remote host closed the connection [16:39] Nick change: unriel -> riel [17:07] hi all [17:08] I am modifying the install-rh9.0 script to install fedora instead. It is a staight forward thing where I am replacing RedHat with Fedora in the paths [17:09] I am hiting a block when I install minimum. I am not sure if this was working originaly [17:10] could any of you install a rh9 minimum usingthe provided script ? [17:10] it looks like the script is not able to interpret [17:10] rpm --root /vservers/ftestm/ -Uvh 'cat /usr/lib/vserver/fc1-minimum' [17:11] it reports : [17:11] error: open of cat failed: No such file or directory [17:11] > /usr/lib/vserver/fc1-minimum: read manifest failed: Success [17:26] it should be `cat /usr/lib/vserver/fc1-minimum`, not 'cat /usr/lib/vserver/fc1-minimum' [17:29] ensc (~ircensc@134.109.116.202) left irc: Ping timeout: 493 seconds [17:33] Nick change: Bertl_zZ -> Bertl [17:34] ensc (~ircensc@ultra.csn.tu-chemnitz.de) joined #vserver. [17:34] hi enrico ... also 0.24.90 ist jetzt die 'neue' stable?' [17:35] release candidate [17:35] okay, so there will be a 0.25 soon? [17:35] yep;will add the gentoo stuff probably. It does not seem to do any harm ;) [17:36] I'm asking, because I have to replace the 0.24 version as recommended since it _is_ buggy on all versions ... [17:38] and I dont want to confuse people by changing it every day ;) [17:39] [root@vserver-test i386]# rpm -ihv util-vserver-0.24-0.i386.rpm [17:39] error: Failed dependencies: [17:39] /usr/bin/shellmod is needed by util-vserver-0.24-0 [17:39] hmm, where to get? ;) [17:39] hi all, by the way! [17:40] hi Bertl ;) [17:43] MedivhWrk: what is the source of this rpm? [17:44] the spec shipped with util-vserver should not add this dependency [17:44] uh, took the one from http://vserver.13thfloor.at/Stuff/util-vserver-0.24-0.src.rpm and rebuilt it [17:45] maybe you should try the 0.24.90 and do rpm(build) -ta > [17:46] okay, so i will ;) [17:48] ah... bertl removed the %exclude statements... [17:52] yup, was necessary for mandrake ... [17:55] @MedivhWrk you are going to test the vnet patch? [17:56] @enrico is there a problem with removing them? [17:56] Bertl: without these %excludes, you will add the linuxconf-files inclusive the /bin/shellmod dependency [17:57] okay, then we have to find a solution for mandrake ... [17:58] updating rpm would be a solution... ;) [17:59] rpm-4.0.3-10mdk isn't new enough? [17:59] yep i'm going to test vnet [17:59] okay, you need to know some things, as this is highly experimental ... [18:01] Bertl: the rpm-4.0.4 changelog mentions %exclude [18:01] but 4.0.3 should have it too [18:02] warning: File listed twice: /usr/sbin/newvserver [18:02] warning: File listed twice: /usr/share/man/man8/newvserver.8.bz2 [18:02] Segmentation fault (core dumped) [18:03] rpm -ta util-vserver-0.24.tar.bz2 [18:04] Bertl, so what's it I need to know? ;) [18:04] hmm, this might explain the '- fix: %exclude functional (again).' statement in the 4.0.4 changelog [18:04] @MedivhWrk okay ... first, you now should have an uninitialized vnet0 interface ... [18:05] you can verify that with ifconfig vnet0 [18:05] hm, actually, i don't [18:05] [root@vserver-test util-vserver]# ifconfig vnet0 [18:05] vnet0: error fetching interface information: Device not found [18:05] well, then you do not have patched the vnet patch?! ... [18:06] or maybe you just didn't enable the vnet device option in menuconfig? [18:06] the patch is applied, 100% sure, and i think i also enabled vnet ... wait [18:06] let me double check [18:07] bah [18:07] @enrico maybe a #if >= 4.04 ... or something like this? [18:07] checked the option above it ;) [18:07] hmm, wont work, I guess ;) [18:08] rebuilding ... may take a few though, only a PII 233 in that machine [18:09] i was going to use the celeron 850 i had lying around, but no, the mainboard was dead [18:09] well, if you did a make bzImage and not a make clean first, it should be done in a few minutes ... [18:09] hm, i don't have to do the clean? ;) [18:10] always thought i had to :p [18:11] - if you change the file structure, you have to redo the 'make dep' [18:11] - if you change the config, you just do the 'make bzImage modules' [18:11] - a make clean is only required, if you changed the file dates or messed up the dependancies ... [18:12] ah ... thanks for the explanation [18:12] okay, I'll try to explain some details regarding the vnet device in the meantime ... [18:13] this is a hack, so there is only one vnet device yet ... and it is 'bound' or 'associated' with eth0 ... [18:14] further, it has a magic selection scheme, which is fixed to ip addresses with a final octet of 10 (0x0a) [18:14] do you have 'another' machine on the same eth0 lan? [18:15] yep, 3 more actually [18:15] okay, ist this a local network? [18:15] well one of the 3 other machines acts as a gateway for the rest, 1 mbit dsl connection connected to it [18:16] okay, and you use what? 10.0.0.x or something like that? [18:16] 192.168.0.0/24, though i could change that if necessary [18:16] no problem with that, any machine at 192.168.0.10 yet? [18:16] nope [18:17] good, we'll use that for the vnet device ... [18:17] (the .10 is the magic trigger ;) [18:17] recompile and reboot complete btw, vnet0 is there now [18:17] perfect .. first we have to setup the hw address of this interface ... [18:17] ifconfig vnet0 hw ether 0:11:22:33:44:55 [18:18] then we setup the ip of this interface ... [18:18] ifconfig vnet0 192.168.0.10 [18:18] can i use any hw address for vnet0, or should it be some special one? [18:19] well, you should use the one given above, so you can easily track this one ... [18:19] okay [18:19] done ;) [18:19] but as usual, any MAC address is okay ... [18:20] okay, now try to configure/setup a vserver which uses vnet0:192.168.0.10 ... and starts some services there ... [18:21] for example ssh/telnet/http ... [18:22] okay ... i will actually walk back home first though, finished here at the office ... and continue from there setting up the vserver [18:23] Action: ensc would not do any network setup from a remote place... ;) [18:23] coward! ;) [18:23] well the machine is at home anyway so ;p [18:24] be back in, say, 20-30 mins ;) [18:24] cu then ;) [18:24] MedivhWrk (MedivhWrk@gw-mcb-briteline.multimedia-centrum.de) left irc: Quit: ircN 7.27 + 7.0 for mIRC (2002/01/10 00.00) [18:26] okay enrico, so when will the 0.25? release be there? (sorry to bug you) [18:26] I think somewhere today (CET)... [18:29] okay, then I'll wait .. and link the 2.5 later ... just let me know, thanks for doing vserver tools by the way ;) [18:29] s/2.5/0.25/ [19:11] back ;-) [19:12] fine ... [19:13] okay, where was I .... [19:13] ahh, yes, already succeeded in starting a vserver on that interface/ip? [19:16] not yet, just got home and had some food ;) [19:16] gonna install a vserver now ... anyone finished a minimum package list for fedora core 1 yet? [19:21] Bertl, what is the magic about the .10 though, btw? ;) [19:21] well, the vnet device will 'grab' any address ending in .10 ... [19:22] hm, so i can't use anything else but .10 on the vnet interface? [19:22] so this is the 'magic marker' which could in future be replaced by any ip matching code ... [19:22] zyong (cat@bb220-255-105-48.singnet.com.sg) joined #vserver. [19:22] hi bert! [19:22] hi zyong! [19:22] *gives bert a BIG hug* [19:22] Medivh: http://www-user.tu-chemnitz.de/~ensc/min-fc-1.txt should be nearly minimal [19:23] Action: Bertl is honored ... [19:23] thanks Enrico [19:23] @zyong we did it right again? [19:25] uhh? [19:27] Good evening guys. [19:27] i am addicted to kernel patching all thanks to herbert potzl [19:27] hi virtuoso! [19:31] @zyong so I assume you are recompiling you kernel day and night, with much fun ... right? [19:31] .... yes [19:31] lol [19:32] @all,enrico I would like to have a short discussion regarding RH, RHEL, Fedora and CO ... [19:32] s/CO/others/ ... [19:32] Bertl: do you want to write a patch for their kernels? ;) [19:33] well, that is one question I would like to discuss ... [19:33] would it be difficultly? [19:35] well, let me put it this way, I think it is possible to support RH* kernels in the 'newer' development branch ... if there is enough testing, and a good reason not to use vanilla kernels on that platforms ... [19:35] s/platforms/distros/ [19:37] bert, freebsd? [19:37] Do RHs kernel differ much from Linus' branch? [19:37] Bertl: reasons could be missing NPTL and non-exec-stack support for some people. Unsupported hardware support also [19:37] virtuoso: Linus doesn't have a 2.4 branch ;) [19:38] currently he hasn't any branch, hi rik! [19:38] FreeBSD goes su^Wsmoking with their jails. [19:39] Bertl, riel: What are you talking about? :) [19:40] well, you asked the difference between RH and Linus kernels ;) [19:40] RH has 2.4 based kernels, Linus doesn't [19:40] so yeah, there's a big difference ;) [19:41] That's all clear except why Linus doesn't have 2.4? [19:41] 2.4 is Marcelo branch, 2.6 is Andrew branch ...2.7 will be Linus branch ... [19:41] Hm. I see. [19:42] 2.2 was Alan, and now is? [19:42] yeah [19:42] might still be Alan, 2.2 doesn't take much time [19:42] 2.0 and 2.2 maintenance are easy now ;) [19:42] security bugfixes only [19:42] no new hardware support in general [19:42] removing the dust from time to time ;) [19:46] okay, so NPTL is an argument, but I have to ask: a) why does *** decide to 'break' the stable 2.4 kernel API? and b) which distros actually use the NTPL stuff [19:47] s/[NTPL]\{4,4\}/NPTL/g [19:48] shall I invite some RH developers to this channel? ;) [19:48] nptl is a rare thing I guess. [19:48] @enrico yes, please do so ... [19:49] is the freenode <-> oftc gateway still alive? [19:50] I guess not, otherwise alekibango would still be here, right? [19:51] Oh, BitchX doesn't support more than one server at a time? :) [19:52] hmm, doesn't it? [19:52] 17:52 < Sopwith> ensc: Because life without NPTL sucks... [19:52] that's a good reason for breaking a stable interface ... [19:53] maybe we can change the sys_open() syscall in vserver too ;) [20:06] okay, so who exactly uses the NPTL patched kernels, and has such a glibc that it can't cope with non NPTL patched kernels? (distro/version please) [20:08] by the way, I still don't understand why NPTL requres _any_ kernel changes, as it should be a userspace library, right? [20:08] afaik, only RHL9, FC1+ and RHEL3 has NPTL support [20:09] with some tricks (recompiling db4) you got most programs to run on vanilla kernels [20:10] what I don't understand, how does a threading library require kernel modifications? it linux threading not sufficient for NPTL? [20:10] NPTL needs some special support for thread creation, and O(1) is required also. http://people.redhat.com/drepper/nptl-design.pdf [20:10] okay, so it sounds like a 2.6 feature, right? [20:11] it will be/is in 2.6 [20:13] RHL9 == RH 9.0 ? [20:14] no, Red Hat Linux 9 [20:14] ;) [20:14] okay, which is? [20:14] Shrike [20:15] and fedora works with vanilla kernels, but uses NPTL? [20:16] with some (one?) exception: yes (db4) [20:17] are there some NPTL patches (for the kernel) available somewhere? [20:17] and don't point me to the redhat/fedora source ;) [20:18] I am in doubt about it... you will have to apply/search the patches from the kernel src.rpm [20:18] so this is a 'all-in-one' redhat only feature then? [20:19] debian, gentoo,etc ... will never use NPTL? [20:19] no; an 'all-in-107' feature ;) [20:21] Bertl: http://people.redhat.com/~mingo/nptl-patches/ [20:24] hmm, well it's a long patch, and adds plenty of (useless?) stuff, but can anybody verify that a thusly patched ac kernel is able to use the NPTL userspace/glibc on those distros? [20:26] because we then could make a NPTL patch available, maybe together with the O(1) patch, which provides the 'minimum requirements' for NPTL userspace ... [20:30] the nptl patch applies to the ac1 kernel at least... [20:30] hehe ;) [20:31] it seems they modified clone() and the signal handling ... exec() and some futex stuff ... [20:40] mmh, devfs does not compile [20:42] well, devfs was abandoned ... without working replace (and no I don't count udev as replacement, as it needs a userspace helper to create the device nodes) [20:43] but to test the kernel, I need devfs [20:43] but I guess, I fixed it... [20:43] s!o_pptr!real_parent! [20:55] ok, kernel compiled... [20:56] this is now fedora, right? [20:56] 2.4.22 + ac1 + nptl; with gcc-3.3.2 [20:57] yup, but on what distro are you going to test it? [20:57] it is redhat rawhide base (newer than Fedora Core 1) [20:57] okay ... [21:00] has anybody lately experienced problems with >2TB filesystem/partition support ;) [21:03] Action: virtuoso would like to have such problems. [21:04] Bertl: ac1 + nptl seem to provide NPTL functionality [21:04] well, so this would be a way to go, right? [21:05] yes, when a vserver-patch could be provided for ac+nptl, the adaptions for the RH kernels would be much easier... [21:06] I'm not saying that this _is_ the way we should go ... but it's an option ... [21:06] dunno, how invasive the random vm mapping and non-exec-stack is... [21:06] the problem I see with RH* kernels is, that there will be a multitude of, right? [21:08] yes... :( [21:08] so each RH* distro/branch/whatever will need it's own patch to be happy ... and this doesn't sound good to me, unless somebody will actively maintain those kernel patches ... [21:09] I have no problem with an initial port, and I can help to add/adapt the deltas .. but that pretty much is it, for a distro I don't use (yet) ... [21:12] @virtuoso me too, just read it on LKML ... [21:29] shuri (~ipv6@207.236.226.187) left irc: Remote host closed the connection [21:45] Eryr (~druida@102.27-182-adsl-pool.axelero.hu) joined #vserver. [21:45] hi [21:45] hi! [21:46] g (~g@203.16.231.146) joined #vserver. [21:46] hi [21:46] @enrico so the question is, is somebody willing to maintain separate branches for RH* or do we go for a 'modified' kernel supporting NPTL and the exec() stuff ... [21:46] hi g! [21:47] g==geoffrey? [21:47] yes [21:48] that was quick ... [21:48] had a look at your page ... [21:48] Bertl: dunno, I do not know somebody who will do this ;) [21:48] we should definitely add some per distro support page on linux-vserver.org (or at least links) [21:49] can i ask about cpu and memory limitation? [21:49] I saw the wiki, but I don't know if you'd want to put the whole script in there [21:50] it really needs to work based on a config file too [21:50] @g short info: I fear that doing a RH* version of vserver will add >5 different branches ... which all need update etc ... [21:50] @Eryr yes, please go ahead .. [21:52] @g I think we should add an Overview Page, which addresses the Distro specific anomalies and specialities, by listing each distro, and linking to another page, where the detail should go ... one of them could be your page for example ... [21:52] bertl: I presume you're talking about kernels, not userspace tools? [21:53] @g yes, but the glibc recompile would not be necessary, if we had a FC1 kernel patch ... [21:53] first if these limitations are done yet, where can i read about them? :) [21:53] Bertl: Each vserver maintains its own copy of evey file, correct? [21:53] bertl: let me understand this: will fedora core 1 not work with a kernel.org kernel anymore? [21:54] bertl: that is, without recompiling glibc [21:54] @g nope .. because of NPTL and the exec stack stuff ... [21:54] Bertl: with my current FreeVSD implementatoin we are using a skel, and have the vservers hard linked to it [21:54] hm, that's not so good. [21:54] @Eryr ... elaborate what you consider cpu limitation, memory limits are in experimental patches ... [21:54] Bertl: then we relink when a vserver needs its own copy [21:54] @WSU that is called unification in vserver ... [21:55] bertl: I don't seem to have had any probs with NPTL. I'm running a few RH9 servers around the place and haven't noticed any trouble. [21:56] well enrico knows more, maybe he can explain ... [21:57] moment please... I have to take care that my food is not burning... [21:57] @Eryr documentation is rare, there are some patches and some people who know how to use them ... [21:57] so the options are: 1) convince rh to make fc1+ work with kernel.org kernels [21:57] 2) vserver maintain separate kernel patches [21:58] or 3) vserver maintain glibc rpms [21:58] ? [21:58] Bertl: who are they? :) and where are those patches? :) [21:58] 4) vserver maintain NPTL on vanilla patch .... [21:59] ummmmm, doesn't FC1 work with kernel.org kernels already ? [21:59] @Eryr http://vserver.13thfloor.at/Experimental/*ml0* are all memory limiting patches ... [21:59] Gandalf (~gandalf@tux.rsn.bth.se) joined #vserver. [21:59] NPTL userland should be able to run fine without an NPTL kernel [21:59] it's just the NPTL kernel that requires NPTL userland [21:59] not the other way around [21:59] riel: it doesn't work with my 2.4.18ctx-12 kernel (don't laugh at the version) [22:00] @rik I thought that too, but IIRC, some userland tools fail ... [22:00] riel: it's not nptl, it seems to be the exec-stack stuff [22:00] I assume you've filed bug reports already ? [22:01] no, I don't yet have an fc1 machine to boot into a different kernel with [22:01] riel: db4 issue is known... [22:01] Bertl: thanks [22:01] no wait, I know you haven't filed a bug report [22:01] otherwise I'd have seen it [22:01] all my fc1 testing has been in vserver so far [22:01] hmm, nope, guess we considered it a feature/rh decision ... [22:01] mmm, I only get bug reports against the kernel, not userland ;) [22:01] ensc: ok [22:02] @Eryr feel free to ask me about the patches ... [22:02] Bertl: "must be able to run the kernel.org kernel" is a MAJOR design goal for RH [22:02] riel: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933 [22:02] well, in this case 'problem delegated' soon to be solved, right? [22:03] otherwise, I do not see NPTL related userspace problems. There was a faulty glibc errata in the last week, but the new version ....7 is fixing it [22:04] Bertl: "Per Context Disk Limits" (doc) gives the quota for one vserver eh? [22:04] I tried to modiy the ishall-rh9.0 script for Fedora Core 1. I failed. :( [22:04] Bertl: So how is the simplest way to go about using unification in the vserver would? I find no mention of it on the various pages... [22:04] Bertl: Also, is the a vserer mailing list/archives I should be following? [22:05] @Eryr nope, that is the Per Context Quota, the disk limit does what it says, a limit to the available disk space ... [22:05] or is IRC it? [22:05] well, probably the best source ;) [22:05] but search/browse linux-vserver.org, there you'll find many answers ... [22:06] (including the mailing list archives) [22:06] Bertl: hmm that disk limit is a full quota for all vserver, nah? [22:06] serving: what's the ishall-rh9.0 script? [22:06] it is in /usr/lib/vserver [22:07] Bertl: as if i put a vserver on a seperated partition [22:07] ensc: eeek ;( [22:07] @Eryr again no, Disk Limit means that the space shown by df (-i) is smaller than the actual available space ... [22:07] hmm [22:07] and this limit is enforced too ... [22:09] serving: have you seen vserver-fc1 at http://www.netcraft.com.au/geoffrey/vserver/ ? [22:09] gaertner (~gaertner@212.68.83.129) left irc: Ping timeout: 493 seconds [22:10] g: I am running FC1 vserver on vanilla 2.4.22 I do not have the described exec-stack problems [22:11] ensc: curious. one day I'll upgrade the kernel on that machine and see if that fixes it [22:12] @Eryr assumed you want to put several vservers on one partition, you'll need to limit the amount of disk space per vserver, right? [22:14] yeah [22:14] is it possible to change this limit without having to restart the vserver? [22:14] yes [22:15] g: I am chekcing it out [22:15] I havn't used vserver in a long time (there's no 2.6 version yet? :) [22:15] and if you want to have individually configurable quota from each vserver (as vserver root) you need the Per Context Quota patches ... [22:16] Bertl: ok, yeah, then i need disk limit now :) [22:16] @Gandalf would require a lot of 2.6 testing, are you willing to test? (I mean experimental stuff, which could crash your system ;) [22:17] Bertl: I'm used to my system crashing when testing patches :) but these days I have a dedicated testsystem for that :) [22:17] Bertl: I'd be happy to test 2.6 patches [22:17] hmm ... how much time would you spend on that? [22:18] Bertl: what would u advise: debian or mandrake? [22:18] what would you advise, tie or bow tie? [22:19] :p [22:19] Bertl: I don't know how much time I'd have to actually do the debugging when it fails, as it is I don't even have enough time to do netfilter hacking [22:19] I'm using Mandrake, you'll have problems with default debian and unification ... [22:19] what kinda problems? [22:20] vunify is RPM based, debian not ;) [22:20] :p [22:20] well.. mandrake :) [22:20] gaertner (~gaertner@212.68.83.129) joined #vserver. [22:21] okay, gandalf sounds reasonable to me ... maybe it's time to start 2.6 vserver development, what do the other think? [22:23] Bertl: unification is when i can use one program from different servers, eh? [22:24] unification is hardlinks between vservers, guarded by immutable flags, weakened by ILI flags ;) [22:24] Eryr: Basically, you have one real file, each vserver has a hard link to that inode/ [22:24] ahm :p [22:25] iirc, I have an old bash-script that just compares all files in two directories (two vservers) and unifies all files that are common to both [22:25] ok [22:25] used that when I ran vservers on debian [22:26] okay gandalf, here is a patch to test: http://vserver.13thfloor.at/Experimental/patch-2.6.0-test9-vs0.01.diff [22:27] how much does it include? [22:28] well, it's the minimal core, only process separation ... a [22:28] but it adds some new stuff .. [22:28] ok [22:28] you are good at netfilter? [22:28] booting testsystem now [22:29] I am a member of the coreteam, so I know a thing or two [22:29] great, could you help us (me)? [22:29] sure, with what? [22:29] I did an highly experimental virtual interface hack ... [22:30] based on NF hooks grabbing the packets from the original interface ... [22:30] and delivering them 'through' the virtual network device ... [22:30] sounds nasty :) [22:30] kind of works (with some issues) [22:31] As I know diddle about network stack .. that was the first approach I did ... ;) [22:31] what is it you want to accomplish? [22:31] I would like to have a vnetX device for each vserver (or more of them) [22:32] so that each vserver can 'bind'/'handle' this interface ... [22:32] and I would like some mechanisms, preferable a netfilter 'mark' which decides which packets go to this interface ... [22:33] everything 'sent' to this interface from userspace, should be checked, and if appropriate, transmitted from a real interface ... [22:33] http://vserver.13thfloor.at/Experimental/patch-2.4.23-rc1-vn0.04.diff (that is the latest version of this hack) [22:33] bertl: is this so that you could eg. permit tcpdump? [22:34] yes, you could permit everything ... [22:34] and still stay secure ... [22:34] everything except changing ip address [22:34] vserver would just see the vnet devices, and not the real devices (maybe with a cloaking name change ;) [22:34] even changing the ip address would be okay ... [22:35] if you choose a 'not allowed' one, your packets just would be dropped ... [22:35] I see. [22:35] what about changing routes? [22:36] gues we'll need a per vserver routing table, but that is something for the next step, I guess .. [22:37] I was thinking about virtualizing the routing tables, based on some (special) NF marking ... [22:37] the kernel already supports multiple routing tables; you could almost do that already, right? [22:37] yes ... that is why virtualizing that should not be too hard ... [22:38] Bertl: I see that you are registering at PREROUTING, that only gets incoming packets [22:38] well, the outgoing packets are handled by device_xmit, no? [22:38] bfn; I've gotta go to bed. [22:39] night! [22:39] g (~g@203.16.231.146) left irc: Quit: Leaving [22:42] @Gandalf so do you see a 'better' approach, I'm not locked on that one, I was just trying to reach the goal with a minimum of kernel modification ... [22:42] Bertl: have you looked at the IMQ patch? [22:42] which is, does, I can find where? [22:43] http://trash.net/~kaber/imq/ [22:44] hmm, seems to do the 'intercepting' but provides no virtual/separate interface, right? [22:45] it provides two interfaces, imq0 and imq1 [22:45] I've never used it [22:45] yes, but they do not receive any traffic, they just get the qdisc (so says the page ;) [22:45] By default you have two imq devices (imq0 and imq1). These are dummy interfaces, you can do nothing but attach qdiscs to them. [22:46] thanks everything, nite [22:46] Eryr (~druida@102.27-182-adsl-pool.axelero.hu) left irc: Quit: Leaving [22:54] @Gandalf one issue I couldn't solve yet, is the arp table going mad on me ... havent found a way to keep this in sync with the IPs yet ... [23:14] matta (~matta@pcp02730451pcs.potshe01.pa.comcast.net) joined #vserver. [23:14] hello [23:14] hi matt! [23:14] so Bertl... that 8um was an old patch apparently [23:15] rediffing is easy, just needs to be done [23:15] fine, they've got a new one? [23:15] http://aleron.dl.sourceforge.net/sourceforge/user-mode-linux/uml-patch-2.4.22-6.bz2 [23:15] i can rediff it if you want [23:16] if you rediff the vs*prep patches, go ahead, otherwise please don't ;) [23:21] jhh (~heuing@194.245.114.189) joined #vserver. [23:21] hi folks... [23:22] hi jhh! [23:27] Gandalf, still alive? [23:28] 2.6... nice [23:28] you didn't try it yet, right? [23:29] Bertl: yup still alive, had to take care of the laundry [23:29] should read: you haven't tried yet, right? [23:29] Bertl: compiling it right now [23:29] infowolfe (infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) left irc: Quit: Trillian (http://www.ceruleanstudios.com) [23:30] infowolfe (~infowolfe@68.33.215.209) joined #vserver. [23:32] Gandalf, you mean the 2.6 test stuff, right? [23:33] Bertl: yup [23:33] is there any chance you could help with the vnet stuff? [23:34] don't think I'll have time with that tonight : ( [23:34] well, hasn't to be tonight ;) *pleeeze* [23:34] I'll see if I can look at it this weekend, I'll be rather busy until then [23:35] sounds good/fair to me ... thanks in advance ... [23:39] just have to get util-vserver to compile... [23:39] jhh (~heuing@194.245.114.189) left irc: [23:40] well, guess we can help you there, right enrico? [23:40] I will try... ;) [23:42] looks like problems unrelated to vserver, upgrading some stuff now [23:44] What do I need to do to use unification? [23:45] the newserver script has the "sharing" option [23:45] though it didn't seem to work [23:46] you need the tools to change the ILI flag ... setattr/showattr and some concept which files should be linked across vservers (this is easy on RPM based systems) .. [23:47] what distro are you using now? [23:48] I am trying to get this working on a redhat 9 [23:48] okay, should be fairly easy, util-vserver or vserver tools? [23:48] vserver tols [23:48] *tool [23:49] okay, 0.26 I assume? [23:49] and the 1.0 relase patch against 2.4.22 [23:49] yes [23:49] okay, there is a tool called vunify ... [23:49] /usr/lib/vserver/vunify [23:50] ah [23:50] ok [23:50] this does this for you, you just specify the packages or, ALL and it will unify the vservers ... [23:56] Bertl: has anyone written an iptables module to match packets on the context they came from? [23:56] not yet, but I assume that would be easy to do ... [23:57] yup, just a small addition to the owner match [23:57] I could even add an vx_id to any skb_buff or such ... [23:57] if this does any good ;) [00:00] --- Wed Nov 19 2003