[00:07] mhepp (~mhepp@213.211.38.19) left irc: Remote host closed the connection [00:35] serving (~serving@213.186.191.12) joined #vserver. [01:16] hi [01:16] hi! [01:16] i've just encountered a little problem here [01:16] running 2.4.22 with ctx17a [01:16] when i enter a vserver, i get this [01:16] [root@matrix root]# vserver auth04 enter [01:16] /usr/sbin/vserver: line 628: ulimit: max user processes: cannot modify limit: Invalid argument [01:17] sounds normal (expected ;) [01:17] really? ;) [01:17] as i don't have it on another machine ;) [01:17] yep, marcello & co decided to change the ulimit interface between 2.4.21 and 2.4.22 in some pre stage ... [01:18] aah, ok, my other machine is running 2.4.21 [01:18] it is now considered an error to set the hard limit below the soft limit ... [01:18] you have two choices to workaround ... [01:18] a) apply my ulimit-unfix patch [01:19] b) use -HS insted of -H in the config to set both hard and soft limit ... [01:19] well yes, it is a bug to set the hard limit below the soft limit ;) [01:19] so the better solution would be b) then ... ? [01:20] I dont agree, because they are not connected (this way around) [01:20] I didn't agree either, at first [01:20] but people convinced me [01:20] well i'm not too experienced with ulimits ... ;) [01:21] @ck yes probably the best ... [01:21] by quoting the SuS at me [01:21] it seems logical to me that the soft limit cannot be above the hard limit, but and that is the point, I do not agree that the user has to ensure this on lowering the hard limit ;) [01:22] agreed, the shell should do that for you [01:22] hm, yeah, sounds logical ;) [01:22] or maybe even libc [01:22] IMHO the kernel (or the tools) have to do this for me ... [01:22] agreed, the tools should do that [01:22] not the kernel though [01:22] changed to -HS now though, the box I had the prob on is in production use, don't want to reboot it now ;p [01:23] setting the ulimit involves setting the hard and the soft limit simultaneously [01:23] but if you talk to the tool-makers, well, you know what they say ... [01:23] you pass both values to the kernel at the same time [01:23] thx for your help;) [01:29] @rik hopefully the bash/ksh/csh maintainers will change the builtins soon ... [01:30] that'd be cool [01:31] when do you plan to start with some vserver stuff on 2.6 ... [01:31] I'm still studying the selinux code [01:31] selinux can do the separation between vservers ... but in a flexible way [01:32] because some community members where asking if anything for 2.6 is available ... [01:32] so you could configure your system so some vservers could control others, while others would be complete jails [01:37] hmm, so you don't know, or you don't want to start? [01:41] what is a good naming method for vservers or servers in general ? :) what do you guys do ? [01:43] serving: it's intented purpose [01:43] serving: i've always used that for all my servers [01:45] hmm, I limit myself to 4 characters, so I can see the full name in every situation ;) [01:46] usually starting with 2-3 chars and the rest numbers ... [01:46] s/chars/alphas/ [01:51] JonB (~jon@129.142.112.33) left irc: Quit: Client exiting [01:51] Nick change: riel_ -> unriel [01:56] hmm. multiple mail servers will have smtp001 [01:56] would be an option ... [01:56] named will be dns001 dns002 [01:57] bond007 [01:57] if DNS1 DNS2 ... DNS9 is sufficient, I would go for that ... [01:57] this is better thean srv001 srv002 that I've been doing [01:58] shuri: shaken not stirred :)) [01:58] bond007 server wil have license to hack ? [01:58] B007 ;) [02:00] matta (matta@tektonic.net) left irc: Quit: [hienoa] - your ass is glowing! [02:07] hehe [02:08] Simon (~sgarner@210.54.177.190) joined #vserver. [02:08] hi Simon! [02:08] hi Bertl! [02:10] what's the 'right' way to 'build' a vserver with the latest tools? [02:11] what is the last version, and who do you ask? [02:11] s/last/latest/ [02:11] util-vserver-0.23.6 [02:11] anybody who knows the answer ;) [02:11] vserver test build doesn't make a working chroot tree [02:12] best to ask enrico ... maybe he is around ... [02:12] Action: Simon gives ensc a friendly prod [02:13] Simon: when you are brave, you can try the alpha version [02:13] brave == stupid ;) [02:13] Action: Simon sucks chest in [02:13] right you are! let's have at it [02:14] well, I have to confirm that enricos alpha versions are a _lot_ better than most final releases ... [02:14] all of vserver is alpha right now anyway eh? ;) [02:15] if you see it this way, perfect ... we can only improve ;) [02:15] the basic stuff works in alpha, but some management tools (e.g. vunify) are not ported yet [02:15] by the way, enrico, why do I need a c++ compiler for your tools? [02:15] can I use the old vunify? [02:16] Bertl: for vunify e.g. [02:16] hmm, okay is there an option to do without? [02:16] Simon: the old vunify relies on /vserver/* structure and the rpmdb with this directory. With my new tools, the vserver-dir is configurable and the rpmdb is outside of the vserver [02:17] Bertl: not yet [02:17] @enrico, okay, thanks ... [02:17] Simon: http://www-user.tu-chemnitz.de/~ensc/vserver/util-vserver-0.23.192.tar.bz2 [02:18] you will need 'apt-get' for the new 'vserver ... build' [02:18] hmm, another question, this is some kind of cvs numbering, right? [02:18] no; I have 0.23.6 which is the old version, 0.23.89 which is the syscall-switch and 0.23.192 which is the devel [02:19] how do I calculate the latest stable/devel version if I look at your numbers? [02:19] I do not have decided this yet... [02:20] okay so 0.23.92 is older than 0.23.192 then? [02:20] Bertl: no; 0.23.92 is more stable, but 0.23.192 has all feature of 0.23.92 and more [02:21] lower number == greater stability? [02:21] greater number == more features? [02:22] sometime, I will go to 'x.y' for stable releases and 'x.y.z' for development versions. When z is near 100, this marks a release candidates [02:22] hmm, is there a problem with the way the kernel does the numbering? [02:22] but currently, there are some things too uncertain to follow this numbering scheme [02:23] I do not have the feeling that I can a assign a version >= 1 to it in the current state [02:23] because I would like to have a similar (if not identical) numbering scheme for tools and patches ... [02:24] you could use 0.0.x for stable and 0.1.x for unstable ... [02:24] er, I mean development, of course ,) [02:24] would work with 0.24.x and 0.25.y too ... [02:24] I think the kernel numbering is a good one ;) [02:25] well I know better, but everybody patching the kernel has to know this scheme ;) [02:25] ensc, does that version fix the problem I had with .92? [02:25] I do not want x.y.z triples for stable versions; this seems to violate the automake gnits standard somehow [02:25] Simon: which problem? [02:26] chbind/chcontext not working with c17f [02:26] under x86_64 anyway [02:26] @enrico guess this was the syscall return, so probably yes ... [02:26] Simon: yes [02:27] @simon what kernel version do you use now? [02:28] 2.4.22-c17f [02:28] any problems with the g/g2 version? [02:31] I just wanted to wait for 2.4.23 to be not-test [02:32] or pre rather [02:32] okay but g/g2 on 2.4.22 would be okay? [02:32] does it patch? [02:33] this was a rhetorical question ... [02:33] er ok... ;) [02:37] so you dont have a problem with the g/g2 stuff, only with the -pre7 stuff then, right? [02:39] the 2.4.23-c17g worked fine [02:42] could you, next time you compile a version (probably c17h) make the compile warnings public somehow? [02:44] okay [02:47] what's new in c17g anyway? :) [02:48] the syscall switch ... [02:48] ahh [02:48] Val (~val@val.linuxfr.org) joined #vserver. [02:48] hi val! [02:48] hi [02:48] Bertl : take a look at http://linuxfr.org/journal/ [02:49] Bertl : first news (mine) [02:49] Bertl : i published ctx17f which works fine [02:49] Bertl : but i tested ctxg2, which fails :-/ [02:50] hmm, maybe there is some posting ... but .. [02:50] where did you say is the english/german version? [02:50] when booting, vservers starting fails with a no vaid ipv4root address [02:51] but virtual ifaces are up [02:51] Debian packages are there : http://debian.linuxfr.org/ [02:51] hmm strange ... which tools? [02:51] vserver 0.23 [02:52] s/vaid/valid/g [02:52] ahh, wont work with g2 .. you need recent util-vserver [02:52] ouch ? [02:52] but I said that yesterday ... [02:52] yes you did [02:53] but no new util's debian package is available [02:53] so go ahead, make one ;) [02:53] ooohhh :) [02:53] talk with enrico, he will know what is required ... [02:53] first i do a search on debian packages engine :) [02:54] http://packages.debian.org/cgi-bin/search_packages.pl?keywords=vserver&searchon=names&subword=1&version=all&release=all [02:54] ...no new version available :-/ [02:54] The debian people seem to have lots of vserver patches but I have not looked in detail into them. Some of them (e.g. changing of /vservers toplevel dir) will be probably obsoleted by the new version [02:55] yes, it's now /var/lib/vservers [02:55] util-vserver >= 0.23.100 does not has this constraint [02:56] Ola Lundqvist is the maintainer of CTX patch and vserver utils package :-( [02:57] I am completely unfamilarly with debian and its people [02:57] i'll mail him Bertl's patch for 2.4.22 [02:58] ...hoping he'll consider it as an "upstream" one [02:58] wait a little ... there will be a c17h soon ... [02:58] and do new vserver package :) [02:59] just do some testing ... on the g2, so we can make sure the debian version works ... [02:59] Bertl : it is not too hard to do ctx patch for debian using your diff, i think it's time for him to do the work [03:00] no problem with that, but it's better when he starts from a working version, right? [03:00] and then get util-vserver >= 0.23.100 :) [03:00] Bertl : right [03:00] Bertl : for me only ctx17f works [03:00] Bertl : ctx17g2 fails [03:00] when does it fail? [03:01] when booting vservers [03:01] ipv4root... [03:01] well do you use the new tools? [03:01] wrong version of utils-vserver :) [03:01] are we going in circles? [03:01] yes we do :) [03:01] so get those da^H^Hfantastic tools and test it, then ;) [03:02] haha :) [03:02] 0.23.80 <= utils-vserver < 0.23.100 should be stable and are working with syscall-switch [03:02] ok [03:02] ...but debian package making will be stronger than kernel-patch [03:03] yes, vserver -> util-vserver transition is not trivial for packaging... [03:03] nearly all files have been moved/renamed [03:03] hmm, well you throw everything out, and take all in ;) [03:03] i'll get vserver debian package source and do the diff manualy [03:04] ensc : ouch, files have been moved/renamed ? [03:04] grmbl [03:04] Val: yes, most files are now C-files [03:04] Val: and it is automake/autoconf based [03:04] so... i know now why nothing moved on debian packages :) [03:05] hmm, rpm , thanks to enrico, was a matter of rpm -ta ... [03:05] Bertl: yes, I am using rpm by myself and I do not install packages manually [03:06] but rpm does use the stdio lib 8-) [03:07] Bertl: I am in contact with jbj (the rpm-author)... ;) [03:07] ahh, thought so ... *G* [03:08] Bertl: btw: the legacy parser in the libvserver is now stdio-free [03:08] hmm, not bad ... [03:09] so, i go to bed, have a nice night ;-) [03:09] you too ... [03:09] thx, bye [03:09] Val (~val@val.linuxfr.org) left irc: Quit: zZz [03:23] matta (root@debian.unixshell.com) joined #vserver. [03:23] hrm [03:23] hi matt! [03:23] i don't think O1 is SMP safe... [03:23] di I tell you? [03:23] i booted a server up with it [03:23] it was up fo like 20 minutes [03:23] and then it just hung [03:23] so i'm not sure whats up [03:24] with or without your mem stuff? [03:24] with [03:24] the fixed version? [03:24] i figured if O1 wasn't SMP safe it would last 30 seconds [03:24] uhm... i'll have to check when it comes back up [03:25] depends, if there is a race .. how did you fix the compile issues? [03:25] oh [03:25] well, it looked like duplicated code [03:25] the function is in there twice [03:25] it's different code, with different conditions [03:25] one is #ifdef CONFIG_SMP [03:26] the other is #if CONFIG_SMP [03:26] one part in sched.c and another in ksym.c [03:26] i commented out one and it failed to compile, i commented out the other and it did [03:26] prolly not the best idea :) [03:26] ;) [03:26] i tested that it loaded on a SMP server, but no extensive testing [03:27] what did you see from that? [03:27] and who has a SMP server? I bet sam does :) [03:28] probably ... but it's not his stuff, and he didn't test it ... [03:31] I heard that genetic algorithms are a good way to adjust some things, but until yet they failed miserably for coding purposes ;) [04:02] okay, if anybody want's to test, c17h is there ... [04:03] whats diff? [04:04] cleanups and restructuring ... nothing which would affect functionality ... [04:04] if everything works out as expected this will be the vserver 1.0.0 release ... [04:05] still need some feedback from other platforms ... [04:09] okay, I call it a day ... [04:09] cu probably tomorrow ... [04:11] Nick change: Bertl -> Bertl_zZ [05:55] ensc, you there? [06:17] a-c-e (~ace@213.225.74.103) left irc: Ping timeout: 492 seconds [06:31] :( [06:31] gcc -Wall -pedantic -g -O2 -std=c99 -Wall -pedantic -W -o src/rpm-fake.so -fpic -ldl -shared src/rpm-fake.o lib/libvserver.a [06:31] src/rpm-fake.o: could not read symbols: Bad value [06:31] collect2: ld returned 1 exit status [06:32] /usr/bin/ld: src/rpm-fake.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC [06:36] alekibango (~john@b59.brno.mistral.cz) left irc: Remote host closed the connection [06:47] Nick change: riel -> surriel [08:13] a-c-e (~ace@213.225.74.103) joined #vserver. [08:43] say (~say@212.86.243.154) joined #vserver. [08:43] say_ (~say@212.86.243.154) left irc: Read error: Connection reset by peer [10:30] gaertner (~gaertner@212.68.83.129) joined #vserver. [10:58] moin [12:48] Nick change: Bertl_zZ -> Bertl [12:48] morn 2! [13:20] say (~say@212.86.243.154) left irc: Ping timeout: 513 seconds [13:41] hi Bertl! [13:47] Action: Simon prods Bertl [13:47] I know you're there ;) [13:47] hi! [13:47] can't hide, can I? [13:47] nope ;P [13:48] got a couple of issues... first up when I enter a vserver, hostname and uname still show the host server's hostname? [13:48] hmm, strange, which version is this? [13:49] c17f with util 192 [13:49] er, util 90.6 rather [13:49] 192 wouldnt compile.. :( [13:50] Simon: have you tried to recompile with '-fPIC' instead of '-fpic'? [13:50] no :) [13:50] where do I add that? [13:51] gcc -Wall -pedantic -g -O2 -std=c99 -Wall -pedantic -W -o src/rpm-fake.so -fPIC -ldl -shared src/rpm-fake.o lib/libvserver.a [13:51] should be executed from top-level directory [13:51] and then 'make' again [13:51] ok, i'll try it [13:52] @simon if you find some time, give c17h a try, yes? [13:53] it still doesn't like that... [13:53] /usr/bin/ld: src/rpm-fake.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC [13:53] src/rpm-fake.o: could not read symbols: Bad value [13:53] collect2: ld returned 1 exit status [13:54] hmm, different C and LD options maybe? [13:58] -fPIC is a linker option only [14:01] hmm, .so != .o then? [14:02] -fPIC does not work with _syscallX() declarations: error: can't find a register in class `BREG' while reloading `asm' [14:06] hmm, shouldn't a 32bit version be equivalent to x86 ? [14:07] then, what do I know of 64bit architectures ;) [14:09] Simon: can you do: rm src/*rpm-fake*.o [14:10] and make AM_CFLAGS='-fPIC' [14:10] ? [14:13] gcc -fPIC -g -O2 -std=c99 -Wall -pedantic -W -o src/rpm-fake.so -fpic -ldl -shared src/rpm-fake.o lib/libvserver.a [14:13] /usr/bin/ld: lib/libvserver.a(lib_libvserver_a-syscall.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC [14:13] lib/libvserver.a: could not read symbols: Bad value [14:13] collect2: ld returned 1 exit status [14:13] make[2]: *** [src/rpm-fake.so] Error 1 [14:13] mdaur (~mdaur@141.59.19.50) joined #vserver. [14:14] hmm. it's in the library then? [14:14] hmm, compiling the library with '-fPIC' is not possible [14:14] at least on ia32 [14:15] hallo, where is the url to ctx-17h? [14:16] http://vserver.13thfloor.at/Stuff/c17h/ [14:16] Bertl: thanks i forgot it [14:16] Simon: try 'rm lib/*.{o,a}' and execute make AM_CFLAGS='-fPIC' again [14:16] brb .. 20min or so ... [14:16] Nick change: Bertl -> Bertl_oO [14:18] that worked :) [14:19] but... these tools still don't work with c17f eh? [14:19] # vserver test enter [14:19] WARNING: can not find configuration, assuming legacy method [14:19] Can't set the new security context [14:19] : Invalid argument [14:19] Can't set the ipv4 root (Invalid argument) [14:23] Simon: oh yeah, I am stupid. Replace 'EAGAIN' with 'EINVAL' in lib/checkversion.c [14:27] nope, no difference :( [14:27] don't worry, I'll try c17h tomorrow [14:29] Simon: The legacy method uses the tools within $PATH; do you have an older version installed? [14:30] it is using the right /usr/sbin/vserver [14:31] chcontext is interesting [14:36] btw, how likely is this apt-get stuff to work on mandrake? [14:39] it should work [14:39] are there existing public repositories for Mandrake? [14:39] creating an own one is not a problem [14:40] repositories as in? [14:40] e.g. ftp://ftpl.tu-chemnitz.de/pub/linux/fedora/redhat/9/i386/base/ is a RH9 repository [14:43] the release.* files are there important: use a partition which can hold all the needed packages (>2GB) and create RPMS.os, SRPMS.os and base directory there. Into the base directory, copy a sample release.* file, rename it to release.os and change some values. Then, copy your packages into RPMS.os and call 'genbasedir --partial --progress --bz2only --bloat --flat `pwd`' there [14:45] Then, create /etc/vservers/.distributions/mdr9/apt/ and create a 'sources.list' file with content like 'rpm file: os' [14:47] Now, copy /usr/lib/util-vserver/distribution/rh9 to mdr9, and create your vserver with 'vserver foo build -m apt-rpm -- -d mdr9' [14:50] goodness [14:50] ok :) [14:50] Nick change: Bertl_oO -> Bertl [14:53] so we have to find a mdk92 release file... [14:53] hmm. what do you need? [14:55] Simon: look into the release files; they are just random text ;) [14:55] Simon: make first line 'Archive: os' and copy the rest from somewhere else [14:55] ok.. [14:56] ftp://gd.tuwien.ac.at/pub/linux/Mandrake/9.2/i586/Mandrake/{base,RPMS} [15:21] say (~say@212.86.243.154) joined #vserver. [17:14] say (~say@212.86.243.154) left irc: Ping timeout: 483 seconds [17:15] say (~say@212.86.243.154) joined #vserver. [17:15] Nick change: unriel -> riel [18:01] space_phoenix (~morrigan@212.16.62.51) joined #vserver. [18:02] space_phoenix (~morrigan@212.16.62.51) left irc: Client Quit [18:02] serving (~serving@213.186.191.12) left irc: Ping timeout: 483 seconds [18:03] space_phoenix (~morrigan@MAIL.13thfloor.at) joined #vserver. [18:13] space_phoenix (~morrigan@MAIL.13thfloor.at) left irc: Quit: leaving [18:14] hi say! [18:15] hi [18:15] hi shuri! [18:15] sup Bertl [18:16] what's up? [18:16] uptime [18:16] 10:12:08 up 10 days, 20:27, [18:16] with ctx17f [18:16] well, then test c17h, we want to release this month ;) [18:16] on a production server [18:18] what new in ctxg? [18:18] what new in ctxh [18:19] the syscall switch ... [18:21] ok i will compil it today [18:26] great! [18:31] mdaur (~mdaur@141.59.19.50) left irc: Quit: Client exiting [18:31] are you satisfied with the c17f functionality? [18:38] well [18:38] since ctx17 [18:38] i do not see any new functionality [18:38] in a way, this is my question ... [18:39] hehe [18:39] would you like more features or more stability in future releases ... [18:39] bertl [18:39] hi matt! [18:39] the only stability problem i got with vserver was with ctx14-15 [18:39] so I put the O1 patch on my non-smp server (the one that uses 800MB of swap and loads jump to 100+ frequently) [18:39] remember that customer I had who was sending all the e-mail? [18:39] set them to nice of 19 so they are batch scheduled [18:40] average load since then is 1 and very snappy [18:40] @shuri well look at matt, he is running the O(1) scheduler (very experimental ;) [18:40] time to fix SMP!! :) [18:40] good to hear ... [18:41] I assumed you fixed it yourself by now? ;) [18:41] lol [18:41] my SMP server here fried [18:41] well, as junior vserver developer ... [18:42] ha ha [18:43] i'm gonna see if I can get y old SMP box running, i think the mtoherboard is gone [18:52] @shuri would you use an experimental release, or just wait for the features getting into the stable one? [18:55] stable [19:04] so you prefer stable over features, right? [19:11] @matt do you have a system to test SMP issues on? [19:12] dst (~dst@212.227.35.75) left irc: Quit: leaving [19:49] loger joined #vserver. [19:52] @matt are you able to test a SMP version of the O(1) scheduler? [19:54] http://vserver.13thfloor.at/Experimental/patch-2.4.23-pre7-O1.1.diff.bz2 [19:54] serving (~serving@213.186.189.201) joined #vserver. [19:55] @matt just the scheduler ... nothing more, but if this hangs/does funny stuff, we still have to work on it ... [20:32] Nesh (~dmistry@64.106.131.10) joined #vserver. [20:32] hi lo [20:33] hmm, average ~ 0 then ... ;) [20:33] Bertl so I am compiling c17f [20:34] this does not have the quota stuff or anything like that right? [20:34] nope, not without patches ... [20:34] its just a fixed up version of ctx-17.. [20:34] ok cool [20:34] well that stuff is still experimental [20:34] :) [20:34] c17h has the 'stable' syscall switch too ... [20:34] is there a link on the page that is a changelog? [20:35] i did not see one [20:35] not yet ... but now that you mention it ... [20:35] ;) [20:35] believe it or not, for me it's obvious *G* ... [20:35] not for me tho! [20:36] I'm on it, I'm on it ... [20:36] hehe cool :) [20:46] vserver-admin-0.23-1 [20:46] vserver-0.23-1 [20:46] that ok with ctx-17h [20:46] nope ... you need util-vserver ... [20:46] a working package is in the same dir ... [20:46] or you can grab it from savannah ... [20:48] vserver-0.24.src.tar.gz ? [20:48] http://vserver.13thfloor.at/Stuff/c17h/util-vserver-0.23.92.tar.bz2 [20:48] cool! [20:49] this will replace my rpm or do i need tp rpm -e it .. [20:49] rpm -ta should do the trick ... [20:50] or rpmbuild on RH ... [20:50] Wrote: /usr/src/redhat/SRPMS/util-vserver-0.23.92-0.src.rpm [20:50] Wrote: /usr/src/redhat/RPMS/i386/util-vserver-0.23.92-0.i386.rpm [20:50] heh nice. [20:51] [root@host03:/home/dmistry]$ rpm -Uvh /usr/src/redhat/RPMS/i386/util-vserver-0.23.92-0.i386.rpm [20:51] error: failed dependencies: [20:51] vserver < 0:0.23.92 conflicts with util-vserver-0.23.92-0 [20:51]