[00:00] s/reason/explanation/ [00:00] I can just change the chattr flags if you like ;) [00:01] well, we probably need 2-3 tools ... [00:02] a) something to list/set the IUNLINK (that's what its called now) [00:02] b) soemthing to list/set xid (context assignment) [00:02] c) something to sum up (like du) but with respect to the xid [00:03] a and b could be one tool huh? [00:03] I'm not sure if we should 'just' adapt the fileutils ... [00:03] or write some 'specialzied' tools which can do more ... [00:03] depends if you can get the patches integrated, otherwise it'll be more hassle maintaining the patches [00:04] well, I'd say, 'NO CHANCE' for an integration ;) [00:04] exactly ;) [00:05] but on the other hand, it would not require to reinvent du/lsattr/chattr and do the bugtracking for this stuff twice ... [00:06] enrico? are you here? [00:07] yep [00:07] do you plan to add such tools to the util-vserver package? [00:07] I am about to write lsxid/chxid with a -R flag [00:08] ah okay, that could probably be used for the IUNLINK flag to, right? [00:08] s/to/too/ [00:08] it can be probably reused for setattr/showattr [00:09] could this become a multicall binary? [00:09] yes [00:09] great! [00:09] how much trouble would it cause you to add a xid based 'du -k' to that? [00:10] should be not very much, I guess [00:10] so basically while doing the lsxid -R summing up the file sizes and number of files ... [00:10] that would be perfect for the cqdlim setup ... [00:10] well, it actually could be part of that ... [00:11] I dont want to add to your task/todo list, but it would be a great help, I guess ... [00:15] Simon: you have to explain your vskel stuff to me, when you've got some time ... [00:15] it looks like it's accepted by the community, so it must be useful ;) [00:17] :) [00:26] nathan_ (~nathan@209-6-130-26.c3-0.sbo-ubr1.sbo-ubr.ma.cable.rcn.com) left irc: Ping timeout: 492 seconds [00:52] Simon, when you get back, I have another question for you. [01:50] Nick change: Doener -> doener_zz [01:55] JonB (~jon@129.142.112.33.ip.tele2adsl.dk) left irc: Quit: Client exiting [02:04] do I need to keep /lib/modules in a vserver? [02:04] WSU: nope [02:04] didn't think so [02:04] thanks [02:05] what are some of the common things I should take out? [02:05] kernel sources, development stuff (if not required) [02:06] tools for filesystems, and hardware detection, etc... [02:06] check [02:07] morning [02:07] morning! [02:08] hey herbert :) [02:08] vserver rules! :) [02:08] yeah, that's the spirit! [02:10] What is the correct configuration for sendmail in a vserver so that is not listen to external address? I use 'DAEMON_OPTIONS(`Address=127.0.0.1,Name=MTA')dnl [02:11] which works on real hosts, but with vservers I can telnet to port 25 still [02:14] well, you probably need to add 127.0.0.1 to your list of allowed ips ... [02:19] yes, this works but I used 127.0.0.2 [02:20] or is 'lo' interface local to vserver also? [02:20] nope, not yet ... [02:26] but jack is working on it, I guess ;) [03:23] kestrelw (~athomas@o2rosock0a.optus.net.au) joined #vserver. [03:57] kestrelw (~athomas@o2rosock0a.optus.net.au) left irc: Quit: brb [04:10] serving (~serving@213.186.189.86) left irc: Ping timeout: 499 seconds [04:11] Bert you still around? [04:11] yup [04:11] -k-, I have a prob, hopefully you can help me, I may have to talk to simon [04:11] I am using his vskel script [04:11] creating 5 vservers off the same skell [04:12] if I delete a file from inside a vserver that is global it only does it for that vserver [04:12] if I edit it, it edits it for all vservers [04:12] yeah, that is supposed to be so ... [04:13] but you should not be able to 'edit' shared files .. [04:13] yes, the delete [04:13] -k- [04:13] then why, how do I fix it [04:14] well you should check, why those files are editable at all ... [04:14] check with lsattr and showattr (from the vserver tools) [04:15] [root@localhost root]# /usr/local/lib/util-vserver/showattr /vservers/.skel/skel1/global/bin/zcat [04:16] / vservers/.skel/skel1/global/bin/zcat 00000000 [04:17] that is a file I deleted from on vserver. all good [04:17] I edited in another [04:18] and changed it in all [04:19] well, it should be immutable and iunlink ... [04:19] but it has none of those flags set, so the result is somewhat expected ... [04:20] -k- [04:20] so [04:20] if you do setattr --immutable --immulink [04:20] on that file, before you 'try' to modify it from a vserver, you will get the expected result ... [04:21] does it support recursive? [04:22] no .. but applying to all files would disable your vservers immediately ... [04:22] Well, I have global type things, like /bin that I want users to be able to delete [04:23] but not change accross every vserver [04:23] ie. user = root from inside a vserver [04:23] well, I guess the vskel tool should take care of setting those flags [04:24] Action: WSU pokes Simon [04:28] chattr -R +it $skelpath/global/* [04:29] that is what is done when the global is created [04:30] hmm [04:30] I think I fixed it [04:30] hmm, well it's not correct, and obviously didn't catch ... [04:30] yeah [04:30] I'm checking right now [04:34] hmm, what kernel/patch combo do you use? [04:34] somehow that +it didn't stick, or didn't happen [04:34] I just reran that command [04:34] and it is working as expected [04:35] WSU: what did you edit with? [04:35] just vi -b [04:35] deleted the elf header [04:35] did the inode change? [04:35] It was that the +it attributes were missing [04:36] were they missing before you edited it? [04:36] yes [04:36] Not sure why, they should have been there [04:36] but they weren't [04:37] # touch test ; chattr +it test ; lsattr test ; ls -i test [04:37] ----i------t- test [04:37] 1933666 test [04:37] # vi test [04:37] [:w!] [04:37] # ls -i test ; lsattr test [04:37] 1933668 test [04:37] ------------- test [04:37] you see what the editor does? [04:37] new inode [04:38] yeah, but when you look at test.orig [04:38] (if you have backup enabled) [04:38] you'll see that this is the shared inode ... [04:38] right [04:38] and a change to the 'new' inode, could in no case propagate to the shared inode ... [04:39] which was the case for WSU ... [04:39] hmm [04:39] let me see if I can re-create that [04:39] I would suspect the path argument in that script ... [04:40] a chattr +it will have no effect at all, when done on /tmp ;) [04:40] :) [04:40] all my global files have +it on them [04:41] and my skeleton-derived vservers have +it on the proper files [04:41] yes I think something must have happened when I merged/split the skel [04:41] and please, all users of chattr, keep in mind that +t will change soon ... [04:41] What will be required to migrate? [04:42] hopefully we'll have a tool by then, which is capable to convert an entire partition ... [04:43] but the +t flag actually is the notail flag, so we'll discontinue the use ... and switch to an unused flag ... [04:43] Question about using iptables in a vserver [04:44] answer: don't do it! [04:44] I thought that that was working? [04:44] yup it is, but it is a security leak ... [04:44] explain [04:45] well, there is no per vserver networking atm., so manipulating iptables, means access to the host iptables [04:45] granting NET_ADMIN to vserver is required to do this ... [04:46] ah ok, so that is what you were talking about earlier lo device being hsared [04:46] *shared [04:46] yeah, basically you have bind/conenct checks, but a 'shared' networking stack ... [04:47] Do you have a devel patch that supports this? [04:47] virtual networking or what? [04:48] yeah [04:48] I would like to be able to let each vserver have it's own iptables [04:49] you could always provide a web interface for iptables to each of your vserver clients [04:49] well, I was working on some virtual network device, but the netfilter guy wasn't able (or willing) to help me ... so this is on hold :( [04:49] the use of in vserver iptables is limited ... [04:50] -k- [04:50] accounting and firewalling seem to be the only valid usages [04:50] MrBawb, I was thinking of the same thing. [04:51] both can be done more efficiently on the host, and distributed to the vservers ... but anyway, if there is big demand for such things, work will continue ... [04:51] Bertl: after seeing the sourcecode, it seems to be a very good idea to let tools like ipppd run in an own vserver... [04:52] ensc: don't trust ipppd? [04:52] (and enable exec-shield, and/or use libsafe) ;) [04:52] dan: well nobody does ... [04:52] heh [04:52] how about running it as a user, chrooted? [04:52] the best choice is to run it on a separate box ;) [04:52] chroot() has nothing to do with security... [04:53] ensc: if its chroot()+setuid(!=0) then it does [04:53] thanks for the help [04:53] something booting from CD ... [04:53] gotta go [04:53] cu [04:53] Nick change: WSU -> WSU_away [04:54] MrBawb: afaik, ipppd must run as root [04:54] ensc: ah, thats much more trouble then [04:54] (he says obviously) [04:55] okay, any suggestions which proc entries could be required in a vserver? [04:55] and would be useful to have? any chance to test this? [04:57] I wonder how many people's /proc entries have random data from a hostile root in mind [05:00] hmm, no suggestions? well it's quite clean with 'self' + pids ... [05:14] dionv (~dionv@masq-van7ant.skynet.ca) joined #vserver. [05:14] hi dionv! [05:15] hi Bertl [05:32] does anybody need anything from me? [05:33] (because if not, I'm off to bed ;) [05:35] okay, have a good whatever ... [05:35] Nick change: Bertl -> Bertl_zZ [05:54] say (~say@212.86.243.154) left irc: Ping timeout: 499 seconds [06:08] dionv (~dionv@masq-van7ant.skynet.ca) left #vserver (Client exiting). [08:41] click (click@gonnamakeyou.com) joined #vserver. [08:42] vat (vat@pD9E374A3.dip0.t-ipconnect.de) joined #vserver. [08:42] huhu [08:42] vat [08:42] click :) [08:43] herb's sleeping again [08:43] hihi. [08:43] bertl_zz: when you wake up, do this in a vserver: [08:43] no problem at all ;-). [08:43] (in a script) [08:43] #!/bin/bash [08:43] cat /dev/random >/dev/null [08:43] ./test.sh [08:43] ---done--- [08:43] and check the load [08:44] this may need some fixing [08:44] ack. [08:44] preventing total overloads [08:44] i think.. the box will perhaps crash if it runs some days.. [08:44] *g* [08:44] vat: did you apply any of the quota patches? [08:44] uhm. no. [08:44] we are using image files [08:44] mounting loops? [08:44] not a bad idea. [08:44] jup [08:44] gave me one :D [08:45] how do you create them? [08:45] ;-) [08:45] mom [08:45] it must give some overhead tho? [08:45] we got a mk_vdisk [08:46] care to send it over? [08:46] shall i post it? [08:46] yeah [08:46] here? ;) [08:46] how long is it? [08:46] 9 lines [08:46] would work I guess [08:47] #!/usr/bin/perl [08:47] [08:47] $filename = @ARGV[0]; [08:47] $size = @ARGV[1]; [08:47] $size = $size * 1024 ; [08:47] print "Erzeuge Image Files ".$filename."\nDies kann einige Minuten dauern... "; [08:47] system("dd if=/dev/zero of=".$filename." bs=".$size." count=1024"); [08:47] print "fertig.\n"; [08:47] print "Erzeuge Filesystem...\n"; [08:47] system("mkfs.ext3 ".$filename); [08:47] --done-- [08:47] usage: ./mk_vdisk name size-in-bytes [08:47] as long as its vserver-related I'll think herb would love it [08:47] and then mounting it with ? [08:47] vat: why don't you use sparse files for the image file? [08:47] click: /etc/fstab [08:48] after that -> debootstrap woody directory [08:48] enter, base-config blahblah ready [08:48] of course vserverconfig file first *g* [08:48] youam: how do we set a decent vquota? [08:48] youam, well. we need work :p [08:48] click: erm... no idea [08:49] youam: well, thats why :D [08:49] click: i thought so after you "hinted" my this :) [08:49] course we could make a clean baseimage file and copy it when we need..senseless use of diskspace, which we do not have ;); [08:49] :) [08:50] hm, THAT gave me a fucking good idea [08:50] we've got space enough anyway [08:50] hehe ;) [08:50] scsi SAN's are nice [08:50] we are using raid1 for the vservers. [08:51] youam: got a better idea for restricitng size on the vservers, except making partitions for each one? [08:51] well.. with the image files, we know when a disk is full.. that's the clue on it. [08:52] vat: you're doing a mount -t loop blabla /file for each vs in fstab? [08:52] what about quotas on them? [08:52] f.e. /vserver/disks/vl02s27.disk /vserver/vl02s27 ext3 defaults,loop 0 0 [08:52] well.. quotas are not such a good idea, since we need to know, when diskspace will getting full ;) [08:53] i'm thinking more of vserver quota [08:53] hm. [08:53] youam: are they implemented now? [08:53] it's easier to use for us, maybe. [08:53] click: i have *no* idea about that, sorry... [08:54] vat: well, i was thinking more of having vservers with quotas in the fs [08:54] but imho the one-partition-for-each thingie is bad because you can't share your free space [08:54] youam, hm. why? [08:54] you know when the disk is full.. [08:54] that's enough to know ;) [08:54] why should I need free space on the vserver partitions? [08:54] mhm, true, but I've got shellusers that we want to restrict as well [08:55] giving them max 10mb / account [08:55] swap is on another partition, the hostsystem, too. [08:55] vat: you can't have soft quotas with fixed partition sizes [08:55] youam, yup ;). therefore we use imagefiles ;). [08:56] youam: got a good implementation on how to fix my problem then? [08:56] vat: same problem here [08:56] using two imagefiles [08:56] one with the basesys and the other with (in the vserver) /home [08:57] click: none that i'd know of, but... i never used quota yet and vserver only since tuesday, so i'm just an average guy trying to help by making clueless remarks [08:58] _vat (vat@pD9E373CA.dip0.t-ipconnect.de) joined #vserver. [08:58] <_vat> i hate 24hrs disconnects.. [08:59] <_vat> really. [08:59] <_vat> ;-) [08:59] youam: hehe ok, well, I'm a bit further than that [08:59] vat: downing storm in a few, relocating it to a loop-mount [08:59] <_vat> okay. [09:00] <_vat> don't forget to patch kernel drivers/block/loop.c at anytime.. [09:00] <_vat> else you will just have max 8 loop devices [09:00] got to recompile for that [09:00] well, going to 2.4.24 anyway [09:00] thus, not a big problem [09:00] <_vat> dunno why kernel developers changed that value to this.. when 255 loops are possible [09:01] mem-wide I believe [09:01] _vat: you can adjust that by specifying "max_loop" on insmod or /etc/modules.conf [09:01] <_vat> youam, i know. but making it *real* in the kernel should be better IMHO [09:01] if loop is a module, yeah [09:02] click: if you have it compiled in hard, it should work specifying it on the kernel command line [09:02] <_vat> youam, nah. i don't like command line options : [09:02] <_vat> :p [09:02] hm, true [09:03] vat: when creating the fiskfile. you could ask for a filename and size using bash instead of perl [09:03] much easier [09:03] perl's implementation is so much bigger [09:03] diskfile [09:04] hm, never ran mke3fs on images before [09:04] storm.gonnamakeyou.com.vdisk is not a block special device. [09:04] Proceed anyway? (y,n) y [09:04] correct? [09:05] <_vat> hm [09:05] <_vat> thnik so [09:05] <_vat> think so, even. [09:06] vat (vat@pD9E374A3.dip0.t-ipconnect.de) left irc: Ping timeout: 492 seconds [09:06] Nick change: _vat -> vat [09:08] brb. [09:09] WSU (~irc@c-67-164-197-32.client.comcast.net) joined #vserver. [09:09] Hi [09:09] is there a simple way to uninstall the util-vserver tools? [09:10] I want to do them with a different prefix [09:10] squirt (uob@bb220-255-104-186.singnet.com.sg) left #vserver. [09:11] vat: had to mount without blocksize etc [09:11] then it plays nicely [09:11] make uninstall [09:11] actually works [09:11] nice :) [09:11] heh [09:11] :D [09:12] it is usually a good thing to check before asking :) [09:21] this should be fun [09:21] added a 4gb loopdisk [09:38] | perlarnings -mstrict -mData::Dumper -e 'my $seen; while (<>) { if (! defined $seen->{$_}) {print $_; $seen->{$_}="YES";} }; print "FOO".Dumper %{$seen};' [09:38] ups. [09:40] vat: found out the 255.0.0.0 thing [09:40] vat: i forgot to add broadcast on the ifaces-list in the cfg [09:55] hehe [09:55] okay ;) [09:55] played broadcast this time :P [09:55] eh [09:55] <- dumb. [09:55] bzflag ;) [09:56] tyr to log in now [09:56] vat / vat [09:56] added a few ip's as well, making sure I can control my own domains and vhosts ;] [09:56] :) [09:56] HAHA [09:57] apt-get install vat [09:57] it's actually a program [09:57] jaja [09:57] heh [09:57] ganz gut doch [09:57] it's value added tax also ;) [09:57] :) [09:57] hihi :) [09:59] hm, dmesg: operation not permitted, als root :) [09:59] grsec ist ja ganz ok [10:22] arghs. [10:22] got ip accounting error :/ [10:23] mysql querys ran wild [10:23] *fixx* [10:29] WSU (~irc@c-67-164-197-32.client.comcast.net) left irc: Ping timeout: 499 seconds [10:37] kestrel (~athomas@dialup51.optus.net.au) left irc: Ping timeout: 499 seconds [11:08] serving (~serving@213.186.190.94) joined #vserver. [11:33] argh, argh, argh.... I've still got that fucking 16 ip-limit... Gotta fix that and recompile, and then restart *sigh* [11:47] serving (~serving@213.186.190.94) left irc: Read error: Connection reset by peer [11:58] serving (~serving@213.186.190.94) joined #vserver. [12:41] vat (vat@pD9E373CA.dip0.t-ipconnect.de) left irc: Quit: Leaving [12:47] youam (~youam@sc-gw.scientific.de) left irc: Read error: Connection reset by peer [13:16] suhcoolbro (~Suh@216-161-89-24.ptld.qwest.net) left irc: Ping timeout: 499 seconds [15:40] Simon (~sgarner@apollo.quattro.net.nz) left irc: Quit: so long, and thanks for all the fish [15:42] kestrel (athomas@dialup51.optus.net.au) joined #vserver. [16:12] micah_ (micah@micha.hampshire.edu) joined #vserver. [16:19] micah (micah@micha.hampshire.edu) left irc: Ping timeout: 499 seconds [16:20] ccooke (~ccooke@80.1.164.238) left irc: Remote host closed the connection [16:26] Doener_zZz (~doener@pD9E12CCB.dip.t-dialin.net) joined #vserver. [16:29] maja (maharaja@is.the.one.who.rules.at) joined #vserver. [16:29] re [16:30] ensc: you reported a bug in the ext2 dev libraries. can you post/query/... the correct line? i fail to resolve this issue :-/ [16:31] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112448 [16:33] doener_zz (~doener@pD9E12B97.dip.t-dialin.net) left irc: Ping timeout: 492 seconds [16:39] ccooke (~ccooke@80.1.164.238) joined #vserver. [16:50] nathan_ (~nathan@209-6-130-26.c3-0.sbo-ubr1.sbo-ubr.ma.cable.rcn.com) joined #vserver. [17:09] TamaLunch (~a@193.173.84.237) joined #vserver. [17:09] oy [17:09] Nick change: TamaLunch -> Tamama [18:28] Nick change: micah_ -> micah [18:29] wheee [19:21] mount -o bind is nice :D [19:58] Pony (~jon@129.142.112.33.ip.tele2adsl.dk) joined #vserver. [19:58] Nick change: Pony -> JonB [20:21] when having 1GB RAM is it better to enable high memory support, or to lose some MB? [20:21] Nick change: Bertl_zZ -> Bertl [20:21] oops, wrong # [20:22] no [20:22] well enrico, in most cases it's better to lose some memory, will be 992 left [20:22] (why is irsii reordering # list at each restart?) [20:22] ok, thanks ;) [20:22] or was it 962? [20:22] when we are at hardware questions: is HyperThreading support stable in Linux? [20:22] ensc: it is not the wrong channel [20:23] 962 i guess [20:23] Nick change: Doener_zZz -> Doener [20:23] at least the text in menuconfig says so ;) [20:23] ensc: HT is stable, but not as efficient as real SMP [20:23] Bertl: why is it better to lose memory ? [20:23] well actually depends on the MB and chipset [20:24] but most machines do not support High I/O and that support is a little flakey too [20:24] so the well known bounce buffers will kick in, memory management will get confused about the 'small' highmem area ... [20:24] and buffering will get worse ... [20:25] okay, have to get something to eat, brb (20min) [20:25] Bertl: can it not just stuff things in there that does not need buffers? [20:25] Nick change: Bertl -> Bertl_oO [20:25] Bertl_oO: what about 1280MB memory ? [20:37] I just enabled high memory.. the hardware supports it just fine :D [20:43] suhcoolbro (~Suh@63-224-250-137.ptld.qwest.net) joined #vserver. [20:45] Nick change: Bertl_oO -> Bertl [20:45] stubbsd (~stubbsd@217.206.216.194) joined #vserver. [20:46] JonB: well I'd say with 2.4.x 1.5GB is the minimum for Himem ... [20:46] I'm trying to run "expect" on a vserver and it say that there are no ptys avalible any ideas? [20:46] hmm, doesn't expect use ptm/pts as everything else now? [20:47] I have know idea, I will go looking. [20:47] s/know/no/ [20:47] try to strace it (V >= 4.5) [20:48] Bertl: if the MB doesnt support high I/O, why not just put programs in that memory ? [20:49] because there is no way to make 2.4 NUMA on i386 easily [20:49] and I guess this would even require some code not present in 2.6 ;) [20:50] Bertl: can we back up a little [20:51] Bertl: i suppose the cpu cache can cache the whole 32 bit address space? [20:52] sure no problem with that .. [20:52] numa? [20:52] 4GB on x86 and 64GB on PTE machines ;) [20:53] Bertl: so, it is the DMA that can not access the hole 32 bit address space ? [20:54] yup [20:54] bingo [20:54] dma has been a pita for along time now (as well as only 16 irq lines) [20:54] oh well, just flaws we need to live with :) [20:55] well actually 4 lines.. heh [20:55] Bertl: okay, why cant the kernel put programs, and other stuff in the part of the memory where the dma wont work, stuff that only the cpu reads (other than one copy from the hd to the memory, using dma, and one copy to the high place (i mean, is there a technical hinder for that ? [20:56] it impacts speed (double copy needed) [20:57] no basically not, but you have to define 'DMA' and 'MEM' area and there is no 'EXEC' area per se [20:57] so where driver allocate special DMA areas, programs won't [20:57] this results in copying DMA space to MEM space ... and back (bounce buffering) [20:58] Bertl: that could be avoided with the right coding in the kernel, right ? [20:59] Bertl: how can i know if my MB uses bounce buffering ? [20:59] jup, as I said 2.4 in 2.6 the bounce buffering is much better, as is the memory allocation [20:59] well simple, do some disk benchmarking with and without highmem .. [21:00] Bertl: well, there is vserver 2.6 useable ? [21:00] if the benchmarks drop on highmem enabled .. its not advised to enable it ... [21:00] Bertl: hmm, i guess i have to test that then [21:01] and please let me know the outcome, I'm always interested in such test results ... [21:01] Bertl: sure [21:03] well SMP kernel seems to work so far.. but then again i still need to actually add the 2nd cpu [21:03] Action: Tamama whistles [21:04] hmm Tamama you are testing what exactly? [21:04] everything i come across [21:04] so it varies :) [21:04]