Hi. Someone just pointed me to this thread about agedu, and I thought I'd correct a misunderstanding or two.
Maximiliano Curia wrote: > I've been looking at the agedu project and from my point of view it has some > design flaws: > - It creates an index database file prior any query can be made, > and the index database is loaded fully into memory on every > query. It certainly is not! The index database is _memory-mapped_ by agedu, which means that only those parts of the file relevant to a particular query will be loaded from disk (but then they'll stay in the buffer cache for a while, of course, so that subsequent queries touching the same parts of the file need not load them again). The data structure is a log-time one, so the effort required for a query is of the order of log(file size). > - Unix utilities are based on the idea of, do one thing, but do it > well, a du that has an embedded web server cannot call itself a > Unix utility. I'd be happy to discuss alternative usage modes. A convenient means for agedu to hook into an existing web server as a CGI script would seem obviously useful, for instance. > - The web interface listens on: > > 127.randrange(0-255).randrange(0-255).randrange(2-255):randrange(1025-65535) > on behalf of "security" so other users can't see your agedu, > however any user can type: netstat -l to see where agedu is > listening > - The use of a random ip can be quite troublesome in certain > firewalls setups. The random IP address selection is not part of agedu's security strategy. Agedu's security in the default mode is based on looking up each incoming connection in /proc/net and finding out which user id owns the far end of it. So it doesn't matter if another user can find out where your agedu is listening: they'll still be told 403 if they try to connect to it. _That's_ the security layer. (If you don't like that, good old-fashioned HTTP Basic password authentication is supported as an alternative.) The random IP thing was just an attempt to avoid congesting port space too much (since I anticipated multiple users running it independently), and I'm prepared to consider that it might have been misguided and arrange for it to be easily disabled at compile time. Cheers, Simon -- Simon Tatham What do we want? ROT13! <ana...@pobox.com> When do we want it? ABJ! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
