The infamous to-do list

Olaf Titz olaf at bigred.inka.de
Sat Jun 24 15:54:47 UTC 2000


> * Some installed binaries and configuration files don't have man pages.
>   In particular, man pages are needed for actsync.conf, actsync.ign,
>   innreport.conf, and news2mail.cf.

The actsync config files are horribly ugly and unclear and that whole
mess should be reworked (which basically means rewriting actsyncd)
instead. One of the things it has to support cleanly is syncing
against multiple sources (e.g. my upstream for the standard groups,
news.mozilla.org for netscape.*).

> * contrib needs to be reviewed, the best ideas integrated into INN, and
>   some sort of general overview documentation written for everything else,
>   at least sufficient to explain what things are for.

What is the procedure to get something into contrib? :-)

> * Lots of people encrypt X-Trace in various ways.  Should that be offered
>   as a standard option?

Yes. The way I've already recommended this once goes as follows:
1. take the content of that line as string (built like now or perhaps
   with additional info) into a buffer
2. if an encryption routine is built in and a key configured
   then encrypt that buffer
3. output the buffer's content in base64.
This way you generate a useful header whether encryption routines are
available at install time or not.

It wouldn't be too hard to distribute this as a patch if legal
problems are still suspected.

Because it fits here: I have another wishlist item, standardized
support for Cancel-Lock.

> * Revisit support for aliased groups and what nnrpd does with them.
>   Should posts to the alias automatically be redirected to the real group?

No. This breaks the least surprise principle and the don't touch the
headers principle. Better reject the posting and leave it to the
client to sort out (as good clients already do).

> * sendbatch and send-uucp do the same thing.  So do send-nntp and
>   nntpsend, mostly.  Might be a good idea to unify them into single
>   programs (and easier to maintain).

In the INN 1.x days someone wrote a C News-like configurable
sendbatches driver; I'd like to see such a thing reappear. (Where you
can configure the size, compression and sending method for each peer
in a file and generate all batches with one command.)

> * ctlinnd flushlogs currently renames all of the log files.  It would be
>   nice to support the method of log rotation that most other daemons
>   support, namely to move the logs aside and then tell innd to reopen its
>   log files.  Ideally, that behavior would be triggered with a SIGHUP.

Speaking of SIGHUP, it would be nice if that could force a re-read of
inn.conf. ;-) But I doubt that can be done, too much is static AFAICT.

> * nnrpd should have support for fixing broken Date headers supplied by
>   clients, although now that most clients have been fixed for Y2K this may
>   be less of a problem.

I'd like to see this "fix" limited to a narrow set of special cases
like two-digit years, for the reasons stated above.

> * nnrpd's NNTP command parsing interacts poorly with AUTHINFO and
>   passwords containing spaces.  The correct solution isn't clear; check
>   with the current NNTP RFC draft?

Better (IMHO) first check with current clients' actual behavior. Not
sure if this would break anything though.

> * When articles expire out of a storage method with self-expire
>   functionality, the overview and history entries for those articles
>   should also be expired immediately.  Otherwise, things like the GROUP
>   command don't give the correct results.  This will likely require a
>   callback that can be passed to CNFS that is called to do the overview
>   and history cleanup for each article overwritten.  It will also require
>   the new history API.

I still favor the approach to drop the self-expire/non-self-expire
distinction completely and treat the disappearing of articles as
something which just does happen. This way you can use alternate
expire programs, which may suit local policies or installation issues
better, and the code gets less complex.

Still further in the future would be a complete rework of the expire
subsystem. I'd like a daemon which continually checks if articles are
expired or to be expired and does the necessary work, instead of the
current somewhat disruptive cron job. (To get this completely working
would need all databases, including history, in a format which allows
delete operations.)

> * Traffic classification as an extension of filtering.  The filter should
>   be able to label traffic as binary (e.g.) without rejecting it, and
>   newsfeeds should be extended to allow feeding only non-binary articles
>   (e.g.) to a peer.

One wishlist item for me (or is it implemented already in some way?):
the filter should be able to tell innd to file the article into (an)
additional group(s). This way I could define an extra group for local
postings, or make a kibozing group, etc.

> * The locking of the active file leaves something to be desired; in
>   general, the locking in INN (for the active file, the history file,
>   spool updates, overview updates, and the like) needs a thorough
>   inspection and some cleanup.  A good place to start would be tracing
>   through the pause and throttle code and write up a clear description of
>   what gets locked where and what is safely restarted and what isn't.

The current reserve/pause/throttle scheme is completely broken. One of
the more obvious problems is that expire fails if something else
happens to pause the server at the wrong moment. A possible way around
that would be a locking protocol that goes like this:

  while (!reserve()) {
    if (reason==throttled)
      return ERROR;
    sleep(30+random());
  }
  pause();
  /* do work */
  unpause();
  unreserve();

which is obeyed by _every_ program trying to access the history,
active etc. Another thing is that the PID of the lock-holder should
always be recorded in the lock message, to see if the process has
died.

This should all go into a library routine and probably into an
"ctlinnd lock" command, of course.

Olaf




More information about the inn-workers mailing list