[00:00] Bertl: old program to transfer files between computers [00:00] norse: might be, don't know ... run http://vserver.13thfloor.at/Stuff/testme.sh for a test [00:00] norse: that's the message I was getting earlier :) [00:00] JonB: nullmodem cable is hardware, but a 'fastlynx' might have used such a cable ... [00:01] Can't set the new security context\n : Bad address [00:01] Bertl: hmm, i'll look into what i can get [00:01] Mcleod, heh, how did you solve it mate? [00:01] i've seen that error too :) [00:01] norse: i'm yet to solve it :D [00:01] you can get nullmodem adapters at radioshack still i think. just little things that look like gender bendors you plug into teh send of a serial cable that switch the pinouts around. [00:01] ouch [00:01] norse: but that isnÄt the only output, right? please show me the complete output [00:02] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Quit: Tak ja padaaaaM [00:02] ah, sorry mate, didn't want to flood the channel (hence the \n). should I priv you or is there a flood channel on this network? [00:02] norse: however, perhaps do 'ifconfig' and check the broadcast and netmask in the vhost.conf file - check with Bertl :) [00:02] norse: priv is okay [00:02] cheers mate [00:03] Bertl: Linux sanitytech02 2.4.25-vs1.26 #5 SMP Fri Feb 20 05:39:35 CST 2004 i686 unknown [00:03] Bertl: yay! [00:03] norse: tools are to old, 0.22 from Jack wont work anymore, I guess ... [00:04] the tools are more than a year old .. you require at least 0.24 [00:04] but I would suggest to update to util-vserver 0.29 for example [00:04] aye, that's what I did to resolve it the last time [00:04] Mcleod: so what was the problem? [00:05] Bertl: fresh install from theplanet, and sshd/network wasn't set to auto-start :/ [00:05] I must admit I missed that the tools were that old. the only reason I installed this package was due to the debian-specific newvserver. [00:05] i'll bite my tongue and blame myself for not checking.... [00:06] don't do that, you will regret it the minute after ;) [00:07] Bertl: yay, vserver appears to be running [00:07] Bertl: only one quirky thing remaining.. [00:07] Bertl: # vserver yamaha status [00:07] Server yamaha is not running [00:07] but i can indeed enter it [00:07] should not happen ... let's investigate that one [00:07] first step, try the testme.sh on that setup/kernel ... [00:08] alright, one final question and I promise I won't bug you guys for.. oh, at least an hour or two, heh. what is the preferred way to create new virtual servers? is there a standalone script or anything that doesn't require linuxconf? [00:08] Linux-VServer Test [V0.06] (C) 2003-2004 H.Poetzl [00:08] chcontext is working. [00:08] chbind is working. [00:08] Linux 2.4.25-vs1.26 i686/chcontext 0.29/chbind 0.29 [E] [00:08] --- [00:08] [001]# succeeded. [00:08] [011]# succeeded. [00:08] [031]# succeeded. [00:08] [101]# succeeded. [00:08] [102]# succeeded. [00:08] [201]# succeeded. [00:08] [202]# succeeded. [00:09] okay, looks good, now you did start the yamaha vserver? [00:09] norse: I think i can answer that, just my 2c, safe to ignore it though, you can create your own /etc/vservers/myvps.conf, then run 'vserver myvps build' [00:10] norse: http://www.linux-vserver.org/index.php?page=alpha+util-vserver [00:10] Mcleod, does it actually create a working system or is it lfs? for instance, I want my vservers to be debian-based. [00:10] Bertl: it appears to start, but doesn't [00:10] # vserver yamaha start [00:10] Starting the virtual server yamaha [00:10] Server yamaha is not running [00:10] ipv4root is now 69.93.207.112 [00:10] Host name is now yamaha.sanitytechnology.com [00:10] New security context is 49155 [00:11] # vserver yamaha status [00:11] Server yamaha is not running [00:11] okay, now do: 'cat /var/run/vservers/yamaha.ctx' [00:12] [root@sanitytech02 vservers]# cat /var/run/vservers/yamaha.ctx [00:12] S_CONTEXT=49155 [00:12] S_PROFILE=prod [00:12] [root@sanitytech02 vservers]# ps auwxwww | grep 49155 [00:12] [root@sanitytech02 vservers]# [00:12] okay, so it is working as expected, but your server doesn't start any services, so it basically auto terminates [00:13] Bertl, and you save the day again [00:14] hey hey, I saved the world today, everybody's happy now the bad things gone away ... [00:14] Bertl: what should be started on bootup? [00:14] (anything?) [00:14] well, your vserver should start some services ... maybe it requires the fakeinit [00:14] don't know which runlevel scheme or whatever you have in that vserver [00:16] mmm [00:16] util-vserver [00:16] put everything in /usr/local/etc/rc.d/init.d [00:16] whereas redhat wants it in /etc/rc.d/init.d [00:17] look one of my server on startup looks like this: [00:17] # vserver TEST start [00:17] Starting the virtual server TEST [00:17] Server TEST is not running [00:17] ipv4root is now aaa.bb.cc.ddd [00:17] Host name is now TEST.virtual.vs [00:17] Domain name is now [00:17] New security context is 2102 [00:17] Starting system logger: [ OK ] [00:17] Starting X Font Server: [ OK ] [00:17] Starting sshd: [ OK ] [00:17] Starting httpd2: [ OK ] [00:17] Starting postgresql service: [ OK ] [00:17] Starting crond: [ OK ] [00:17] yep, that looks healthy [00:17] :) [00:18] just not sure why mine isn't doing that [00:18] check your yamaha vserver, if it contains a runlevel script, and if the services are enabled (if your distro for the vserver supports sysv init scripts) [00:19] Doener (~doener@pD9E12A72.dip.t-dialin.net) joined #vserver. [00:19] hi Doener! [00:19] hi [00:21] Bertl: i'm starting to think I should go back to vserver-0.28 as that was for redhat at least... [00:22] hmm, vserver-0.28 is a good choice, it doesn't even bother with setting secure caps [00:24] i'm completely unfamiliar with all these different source trees [00:24] it's simple, there _WAS_ vserver (including vserver-0.xx) up to 0.26 [00:25] i don't know why my vserver instance isn't trying to start anything at the moment, but i'm looking into it... [00:25] it was then sporadically maintained by Jacques up to 0.29 (which is broken) [00:25] ahh [00:25] Jackques has disappeared again, and the maintained tree is util-vserver [00:25] my vserver was a copy of the current install [00:25] and had nothing in the startup enabled [00:25] Action: Mcleod slaps himself [00:26] lack of sleep is catching up on me [00:27] quite possibly one of my last questions [00:27] Bertl: could you perhaps explain what the v_httpd v_sshd startup scripts do? [00:27] sure [00:28] they are used on the host (not on the vservers) [00:28] and the idear is, to restrict the services to a limited set of IPs so that they do not collide with the vserver services [00:28] -r [00:30] ok, so they're designed to make the host bind only to its own ip's and not the vserver ips? [00:30] netrose (john877@SP2-24.207.225.23.charter-stl.com) joined #vserver. [00:31] if so, would it make just as much sense to make sure those services were bound to a single ip instead? [00:32] yeah, that is an alternative, if that can be configured with the service [00:32] for example you can use a specific ListenTo startement in sshd/httpd config [00:33] yup [00:33] ok cool [00:33] i do have good news [00:33] the v_* services just enforce this limitation ;) [00:33] my vservers are running :D [00:33] great! [00:33] thank you so much for your help [00:33] you're welcome! [00:34] this is a bit healthier at least [00:34] # vserver yamaha start [00:34] Starting the virtual server yamaha [00:34] Server yamaha is not running [00:34] ipv4root is now 69.93.207.112 [00:34] Host name is now yamaha.sanitytechnology.com [00:34] New security context is 49163 [00:34] Setting network parameters: [ OK ] [00:34] Bringing up loopback interface: Error, some other host already uses address 127.0.0.1. [00:34] arping: socket: Operation not permitted [00:34] [FAILED] [00:34] Bringing up interface eth0: arping: socket: Operation not permitted [00:34] Error, some other host already uses address 69.93.207.112. [00:34] [FAILED] [00:34] Starting system logger: [ OK ] [00:34] Starting kernel logger: [ OK ] [00:34] Starting sshd: [ OK ] [00:34] Starting sendmail: [ OK ] [00:34] Starting crond: [ OK ] [00:34] Starting atd: [ OK ] [00:34] not sure about the binding to 127.0.0.1 error.. [00:34] you should remove the hardware related runlevel scripts [00:34] maybe by commenting the appropriate sections out ... [00:35] the vserver will not be able to mess around with the hardware (detection/configuration) on startup and shutdown ... [00:35] yep that makes sense, i'll have to make the vservers alot more 'minimal', atm its simply a copy of the host [00:49] Bertl: can vserver limit memory usage? [00:49] yes, virtual memory [00:50] Bertl: OK, i hadn't noticed/read about that yet, can you point me at a URL please? [00:51] well, it requires development or exp branch ... [00:51] ah ok [00:52] not overly sure if i want to try something out thats not known to be stable.. [00:56] Bertl: any comments about particular releases in the devel tree? [00:57] what shall I comment on them? [00:57] are they seriously unstable ? :) [00:57] if they where, I would label them 'seriously unstable' right? [00:58] they are under development, so it might be that the one or other thing is broken .. [00:58] or maybe 'experimental' ... ok i'm looking like a numbut [00:58] experimental is the current 2.6 branch [00:59] so if you do use experimental kernels 2.6.x (now called stable ;) [00:59] then this is the branch for you ... because it's the only branch for 2.6 atm [01:00] ok ta, i'll give 1.37 with 2.4.25 a shot [01:03] as much as I hate to reboot again :-) [01:05] Bertl: is the virtual memmory limits an addon or part of the std devel release? [01:05] (sorry for being such a pain, you're just being so helpful!) [01:06] np, it is part of the devel branch ... [01:07] norse: there is a typo on your page ... [01:09] norse: If other words; -> In other words; [01:21] JonB (~NoSuchUse@kg203.kollegiegaarden.dk) left irc: Quit: Leaving [01:31] ExpiryJames (~james@h24-71-63-164.ok.shawcable.net) joined #vserver. [01:31] hi james! [01:32] Hi bert.. [01:32] still up? [01:32] seems so ;) [01:32] somebody has to work on vserver, right? [01:32] thats right, [01:33] And thank you for your work.. [01:33] don't mention it ... [01:34] what brings you here? just the community mood? [01:39] bengrimm (~ben@bengrimm-host225.dsl.visi.com) joined #vserver. [01:39] hi ben! [01:39] hi Bertl [01:40] how's it going? [01:40] good, working on 0.09 and 1.3.8 as well as q0.14 atm [01:40] and how are you? [01:41] oh good, getting frustrated compiling 2.4.25 for a machine at a colo [01:41] hmm, what's the issue there? [01:42] oh, I think it's just a module that I'm missing [01:42] nothing vserver related [01:42] (except that it's a vserver kernel) [01:42] why not use the 'old' kernel config? [01:42] ah - the old config is the default fedora config... that's no good [01:43] ic [01:43] never had the vserver kernel working on this server yet (or the vanilla kernel for that matter) [01:48] so 1.3.8 is coming out then? [01:48] Nick change: bengrimm -> ben [01:48] yeah, might be out tomorrow ... [01:48] fun fun [02:01] ben: what features do you miss most in vserver? [02:02] hmm [02:05] if it felt more like a real server that would be nice [02:06] i.e. like UML but without the overhead [02:06] especially what aspects? [02:06] emulation of proc would be the nicest feature [02:07] full network access without turning on cap_net_raw [02:07] hmm, so faking entries there, right? which ones? [02:07] yep, more faking of entries [02:08] ensc (~ircensc@ultra.csn.tu-chemnitz.de) left irc: Read error: Connection reset by peer [02:09] what for example? [02:09] ensc (~ircensc@ultra.csn.tu-chemnitz.de) joined #vserver. [02:09] because there was a direction I called 'stealth' vserver, which addressed this, but there is not much feedback atm [02:10] uptime, *info stat, net, net/ tcp, udp, unix, *stat [02:11] those would be the ones that I've had to turn on to get functionality [02:11] I saw mention of the stealth vserver somewhere [02:12] what I'd like is if/when a vserver is compromised to somehow hide the fact that it's living inside another server [02:13] hmm, well while this might be theoretically possible, it's a little problematic, because you have some things, you just can't allow inside a vserver (but you can allow it in uml for example) so it can be easily detected that you are 'not' on a real server (hardware access for example) [02:14] that's true - without virtualizing the hardware you couldn't do it [02:15] could create dummy devices that behave in predictable ways i suppose [02:15] but that's all fringe - not core to making vservers better [02:16] so while you might fool a program, you will not be able to fool a human ... [02:16] but I agree that 'virtualizing' (this is another approach ;) is useful for things like /proc/mounts for example ... [02:17] right, a person will still know - or if they didn't know immediately, they'd figure it out that the devices that were present don't match up to what you'd expect to find in a server [02:18] but definitely if I had my choice of things to make work better - I'd say proc [02:18] eliminate the need for vproc or setattr [02:19] (although there will probably always be a need for those tools) [02:19] the idea behind that is to find a minimal/optimal set for /proc entries ... which then will be implemented as sane default ... [02:19] sure [02:19] (you can change it, if you want to) [02:20] just need to find the absolute minimum to be able to run without errors [02:20] so many utilities use proc to get their data [02:24] hmmm, what else [02:27] we've got memory protection between contexts, do we have filesystem protection? [02:27] could one context delete a file, and another allocate that disk space and read its contents [02:28] i suppose we don't really even have memory protection in that respect [02:29] isn't that type of stuff in grsec? [02:29] well, the memory/disk security question is the same as with normal server users, right? [02:29] yep, believe so [02:30] so the idea would be to add further isolation between vservers [02:30] well, the question is, for what purpose would you like to separate the memory between vservers better, as the memory is separated between users now? [02:31] but i'm not sure the memory is really separated between users [02:31] once freed it can be allocated by any process [02:31] yes, and? [02:31] and freeing memory doesnt clear its contents [02:32] allocation to userspace does [02:32] cdub, so memory is cleared upon malloc? [02:32] ben: no [02:32] ben: it's cleared when a page is given to userspace [02:33] malloc() may reuse (w/in the process) after free() [02:33] glibc has an allocator that sits on top of kernel allocator [02:33] ah - so between processes there's no danger [02:33] since the memory goes back to the kernel [02:33] yeah. otherwise we'd have big problem already ;-) [02:34] ;-) still learning about the kernel [02:34] ben: userspace still needs to memset(addr, 0, len) to be sure, because it could have come from local reuse of buffer [02:34] ben: well, insightful thought, anyhow ;-) [02:35] gotcha - I'm sure that's where I was getting that idea from [02:35] so disk allocation then, probably not zero'd [02:35] ben: and to do separation between vservers is not realistic [02:35] what do you mean by disk allocation? [02:36] when you allocate space for a file (without filling it with anything) [02:36] hmm, with the allocate_space_for_file syscall? [02:36] like truncate()? [02:36] think so [02:36] these are not mapped until written [02:37] so you can get zero page when you read from it [02:37] so it's safe too [02:37] ah - ok [02:37] maybe I'm thinking windows ;-) [02:38] ben: heh, maybe, although it's a _serious_ problem for an OS not to do such [02:38] I would say so, but as you say - it's already taken care of by the kernel [02:39] yes [02:39] the only thing grsec adds in that area is adress space randomization (per process) and non-exec stack (via PaX) [02:41] cool cool - learn something new every day [02:42] I've been using linux since '96 and never really cared too much about how/why it works [02:43] heh, fun to poke under the hood ;-) [02:43] i think the first thing i changed - and only because I had to - was a disk geometry calculation [02:44] it wouldn't recognize my drive [02:44] got a bigger disk? [02:44] yep, back when 40G was 'bigger' [02:44] heh, yeah [02:47] anyhow - vservers are good things [02:47] i get to have entire servers fail over with heartbeat - rather than just processes [02:48] and beyond that I can have production, test and dev all living on the same real server [02:48] with the same paths for all ot them, just can't beat it [02:49] ben: why would you failover between two vservers? what's the secenario you're working with? [02:49] just for testing? [02:49] not fail between vservers - but fail a vserver to another real server [02:50] hmmm, is the other real server running vserver too? [02:50] (just trying to understand the use case ;-) [02:50] yep, pair of real servers [02:50] both have vserver kernel [02:50] both running drbd [02:51] and heartbeat [02:51] and vserver is just to isolate the app you care about from the rest of the host? [02:51] real server -> raid 1 -> drbd -> vserver -> database [02:51] right - vservers to isolate applications from each other [02:51] *nod* [02:52] you use multicast? [02:52] or broadcast? [02:52] (or the serial stuff?) [02:52] the servers have 3 nics and serial [02:52] 1 out to the net [02:52] one interesting aspect of failover vserver use would be to disable synchronization on purpose (somehow?) update a vserver on one machine, switch over to that one, and sync up ... [02:52] 1 connected to a 100M switch and 1 1000M crossover [02:53] but - broadcast - yes [02:53] ben: ah, you should try multicast ;-) [02:53] er - hrmm, one sec [02:54] yeah broadcast [02:54] Bertl: you mean to break the vserver and reunify it? or the drdb replication? [02:54] is multicast better somehow? [02:54] ben: waaaay better, heheh [02:54] the drdb replication ;) [02:54] Action: cdub wrote it [02:54] even over a crossover? [02:54] ahhh [02:54] ;-) [02:56] bertl, you could definitely do that [02:56] Bertl: yeah [02:56] depends on the app though [02:57] morning [02:58] norse (~norse@h118n2fls35o804.telia.com) left #vserver (wargames.unix.se). [02:58] morn alec! [03:00] top of the morning [03:01] hi mids! [03:02] Action: cdub looks at his clock...morning? ;-) [03:02] cdub, isolation the big benefit for me though [03:03] ben: yeah [03:03] yeah I've got 6pm here... ;-) [03:03] Bertl: do you care for unix socket communication? or other local ipc? [03:04] care as in 'take care of separation for vserver' or as in 'use it somewhere'? [03:04] the former [03:04] we try to .. but I guess it is a little untested ... [03:04] hrm, just thinking about it, because heartbeat uses named pipes [03:05] well, any good tests are apreciated, as always ... [03:05] and a patch i'm reviewing right now ignores those things as well [03:06] Bertl: hrm, ok, i'll look into it tomorrow, i think i can use the same test for both cases [03:06] (meaning vserver and the patch i have here) [03:06] a grep into the aptch tells me that there is something ;) [03:06] hehe [03:06] diff -NurpP --minimal linux-2.4.25/ipc/util.c linux-2.4.25-vs1.26/ipc/util.c [03:06] diff -NurpP --minimal linux-2.4.25/ipc/util.h linux-2.4.25-vs1.26/ipc/util.h [03:07] but a test will be appreciated ;) [03:08] Bertl: anything that uses the filesystem can be somewhat taken care of with the vserver /root [03:09] well, it should be, but what about communicated pipes? [03:10] do you mean named pipes? or just regular pipe? [03:10] named ones .. [03:11] what do you say to the following: [03:11] # vuname -s --xid 100 --machine "abc" [03:11] # chcontext --ctx 100 uname -a [03:11] New security context is 100 [03:11] xyz (none) 2.6.3 #12 Fri Feb 20 01:04:55 CET 2004 abc unknown [03:11] hrm, also, there's fd passing, so it could be any fd... [03:11] nice ;-) [03:12] or [03:12] # vuname -s --xid 100 --release "1.0.0" [03:12] # chcontext --ctx 100 uname -a [03:12] New security context is 100 [03:12] FATAL: kernel too old [03:12] just in for the community, ( bert to answer your question from when I joined) [03:12] # vuname -s --xid 100 --release "2.2.0" [03:12] # chcontext --ctx 100 uname -a [03:12] New security context is 100 [03:12] Linux (none) 2.2.0 #12 Fri Feb 20 01:04:55 CET 2004 i686 unknown [03:14] i like it [03:14] hehe [03:14] we like it too 8-) [03:19] Heya Bert, the other day you told me to upgrade my util-verver tools to get static ctx's , I did and they still aren't working.. How can I tell if the utils verstion is correct? [03:19] chcontext --help [03:19] chcontext version 0.29 [03:19] chcontext [ options ] command arguments ... [03:24] hmm, test with the testme.sh script first [03:24] http://vserver.13thfloor.at/Stuff/testme.sh [03:33] thanks, [03:36] everything succeeded [03:36] could you show me the first 4 lines, maybe in private? [03:37] Linux-VServer Test [V0.06] (C) 2003-2004 H.Poetzl [03:37] chcontext is working. [03:37] chbind is working. [03:37] Linux 2.4.24-vssmp1.23 i686/chcontext 0.29/chbind 0.29 [E] [03:37] 2.4.24-vssmp1.23 was the latest compiled version [03:38] hmm, intersting ... enrico, any ideas? [03:38] what is the error? [03:39] just that the static context doesn't seem to work [03:40] okay, could you provide your vserver config somewhere? [03:40] what means "not work"; fails chcontext, or do you get a dynamic ctx? [03:41] hmm, this morning it gave a dynamic context, i restarted it sometime today and didn't look at the context but it is corr3ect [03:42] however i can't seem to stop the vserver [03:42] hmm, you probably started with the old tools, and didn't stop the vserver before updating, right? [03:42] gettin a failed for everything... [03:42] or changed from dynamic to static while the vserver was running? [03:43] I instlled the tools yesterday and hat a boot since then [03:43] hmm, okay, that should work then [03:43] maybe that wass it [03:43] what does vserver-stat report? [03:44] that musta been the problem [03:44] I/the other admin changed the ctx while it running [03:48] thanks, [03:48] okay, so it _is_ working now, right? [03:49] yes, its working correctly. [03:49] problem between keyboard and chair [03:49] okay, perfect, np [03:50] i meant only to lurk, i tend to learn alot from the chatter [03:51] well, that is very similar to the testing/stable issue [03:52] if everybody is waiting until a version is stable, and nobody actually tests it, it will never happen ... [03:52]