Response
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!
<anakin@pobox.com> When do we want it? ABJ!
Reply to: