[00:11] Nick change: Bertl_oO -> Bertl [00:11] hi JusHal! [00:17] WSU (~Josh@ny.webpipe.net) joined #vserver. [00:17] hi WSU! [00:17] Helllllllo [00:20] I'm wanting to move my vservers folder to a new partition, will cp -ax move everything properly? unified vservers and all? [00:20] dump/restore would be a better choice... [00:22] ok [00:26] so something like dump -0 -f /dev/hdb1 /vservers [00:27] best way is (assuming your new dir is at /mnt/part, and the old on /vservers) [00:27] cd /mnt/part [00:28] dump 0sf 100000 - /vservers | restore rf - [00:28] -k- [00:28] -k-, and what are the benefits of doing it with dump/restore over cp? [00:28] will create a directory vservers on /mnt/part, but the contents is easily moved with mv vserver/* . [00:28] dump restore is inode based, so it will honor the hardlinks and flags ... [00:29] -k- [00:37] Is there a faster way of doing it, would something like DD work? [00:37] nope, that way is quite fast ... [00:38] it is about 10-30% slower than a raw dd [00:38] -k- [00:38] and it can benefit from a hot inode cache ... [00:38] THanks [00:39] What about files in use and what not? If I were to do this while the vservers were still running? [00:40] dump is designed to work on files in use, it is a backup utility after all ... [00:40] Right ok [00:40] it cannot guarantee consistency, but it will produce correct copies ... [00:40] Doener_zZz (~doener@p5082DABC.dip.t-dialin.net) joined #vserver. [00:40] THat is satisfiable [00:41] it is a proven good way to transport vservers from one host to another, without breaking the unification ... [00:41] Great. [00:42] ah, damn reconnects... well, i'm going to bed anyways... have a good night [00:42] good night! [00:48] Doener (~doener@pD95888F8.dip.t-dialin.net) left irc: Ping timeout: 480 seconds [00:50] Bert, I get a DUMP IS DONE but no bash prompt, do I assume restore is done also and press ctrl+c? [00:52] nope, just wait a little ... [00:52] -k- [00:52] restore should finish in a moment ... [00:55] great [00:56] -rw------- 1 root root 16539012 Jan 21 16:02 restoresymtable [00:56] any idea what this is? [00:56] seems to be created by dump/restore [00:56] yes, that is the restore symbol table ;) [00:56] umm, so do I need to do anything with is? [00:57] nope, you can delete it ... [01:17] bertl: has the new unification-tools been [01:18] urgh [01:18] well, I guess not 8-) [01:18] bertl: has the new debian unification-tools been fixed yet? [01:18] vapt and those [01:18] hmm, maybe enrico knows more? [01:19] alpha branch has completely new 'vunify' which operates on generic direcotrytrees [01:19] but it compiles with C99 compilers only ;) [01:37] JusHal (~justin@node152cb.a2000.nl) left irc: Quit: Client exiting [02:21] Nick change: surriel -> riel [02:22] hi rik, how are you? [04:51] okay, good night everyone ... cu 2morrow! [04:51] Nick change: Bertl -> Bertl_zZ [05:20] mnemoc (~amery@200.75.4.104) left #vserver (good night :)). [05:21] WSU (~Josh@ny.webpipe.net) left irc: Ping timeout: 492 seconds [05:26] syf (~shai@65.205.225.66) joined #vserver. [05:40] syf (~shai@65.205.225.66) left irc: [06:00] _shuri (~shushushu@vserver.electronicbox.net) got netsplit. [06:01] ccooke (~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com) joined #vserver. [06:08] _shuri (~shushushu@vserver.electronicbox.net) returned to #vserver. [06:14] _shuri (~shushushu@vserver.electronicbox.net) got netsplit. [06:16] _shuri (~shushushu@vserver.electronicbox.net) returned to #vserver. [07:49] vat (vat@pD9E3749C.dip0.t-ipconnect.de) left irc: Ping timeout: 480 seconds [07:49] vat (vat@pD9E375D7.dip0.t-ipconnect.de) joined #vserver. [10:21] noel- (~noel@pD9FFA1C7.dip.t-dialin.net) joined #vserver. [10:28] noel (~noel@pD9E0945A.dip.t-dialin.net) left irc: Ping timeout: 504 seconds [10:50] loger joined #vserver. [12:09] riel (~riel@riel.netop.oftc.net) left irc: Ping timeout: 480 seconds [12:22] surriel (~riel@imladris.surriel.com) joined #vserver. [12:41] miller7 (none@213.239.180.106) joined #vserver. [12:41] hello people [13:05] say_out (~say@212.86.243.154) left irc: Ping timeout: 480 seconds [14:16] anyone here using Gentoo as host or guest? [14:43] no [14:43] i use it for my router thou [14:43] what distro u use for host? [14:45] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [15:51] slackware! [17:00] serving (~serving@213.186.190.24) left irc: Read error: Connection reset by peer [17:12] Zoiah (Zoiah@matryoshka.zoiah.net) left irc: Read error: Connection reset by peer [17:25] Nick change: surriel -> riel [17:56] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Quit: Tak ja padaaaaM [17:56] miller7: debian [18:10] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [18:24] Zoiah (Zoiah@matryoshka.zoiah.net) joined #vserver. [18:29] Nick change: Bertl_zZ -> Bertl [18:30] morning everyone! [18:30] hi miller7! [18:33] huhu Bertl [18:33] *yawn* [18:33] hi vat! [18:34] we can start a hot discussion about the problems you do not have yet?! [18:34] ;) [18:39] hello Bert [18:39] Action: miller7 smiles [18:39] I shouldn't use Gentoo? [18:39] no why? [18:39] oh ok :) [18:40] Action: miller7 is currently compiling a Gentoo box [18:41] I don't have a problem with gentoo (maybe because I don't use it ;), and vserver should be distribution agnostic ... [18:47] I just upgraded my 2.4.21-ctx17 production box to 2.4.24-ow1-vs1.24... So far so good. :) [18:48] yeah, sounds good, many useful changes ... [18:56] serving (~serving@213.186.190.24) joined #vserver. [18:56] hi serving! [19:01] Bertl, got no problems at the moment.. ;) [19:01] trying ipv6root a bit :P [19:01] hmm, what is ipv6root? [19:55] Nick change: noel- -> noel [19:57] hi noel! [20:00] hello Bertl. [20:01] Bertl: I will attend http://www.tu-chemnitz.de/linux/tag/2004/vortraege/detail.html?idx=4 and check if they tell the true (lokks like a pro freebsd speech).;) [20:02] good!, make sure they are ... [20:03] :) [20:03] take your laptop with you, you can then ask me via irc, if you need some info ;) [20:04] who is coming to the Chemitzer Linux-Tag? [20:04] lol. good idea. they are recording the speeches.:) [20:04] ensc: me [20:05] I guess for enrico, it's just too far away 8-) [20:05] it happens 500 meters away from here... [20:05] ensc: ahh you are one of the orga guys. [20:06] no, in the last years I demonstrated something, but not this year [20:06] too stressfully... [20:07] maybe sitting in the first row, and yelling 'objection!' every time the freebsd guy starts praising bsd jails would be a funny thing to do, what do you think enrico? [20:07] I will try... [20:07] :) [20:08] I remember Felix von Leitner in a BIND presentation... [20:22] Hi Bertl! :) [20:23] hi serving, again! [20:24] how r you ? [20:24] fine, thanks, and how r U? [20:25] I am doing great . thanx. :) [20:25] want to test something new? [20:26] btw , I am still with 1.23 on an smp box but I did not encounter the race bug [20:26] lucky you ;) [20:26] No. not realy. Juts wana say hi :) [20:26] unless you have something new to test then yes [20:27] of course, otherwise I wouldn't ask ;) [20:27] ok [20:28] sure [20:30] here you go ... http://vserver.13thfloor.at/Experimental/delta-2.4.25-pre6-vs1.3.5-vs1.3.6pre2.diff [20:31] you'll need 2.4.24, 2.4.25-pre6 patch, vs1.3.5 patch for 2.4.25-pre6 ... [20:32] and enricos latest tools (best from cvs, right?) [20:34] i can test the first one 2.4.24 + 2.4.25-pre6 patch [20:35] and I have vserver tools .29 rpms [20:35] is that ok ? [20:35] well, you won't get the new features ... [20:35] or should I apply the above url agaist 2.4.24 ? [20:36] no 2.4.24, then 2.4.25-pre6 patch, then vs1.3.5 for 2.4.25-pre6, then the url above ... [20:36] Bertl: have you thought of releasing a pre-compiled kernel (just like Jacques used to do in eaaaaaaarly days)? [20:36] yes, I have thought about that! [20:37] and? :) [20:37] well, you won't like my test kernels, would you? [20:38] I was talking about stable versions :) [20:38] well, I upload a kernel image, you take a look, and tell me if you would like those available ... okay? [20:38] Bertl: Ok . I ll get on it ASAP. [20:39] another idea could be to release full patched kernel so that each can just compile? does this make any sense? [20:39] I think that it looks a lot technical now with vserver [20:40] (I don't have a problem with that, just expressing my thoughts) [20:40] well doing patch -p1 <../latest-patch isn't that hard? [20:40] you are right, I am just talking loud mostly [20:40] and a 'fully patched' kernel would mean to download about 25megs just for fun! [20:40] that's right too [20:40] a good point [20:41] so if I switch to providing such kernels, please shoot me! ;) [20:41] :) [20:41] my last vserver kernel is 2.4.20-17... [20:41] so it's before the change [20:42] btw, what's the status of SMP? should it be used or not? [20:42] should work with 2.4.25-pre6 and vs1.24 ... as well as with devel 1.3.3 and higher ... [20:42] 2.4.24 kernel still has some SMP races ... [20:43] ok. I will test on a single CPU for now [20:43] if gentoo decides to stop compiling :( [20:43] suhcoolbro (~Suh@216-161-89-245.ptld.qwest.net) joined #vserver. [20:43] hi suhcoolbro! [20:44] miller7: well regarding the 'precompiled' kernels, it would not be too hard to provide those, but what .config should be used for such a kernel? [20:45] well, Jacques used to have a base one. I don't know how/what cause I'm no kernel expert [20:47] well, and most of the mails he got (at least on the list) went this way: hi jacques, please could you include the 'wossname 127' driver in your precompiled kernel, we use that for years, and it would be great not to patch it ourself ...' [20:47] oh ok [20:47] bert - you know how to move the project better [20:48] so basically we end up having a kernel which includes all possible drivers ... which is fun, but not very useful ... [20:48] Action: miller7 is fine with the project as it is now [20:48] also I'm very grateful for the quota code which I find it very useful always [20:49] well, we _are_ trying to improve, so if there _is_ a demand for such kernels, we probably put some up, but I think it is _better_ for each vserver admin to configure his own and optimized kernel ... [20:51] hmm, you said 2.4.20-17 and precompiled kernel, where does the quota code come from? [20:51] hehe, no quota to that. Also it's not precompiled, I compile my vserver boxes myself :) [20:51] like someone funny said "I do my own stunts" [20:51] (Jim Carrey in "Man on the moon") [20:53] well continue thinking aloud, I always appreciate input ... [20:53] sure [20:53] what features for example, are you missing most in vserver ... [20:53] well, for me quota is important [20:54] . /proc is too but just for "looks" [20:54] also unification is important to me, although never used it :) [20:55] cause it would be much better for my CPUs and RAM to run one instance of httpd or MySQL or sshd etc [20:56] are you inclined to move to 2.6 as soon as vserver is (completely) working there? [20:57] Well, my main factor for vserver is stability [20:57] I don't care if it's 2.4 or 2.6 as long as it's stable [20:57] and does not give headaches [20:58] I see ... [20:58] what would be the benefits of 2.6 for vserver in comparison to 2.4? [20:59] hmm, well, 2.6 contains a bunch of new features, and 'repaired' stuff, useful not only for vserver ... so this is an argument for 2.6 ... [21:00] ic [21:00] it also improves scalability and resource management .-.. [21:00] sounds cool then [21:00] yeah, for sure it's cool, but I'm not yet convinced about stability ... [21:00] agreed [21:01] in my opinion stability should be #1 factor for any project [21:01] and then more features [21:02] well, I guess stability _is_ #1 factor for any project, but you should not let it influence every decision ... [21:03] the argumentation is very simple: assume that stability is #1 and most important factor ... [21:03] then you won't add any features, because any change in the existing code, could influence the stability ... [21:04] no, but it should be stable enough [21:04] and sometimes, as we've seen with 1.23 even changes to 'improve' the stability by fixing known bugs, can degrade it ;) [21:05] (of course, by introducing new bugs ;) [21:06] actually I'm trying to improve the vserver stable devel branch in this regard ... [21:07] I'm planning to make stable prereleases, which ahve to be tested at least for one month, and which won't be released until I got some feedback ... [21:07] (released as stable version) [21:28] Bertl: just got report about AMD64 build failure: http://geek.j2solutions.net/stuff/vserverror [21:28] yeah, saw that before, seems to be some changes in 2.4.24 ... [21:29] obviously nobody checked it on X86_64 :( [21:29] do you know somebody who knows how to build working cross compilers? [21:30] I created a cross compiler for arm. But gcc-3.x only ;) [21:30] no problem with 3.x in that respect, I don't want to run the resulting kernel anyway ;) [21:31] but we would need cross compilers for all architectures ... [21:31] Bertl: you will need to build glibc too [21:31] and my last attempt to build one for alpha failed ... [21:31] I'm not sure we need glibc, because kernel doesn't use glibc ;) [21:34] Bertl: ../configure --build=${target_platform} --host=${target_platform} \ [21:34] --target=%{crossarch} \ [21:34] --prefix=%{_prefix} \ [21:34] --mandir=%{_mandir} \ [21:34] --disable-checking %{?configopt} \ [21:34] %{xtraopt} [21:35] %{?_with_bootstrap:%define xtraopt --enable-languages=c --disable-threads --disable-shared --disa [21:35] ble-nls} [21:36] (you mean for gcc?, I'll try, but last time it failed, because of the bootstrapping, and how it is done, will need compiled binutils though ;) [21:37] binutils can coexists; you have to use '--enable-targets=amd64-unknown-linux' (or similarly) [21:44] okay, 3.3.2 gcc? binutils 2.13.90.0.4, should work? [21:46] yes, you should recompile you distributions binutils with this --enable-targets argument [21:47] but I do not know, which would be the right one for amd64 [21:48] http://gcc.gnu.org/install/specific.html [21:48] x86_64-*-*, amd64-*-* [21:48] GCC supports the x86-64 architecture implemented by the AMD64 processor (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD. On GNU/Linux the default is a bi-arch compiler which is able to generate both 64-bit x86-64 and 32-bit x86 code (via the -m32 switch). [21:52] okay, who of you is running solaris? you can admit it: (see http://www.windowsmedia.com/download/download.asp first line) [21:53] is there a bot in this channel? [21:54] or... has anyone seen infowolfe lately? He's a gentoo guy I think [21:55] haven't seen him for a while ... [21:55] too bad [21:55] he was saying something about automating gentoo->vservers [22:03] does vserver-linux have problems with reiserfs? [22:04] hmm, recent versions should not ... some stuff isn't supported yet ... [22:06] Bertl: what's a nice vproc template to begin with? [22:06] Bertl: or is the new procfs stuff secure by default? [22:06] well, on 1.3.5 it's secure by default (everything disabled ;) [22:07] Bertl: I just upgraded to 1.2.4. :) [22:07] And I'm not really keen on running development stuff on production servers. [22:07] yeah, there the default is everything enabled ... [22:07] Ahh, but the future stable versions will have everything disabled by default also? [22:07] maybe .. not sure if I want to do that to myself ... [22:08] I prefer a secure by default setting. [22:08] BTW, the www.linux-vserver.net webserver is broken? [22:08] yup, but for sure, I'll get a dozen mails: 'bla bla vserver not working with 1.25 ...' [22:09] Well, yeah, but security comes at a cost. [22:09] But: [22:09] zoiah@matryoshka:/proc$ telnet www.linux-vserver.net 80 [22:09] Trying 207.253.4.250... [22:09] Connected to www.linux-vserver.net. [22:09] Escape character is '^]'. [22:09] GET / HTTP/1.0 [22:09] Blah. :) [22:09] Nothing happens. [22:09] hmm interesting ... will check that ... [22:09] Error executing database query. [22:09] Please contact the administrator for assistance. [22:09] LOCK TABLES lvs_org_rate WRITE [22:09] that's what I get ... [22:10] Borked MySQL server? [22:11] well, I don't know what jack does there ... lets take a look ... [22:11] The servers are ran by jack? [22:11] yup, he volunteered to host the wiki ... [22:12] Ahh... [22:12] He seems like a pretty cool and inventive person. I never knew he was the person who came up with the sick stuff called UMSDOS. :) [22:13] BTW, the insecurity of procfs is only when people can become root inside a vserver? Because I don't think there are any user-writable settings in proc. [22:14] AFAIK, that is correct ... [22:14] what insecurity of procfs? [22:14] if someone adds more than the absolutely necessary? is that what we're talking about? [22:15] or there is some other issue I don't know? [22:15] okay, a restart of apache/mysql fixed that issue ... Zoiah, please could you verify that? [22:17] Bertl: yes, it's fine now, thanks. [22:17] miller7: that is what I mean. [22:17] Zoiah: ok, thanks :) [22:18] Berlt: can I safely remotely run vproc on a server without chance of locking myself out? [22:19] if you do not disable proc entries on the host, then nothing bad should happen ... [22:19] Bertl: I'll only use "-d". [22:19] although I'm confident, that sshd doesn't access proc at all ... [22:20] timmy:/# /usr/src/vproc-0.01/vproc -d /proc/bustimmy:/# [22:20] zoiah@matryoshka:/proc$ cd /proc/bus [22:20] -bash: cd: /proc/bus: No such file or directory [22:20] It works! :) [22:22] But there isn't a default list of proc-entries I should disable yet? [22:27] Ahh, and I can't disable /proc/mounts (or /proc/self/mounts)? [22:29] miller7 (none@213.239.180.106) left irc: Read error: No route to host [22:29] Zoiah: you can't modify dynamic entries /proc//* [22:30] besides, there would be no pint in doing so, starting a new process would create 'new' unmodified entries ... [22:30] Bertl: I know, but I just wanted to try since /proc/mounts isn't virtualized yet. [22:30] s/pint/point/ [22:30] well, there is a no_proc_mounts patch ... [22:31] That would be solution. It's not really a great problem for me, but it gives the evil h4x0r a bit more information then I would like. [22:31] http://vserver.13thfloor.at/Experimental/no-proc-mounts-vs1.24.diff [22:32] Hmm... experimental. :) [22:32] But it looks simple enough. :) [22:34] well it's trivial, but untested ;) [22:35] miller7 (none@213.239.180.106) joined #vserver. [22:36] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Remote host closed the connection [22:36] http://www.zoiah.net/vserver.proc [22:37] That seems to do the trick for me. :) [22:37] no scsi on that host? [22:37] Nope. [22:38] And I'm not sure if I should remove execdomains and slabinfo also. [22:38] how does your vserver /proc now look like? [22:38] cmdline devices filesystems meminfo self stat version [22:38] cpuinfo execdomains loadavg mounts slabinfo uptime [22:38] And ofcourse the PIDs. [22:38] cmdline is required for? [22:39] Nothing, but I couldn't see any harm... but yeah, I should remove it. :) [22:40] does anything in your vservers require devices, filesystems or version? [22:40] (just curious) [22:41] maybe we can really establish a 'secure' default for the next stable ... [22:41] Not that I'm aware of, but /proc/version is something I wouldn't like to remove, this is information users should be able to get, imho. [22:41] But devices and filesystems could be left outt. [22:41] Actually, I'm sure a machine can function without a /proc just nicely. [22:42] note that uname -a should work without /proc/version ;) [22:43] It does? [22:43] Ahh, richtig. :) [22:43] Ohh, well, then I could remove those also. :) [22:43] it would be nice to fake the kernel name too (for security reasons [22:43] this is in the latest development ;) [22:43] the faking? [22:43] yup [22:43] how can someone do it? [22:44] well, there is utsname ... which is a struct containing some 'host' information ... [22:45] ic [22:45] is there a tool that runs on the host to dynamically change value of this struct? :P [22:47] well, I guess enrico is writing it now, or already finished, don't know ... [22:48] Bertl: is the kernel supporting it already? [22:48] well, yes ... [22:49] ok, but I will prepare release of 0.28 (old, stable branch) first [22:49] no problem ;) [22:50] will 0.28 require a 'new' 'unstable' compiler ;) [22:53] Bertl: I'm going to add "* [http://www.openwall.com/linux/ openwall patches] Kernel hardening patches that apply cleanly with vserver, no source patching required." to the list of interesting patches on the vserver page, is that fine? [22:54] perfectly fine .. go ahead ... [22:54] Bertl: no. (no branch of util-vserver requires an unstable compiler ;)) [22:55] I'm using this myself in production since a few hours and in development since a few months. :) [22:55] maybe you could also write a short page about the benefits, and/or configuration ... [22:55] (for vserver of course) [22:56] Sure thing, where in the wiki should I add it? [22:57] http://www.linux-vserver.org/index.php?page=Documentation [22:58] I would say either howtos or papers ... [22:58] and make a reference beside the link to the patches (to your howto/paper) [22:58] It'll just be a small mini-howot. :) [22:58] howto* [22:59] did you already add yourself (your company) to the Vserver Hosting/Users section? [23:05] ensc: is --enable-targets, preferred over --target= ? [23:06] or should it be preferred? [23:06] former adds new targets, latter sets the default one [23:06] okay, so when I only want to build binutils for alpha, then --target is the better choice, right? [23:07] no, you can reuse binutils (except as) for all architectures [23:07] $ ld --help [23:07] ld: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32 elf32-little elf32-big elf32-littlearm elf32-bigarm elf64-x86-64 elf64-little elf64-big srec symbolsrec tekhex binary ihex trad-core [23:07] ld: supported emulations: elf_i386 i386linux armelf_linux armelf elf_x86_64 [23:07] hmm, okay, so I should compile binutils for 'all' targets at once? [23:08] so you should use '--enable-targets=x86_64-unknown-linux' [23:08] 'all' is supported accordingly doc, but it fails sometimes [23:08] well, what about alpha, parisc and sparc then? [23:08] you can give a comma separated list of archs [23:09] I thought I compile a binutil package for each of them ... [23:09] but if this can be done in one step, I'd prefer that ... [23:09] true for the assembler, but ld, strings, ... can be reused [23:09] and will assemblers be built for all targets? [23:09] no, assembler must be built manually [23:10] hmm, okay, then one package for each arch might after all be the better choice, right? [23:10] binutils can create shared libraries; separate packages can cause fileconflicts on them [23:11] well, they should all have their separate dirs, right? [23:12] http://www-user.tu-chemnitz.de/~ensc/cross-as.spec [23:12] is my cross-assembler specfile [23:13] {_bindir}/%{crossarch} [23:13] %{crossarch}/lib [23:13] that was what I meant ... [23:51] Action: vat really hates qmail now [23:51] (by some) that is (considered) a step in the right direction ... ;) [23:52] Nick change: Doener_zZz -> Doener [23:52] hi [23:52] hi! [23:58] had to install qmail for a customer, 4hrs until it works. damn chmod's :). [00:00] --- Fri Jan 23 2004