From: <cg...@cd...> - 2002-03-26 12:21:36
|
a.p...@dn... said: > If you're looking for security perhaps its best you compile your own > without modules and with only those drivers you need to run. I'm planning to do that when I decide to go into production with it. But as I'm working from home with a 64kbit line, I'll take the security risk instead of having to download 23Mb worth of kernel source :-) > You could try putting the filesystem on a device, either a real > partition or a LVM logical volume; this should save some, possibly > small, overhead in the host linux. Yes, but in a mass-hosted environment where I'd ideally like to use cow files, that'd mean that you'd either lose some of the (small) speedup when putting the root fs file in an LVM volume and the cow file in a regular file, or you lose the advantages of sparse files when putting both into an LVM volume. I'm going to test the former (don't have enough space to create two volumes for the second scenario) and I'll report back when it makes a significant difference. -- Cees de Groot http://www.cdegroot.com <cg...@cd...> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B |
From: <cg...@cd...> - 2002-03-26 15:00:51
|
da...@da... said: > Don't you ever have lunch, go to the bathroom, or sleep? Just set it > off downloading and leave it. :-) No, why? Furthermore, even if I would do these strange human things, I happen to have landed my flying saucer in a country where you pay per minute for ISDN connections... > It won't do much to writes, or instance-specific files, but for > general binaries, it should speed up the UML slightly, I would have > thought. From a bit of benchmarking I've done it doesn't make a big difference. The largest speed-up comes from ubd-mounting a host directory structure (4-6 times faster than mounting a filesystem in a container). But there (and with NFS) you lose the flexibility to let stuff inside UML do whatever they want with userid's, file rights, etcetera. However, I'll probably put log files under a hostfs 'files' mounted mountpoint (the software in ubd+cow, and for home directories NFS or, if I get it to work, OpenAFS). -- Cees de Groot http://www.cdegroot.com <cg...@cd...> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B |
From: Jeff D. <jd...@ka...> - 2002-03-26 15:49:03
|
cg...@cd... said: > but I see there's no NFS client module supplied with the UML kernel. > Is that an oversight, or are there problems with NFS? NFS works fine. I've just never used it, so I've never enabled NFS in my standard configs. > So far, the TUN/TAP bandwidth seems good enough, it's just the FS > performance that ain't there yet (with 'ab' benchmarking Apache inside > UML from the host, I get around 0.67 requests per second and I'm quite > sure Apache is capable of more than that :-)). An ab run used to be one of my standard release checks, and IIRC, I was getting 100s per second. Is this with 'jail' enabled? Also, mount tmpfs on /tmp. That makes a noticable difference. Jeff |
From: <cg...@cd...> - 2002-03-26 16:17:29
|
jd...@ka... said: > An ab run used to be one of my standard release checks, and IIRC, I > was getting 100s per second. That's what I'm used to as well. Funny enough, I checked on the host system and I only get 7 per second on it. Something's rotten, I'll probably move the whole thing over to our production cluster so I have multiple boxes to test with. > Is this with 'jail' enabled? No. I'm using a chroot'ed setup (almost functioning, except for the bit that UML doesn't announce the pts numbers it allocates), and I read that was good enough. > Also, mount tmpfs on /tmp. That makes a noticable difference. Mounting tmpfs in the chroot'ed area is part of the setup I created. OBTW: the positive side is that I'm quite happy with it. I got SuSE 7.3 to 'install' (I copied the inst-sys directory to the ubd, booted that, mounted the cdroms, and went on with manual RPM work), networking seems to work fine, performance (apart from disk writes but lets blame my box for the moment) is adequate (CPU's are cheap...). Regards, Cees -- Cees de Groot http://www.cdegroot.com <cg...@cd...> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B |
From: Jeff D. <jd...@ka...> - 2002-03-26 18:24:25
|
cg...@cd... said: > No. I'm using a chroot'ed setup (almost functioning, except for the > bit that UML doesn't announce the pts numbers it allocates), and I > read that was good enough. I find it much more convenient to attach them to host portals. > Mounting tmpfs in the chroot'ed area is part of the setup I created. OK, that's good. > (apart from disk writes but lets blame my box for the moment) I've got plans for speeding up UML IO, so it will get better on the UML side. Jeff |
From: <cg...@cd...> - 2002-03-26 20:46:22
|
Jeff Dike wrote: > I find it much more convenient to attach them to host portals. > Call me a bloody newbie, but I haven't got the faintest idea what you're talking about here... -- Cees de Groot http://www.cdegroot.com <cg...@cd...> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B |
From: Jeff D. <jd...@ka...> - 2002-03-26 21:34:30
|
cg...@cd... said: > Call me a bloody newbie, but I haven't got the faintest idea what > you're talking about here... See http://user-mode-linux.sf.net/input.html In short, 'con=port:9000 ssl=port:9000' will make the UML consoles and serial lines available at the host's port 9000. So, you 'telnet localhost 9000' to access them. Adding 'con0=fd:0,fd:1' to that is recommended to keep the main console on stdin/stdout. Jeff |
From: David C. <da...@da...> - 2002-03-26 21:41:38
|
Jeff Dike wrote: > In short, 'con=port:9000 ssl=port:9000' will make the UML consoles and serial > lines available at the host's port 9000. So, you 'telnet localhost 9000' > to access them. Out of interest, which interfaces/IPs does that listen on? It'd be useful to restrict it to lo, if it's not like that already. Firewalling works to a point, but I'd like to avoid having UML listen on an Ethernet interface in the first place. David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Jeff D. <jd...@ka...> - 2002-03-26 23:37:00
|
da...@da... said: > Out of interest, which interfaces/IPs does that listen on? It'd be > useful to restrict it to lo, if it's not like that already. This is what it binds to: addr.sin_family = AF_INET; addr.sin_port = htons(port); addr.sin_addr.s_addr = htonl(INADDR_ANY); This makes it accessible by telnet from other boxes, obviously. I think that's pretty slick, but I could see you not wanting that. Is there a way to fiddle the bind address so it's only accessible to localhost? Jeff |
From: David C. <da...@da...> - 2002-03-26 23:51:34
|
Jeff Dike wrote: > This is what it binds to: > > addr.sin_family = AF_INET; > addr.sin_port = htons(port); > addr.sin_addr.s_addr = htonl(INADDR_ANY); > > This makes it accessible by telnet from other boxes, obviously. I think > that's pretty slick, but I could see you not wanting that. Is there a way > to fiddle the bind address so it's only accessible to localhost? addr.sin_addr.s_addr = inet_addr("127.0.0.1"); David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Jeff D. <jd...@ka...> - 2002-03-27 01:37:42
|
da...@da... said: > addr.sin_addr.s_addr = inet_addr("127.0.0.1"); Right, I was just looking at that. I think a syntax like 'con=port:127.0.0.1,9000' or con=port:127.0.0.1:9000' (any preferences?) would be easy to add. Then we just plug that IP into s_addr, and we're good to go. Jeff |
From: David C. <da...@da...> - 2002-03-27 02:01:13
|
Jeff Dike wrote: > I think a syntax like 'con=port:127.0.0.1,9000' or con=port:127.0.0.1:9000' > (any preferences?) would be easy to add. I was thinking more along the lines of; con=inet:127.0.0.1:9000 David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Roger B. <ro...@ro...> - 2002-03-27 17:14:28
|
> I think a syntax like 'con=port:127.0.0.1,9000' or con=port:127.0.0.1:9000' > (any preferences?) would be easy to add. I would suggest looking at the man page for the -i option to lsof. It already has to deal with this parsing, ipv4 vs v6, the address being optional etc. You may even be able to borrow their parsing code. Roger |
From: Jeff D. <jd...@ka...> - 2002-03-27 03:38:04
|
da...@da... said: > I was thinking more along the lines of; > con=inet:127.0.0.1:9000 Adding that as a new syntax, or just changing 'port' to 'inet'? Jeff |
From: David C. <da...@da...> - 2002-03-27 10:03:05
|
Jeff Dike wrote: > Adding that as a new syntax, or just changing 'port' to 'inet'? IMHO, 'inet' makes more sense than 'port' once you include an IP address. con=inet:9000 con=inet:127.0.0.1:9000 would be appropriate usage - If they don't spec. an IP, then have it listen on everything. David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Adrian P. <a.p...@dn...> - 2002-03-27 10:39:57
|
>>>>> "David" == David Coulson <da...@da...> writes: David> Jeff Dike wrote: >> Adding that as a new syntax, or just changing 'port' to 'inet'? David> IMHO, 'inet' makes more sense than 'port' once you include David> an IP address. David> con=inet:9000 con=inet:127.0.0.1:9000 David> would be appropriate usage - If they don't spec. an IP, David> then have it listen on everything. Or perhaps to be more exact :- con=inet:<address>:<port> con=inet::9000 (for all addresses) Does this syntax work okay for IPv6 ? Sincerely, Adrian Phillips -- Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [OK] |
From: David C. <da...@da...> - 2002-03-27 10:47:38
|
Adrian Phillips wrote: > Or perhaps to be more exact :- > > con=inet:<address>:<port> > con=inet::9000 (for all addresses) That would work too :-) > Does this syntax work okay for IPv6 ? Should do; It's up to UML how it parses the command line. David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: <Ulf...@t-...> - 2002-03-27 11:25:04
|
On Wed, Mar 27, 2002 at 10:47:31AM +0000, David Coulson wrote: > > Does this syntax work okay for IPv6 ? > > Should do; It's up to UML how it parses the command line. Weren't there some ":" in IPv6 addresses? I never used IPv6 so far but debian puts some addresses with colons into /etc/hosts for IPv6... Or is there an alternative representation without the ":" I do not know? -- # # Say it in Python ;-) # try: you.run(away) finally: borg.assimilate(you) |
From: Adrian P. <a.p...@dn...> - 2002-03-27 11:41:22
|
>>>>> "Ulf" == Ulf Bartelt <Ulf...@t-...> writes: Ulf> On Wed, Mar 27, 2002 at 10:47:31AM +0000, David Coulson Ulf> wrote: >> > Does this syntax work okay for IPv6 ? >> >> Should do; It's up to UML how it parses the command line. Ulf> Weren't there some ":" in IPv6 addresses? Ulf> I never used IPv6 so far but debian puts some addresses with Ulf> colons into /etc/hosts for IPv6... These :- ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts Ulf> Or is there an alternative representation without the ":" I Ulf> do not know? Exim has to work around its : seperated lists by "double coloning" things - so :- 127.0.0.1 : ::::1 How would IPv6 work for UML parsing I'm not 100% certain, but :- con=inet:<address>:<port> con=inet::9000 (for all addresses) con=inet:127.0.0.1:<port> con=inet:::1:<port> The last is a bit, umm, yucky but isn't necssarily a problem as far as I can see although it makes parsing more complicated. Perhaps its more complicated than this and an con=ipv6 option is needed ? Sincerely, Adrian Phillips -- Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [OK] |
From: David C. <da...@da...> - 2002-03-27 11:51:23
|
Adrian Phillips wrote: > The last is a bit, umm, yucky but isn't necssarily a problem as far as > I can see although it makes parsing more complicated. Perhaps its more > complicated than this and an con=ipv6 option is needed ? Just looking through my UML configuration, it would be more consistant to do; con=inet,<addr>,port as per the 'eth0' entries. Obviously this makes IPv6 address parsing much easier. If you were wanting to bind to an IPv6 port, one could either have UML figure out if the address is IPv4 or IPv6, or the user could use 'con=inet6'. It's more than just making it parse the command line correctly, as the bind() call must be changed from AF_INET to AF_INET6. David. -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Adrian P. <a.p...@dn...> - 2002-03-27 11:56:12
|
>>>>> "David" == David Coulson <da...@da...> writes: David> Adrian Phillips wrote: >> The last is a bit, umm, yucky but isn't necssarily a problem as >> far as I can see although it makes parsing more >> complicated. Perhaps its more complicated than this and an >> con=ipv6 option is needed ? David> Just looking through my UML configuration, it would be more David> consistant to do; David> con=inet,<addr>,port David> as per the 'eth0' entries. Obviously this makes IPv6 David> address parsing much easier. If you were wanting to bind to David> an IPv6 port, one could either have UML figure out if the David> address is IPv4 or IPv6, or the user could use David> 'con=inet6'. It's more than just making it parse the David> command line correctly, as the bind() call must be changed David> from AF_INET to AF_INET6. Excellent David, that fills in the holes. Now who's going to write the patch ? :-) Sincerely, Adrian Phillips -- Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [OK] |
From: David C. <da...@da...> - 2002-03-27 12:02:39
|
Adrian Phillips wrote: > Excellent David, that fills in the holes. Now who's going to write the > patch ? :-) Actually, we can't do that - It'll bugger up the way UML parses 'con=' entries at the command line; con=inet:<addr>,<port> would be acceptable though, as Jeff suggested yesterday. I'm not 100% of the best way to make use of 'inet6', since it only requires a few changes to one function, but will need an entire new section in chan_kern.c to permit UML to use it. I'm too dumb to figure it out myself :-) David. -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Jeff D. <jd...@ka...> - 2002-03-27 19:15:48
|
How about this: port stays the same - port:9000 means port 9000 with INADDR_ANY inet takes a mandatory IPv4 address - inet:192.168.0.254:9000 means what you think. You can get port semantics with 'inet:0.0.0.0:9000'. inet6 (or ipv6, any preferences?) is the same, except the mandatory address is IPv6. Jeff |
From: <Ulf...@t-...> - 2002-03-27 21:32:00
|
On Wed, Mar 27, 2002 at 02:17:40PM -0500, Jeff Dike wrote: > inet6 (or ipv6, any preferences?) is the same, except the mandatory address > is IPv6. The representation of an IPv6 address is easily distinguishable from an IPv4 address. Wouldn't it be possible (and nice) to use inet:<ADDRESS>:<PORT> for both versions? -- # # Say it in Python ;-) # try: you.run(away) finally: borg.assimilate(you) |
From: Jeff D. <jd...@ka...> - 2002-03-27 23:15:14
|
Ulf...@t-... said: > Wouldn't it be possible (and nice) to use inet:<ADDRESS>:<PORT> for > both versions? I don't like that. I think some redundancy is a good idea, so I prefer inet6:<IPv6>:<port> and inet:<IPv4>:<port> over inet:<IPv6>:<port> and inet:<IPv4>:<port>. Jeff |