Reported by eagle on 14 Dec 2008 03:34 UTC
install.pod and checklist.pod currently still refer to the default /usr/local/news installation path rather than the inn.conf variables (I<pathbin> and friends) that are used elsewhere in the documentation. They should be changed to be consistent.

Reported by eagle on 14 Dec 2008 07:05 UTC
It's often useful to rebuild a whole set of groups stored in tradindexed, but tdx-util -R requires specifying both the newsgroup and the path, making it impossible to just use xargs or feeding it a list of groups. The path to the newsgroup should be possible to determine based on the normal algorithm and the article spool root, so the path argument to -R should be optional.

Reported by eagle on 14 Dec 2008 08:44 UTC
If innd is throttled, rnews currently fails the articles and moves them into the bad directory with an error like:

Apr  7 22:32:29 genba rnews: unknown_reply after article 400 loadav [innwatch:load] 1977 gt 1500

rnews really should just defer the articles if INN is throttled, but right now it doesn't have a great way to do that. I wonder if rnews should try to query the local control socket to get INN's status before trying to post messages, at least in -U mode.

Reported by eagle on 14 Dec 2008 07:14 UTC
Cancel-Lock was a draft for a way to authenticate cancels cryptographically, the idea being that all articles would contain challenges that could only be met by the person knowing the original challenge secret. A cancel would then only be honored if it had the answer to the challenge in the article.

Abuse of cancels has dropped considerably and the Cancel-Lock protocol never made it to an RFC, but it may still be worth looking at supporting this in INN.

The first attached approach is from Andreas Barth. It has the following features:

• A user can only post cancels for articles that are local posted or were originally generated and canceled by a cancel-lock enabled newsreader. The administrator may however allow users in readers.conf to post cancels for every article.

• The patch adds just a very small burden on accepting articles and cancels with post and almost no burden at all for transferring articles.

• Any news system could detect whether a cancel for an article originating at your site is fraud.

The patch does the following:

• if an article is posted, - unless existing - a user cancel lock is added, and always an admin cancel lock is added.

• if a cancel (oder supersedes) is posted, a user cancel key is always added. Now it is checked, whether one of the keys matches one of the locks. If yes, the cancel is accepted. The cancel is also accepted, if the original article is (no longer) available, or the original article has no lock and was posted before a given time (to allow for the transition periode). Otherwise, the cancel is rejected.

You must also create the files /etc/news/canlock.def and /etc/news/canlock.adm and fill them with any characters (but please use printable characters, that makes the live of fgets easier). The patch needs some polishing before inclusion, especially review and removing of the fixed path for the secret files.

Also attached is another approach. Both require the libcanlock library, also attached.

• libcanlock.tar.gz (libcanlock library)
• canlock.tar.gz (another Cancel-Lock patch, older)
• nnrpd-cancel-lock.patch.txt (patch against INN 2.3.5)

Reported by eagle on 14 Dec 2008 07:43 UTC
Reported by Miroslaw Luc [email protected].

1. ps reads all of the strings from argv, not just argv[0], to the nearest NULL. Setting argv[1] to NULL helps ps to read only argv[0].

2. If the length of the initial args > argv[0] modified by setproctitle() then ps discards the latter and displays the initial args. The problem is that it is always true because of using SPACES in ovdb_monitor/ovdb_server and `-s' in nnrpd.

We should:

1. Set argv[1] to NULL in setproctitle().
2. Move the environment to malloc()'ed space to make a room for argv[0].
3. Spawn nnrpd without `-s'.
4. Remove SPACES from ovdb_init,monitor,server.

It's not clear if this is worth it; setproctitle() seems to be getting less and less popular.

Reported by eagle on 14 Dec 2008 08:50 UTC
We should have documentation of how UUCP article feeds work and exactly what's needed to set it up and make it work. Here are some old notes from Andrew Gierth and Olaf Titz.

To be precise, the feeding site batches up articles from a feed (using batcher), and sends them via uucp by invoking (e.g. via the -p option of batcher) a command of the form:

uux - [options](other) sitename!rnews

which means "invoke the command 'rnews' on host 'sitename', using standard input from the uux command".

(The example given in the batcher manpage is to use:

(echo '#! cunbatch'; exec compress) | uux - -r -z %s!rnews

as a -p option to batcher; this compresses the batch first.)

The receiving site shouldn't need to do anything other than ensure that rnews is permitted to the sending site, and that uucp is otherwise working, which means, at least for recent INN versions, make sure that:

• you have a symlink of ~news/bin/rnews to /bin (so uuxqt finds it)
• rnews is installed setgid news and executable for the uucp user

This is not done automatically, the set[ug]id thing has to be enabled in configure now.

Reported by eagle on 14 Dec 2008 07:20 UTC
ckpasswd -f expects crypt() passwords, and not everyone has a copy of htpasswd handy. Attached is a C program from Ajax Ajax [email protected] to generate the password hash. Something like this should probably be included for people who don't have htpasswd.

• mkcryptpw.tar.gz

Reported by eagle on 14 Dec 2008 08:31 UTC
Currently, groups that exist but that one isn't allowed to read receive different error codes (480 or 502) than groups that don't exist (411). This lets users probe for the existence of groups, which may be an information leak.

Add support for a hide: key in readers.conf listing a wildmat of groups for which nnrpd will pretend complete non-existence, returning 411 instead of 480/502. This lets news administrators hide groups at the cost of clients not knowing when to do reactive authentication for them.

Reported by eagle on 14 Dec 2008 04:43 UTC
Diablo supports a mechanism to take an incoming feed split across multiple boxes by hashing the message ID and only feeding the articles in a particular hash bucket to a given host. This lets the hosts collectively store a full feed without handling the full traffic on each host.

INN should support this sort of hash feed via a flag in newsfeeds.

• diablo-hashfeed.patch.txt

Reported by eagle on 14 Dec 2008 07:30 UTC
The history backend currently uses the dbz code in lib, which builds with tagged hash depending on compile-time options. This defeats the whole point of having a pluggable history API. Tagged hash should be a separate history backend that can be selected at run-time.

This will requiring untangling the code in lib/dbz.c and updating makedbz to call into the API instead of knowing about the dbz format internally.

Reported by eagle on 14 Dec 2008 08:22 UTC
Switch nnrpd over to using the new wildmat routines rather than breaking apart strings on commas and matching each expression separately. This involves a lot of surgery, since PERMmatch is used all over the place.

Add support for @ in group permission wildmats to not allow reading an article if it's crossposted to any excluded group.
! would keep meaning what it means everywhere else: disallow this group, but possibly still allow the article if crossposted.

Obviously, the distinction only applies to articles retrieved via message ID rather than by reading a group.

Reported by eagle on 14 Dec 2008 07:17 UTC
A tool from Jeffrey M. Vinocur for analyzing spool usage. Worth including in contrib at least, possibly incorporating into other reporting tools.

• analyze-traffic.pl.txt

Reported by eagle on 14 Dec 2008 08:40 UTC
A full-blown manual for INN would be great. Here is some discussion from an e-mail message that I sent in 1999.

We currently already have what's essentially a reference manual; that's the collection of all of the man pages plus the three README.*_hook files. They need some glue, and more extensive cross-referencing, but that's not too hard.

We have the beginnings of an introductory guide, in the form of README (after the work I did about a month ago) and INSTALL, plus pieces of Elena's document. What that mainly needs at the moment is an overview of how INN works, including descriptions of the major files involved, stuck in-between those two documents and some documentation of the periodic maintenance tasks that one has to do stuck after INSTALL.

We need more general discussion of how specific parts of news work and how to do specific things; we currently have a doc on control messages but that's about it. I have a few things planned here. Part of what should go in this part is schemes for setting up specific types of servers. (If I want a basic feed and reader machine, what do I do? If I want a split feed and reader setup, what do I do? If I want to share the same reader spool across a bunch of machines, what do I do? If I want to set up a standalone server for a particular hierarchy, what do I do? How do I run nnrpd standalone rather than from innd?) Elena's document has some of that.

We're badly missing internals documentation, apart from a few really outdated library man pages.

The overall structure I'd like to see is something like this:

• Introduction

• Basic Usenet Concepts

• User's Manual

  • Building and Installing INN
  • Configuring INN
  • Maintaining INN
  • Platform-Specific Issues

• Configuration Manual

  • Specific Setups
    • Mixed Feed and Reader
    • Separate Feed and Reader
      • INN as Feed Machine
      • Other Server as Feed Machine
    • Farm of Readers With Same Spool
    • Standalone Public Server
  • Performance Issues
    • Major Bottlenecks
    • Choosing a Disk Layout
    • Tuning an INN Server
  • Filter Configuration
  • Namespace Management
    • Control Message Processing
    • Using actsync

• Reference Manual

  • Primary INN Programs
  • Configuration Files
  • Maintenance and Recovery Programs
  • File Formats
  • Library Interfaces
  • Special Issues
    • RFC Compliance
    • Theory and Practice of Control Messages

• Programmer's Manual

  • Code Structure
  • Major Data Structures
  • Documentation Maintenance

Anyway, that's entirely off the top of my head just now, but if you look that over, we actually have a surprising amount of that already. Particularly if you count the stuff that was in the old FAQ. It just isn't well-organized, tied together, explained, cross-referenced, and indexed.

Getting documentation, any documentation, is more important right now than any particular structure, but I'd strongly encourage people to think in terms of a structure like the above and have at least a tentative idea of where the documentation that they're writing would fit in. That way, it will be much easier for us down the road to produce a coherent and readable overall set of documentation.

Reported by eagle on 14 Dec 2008 08:24 UTC
Requested by Bill Davidsen:

A mode for grephistory (or some other tool, but that seems the most natural fit) that retrieves all records between two times, for any of posting, arrival, or expiration.

Reported by eagle on 14 Dec 2008 06:44 UTC
INN currently strongly assumes that it owns a directory hierarchy and most of its files are relative to that directory hierarchy. It's possible to configure it otherwise, but only with significant path customization in inn.conf. It also doesn't separate the different types of binaries (user binaries for bin, system administrator binaries for sbin, and programs only run internally by INN for /usr/lib) very well.

The old installation paths should probably remain for backward compatibility, but an --enable-fhs option to configure that puts everything in the right place for the FHS would make packaging for FHS-compliant distributions much easier.

Attached is a patch from James Ralston that starts to implement this. From his patch explanation in 2001:

• The configure.in file now supports a --enable-fhs-dirs option, which changes the defaults for most of the other directory-related options. It's equivalent to specifying about 10 different options manually. (Unfortunately, it necessitated abandoning the nice INN_ARG_DIR macro.) Use of --enable-fhs-dirs is documented in INSTALL.

• The directory for nnrpd authorization programs is now a separate configure option (--with-auth-dir), with its own corresponding inn.conf parameter ("pathauth"). It defaults to $(prefix)/bin/auth if not set, which is the exact same place that the auth programs are currently installed.

• DESTDIR is now properly supported (the existing support was broken in several ways). The "make install" and "make cert" steps properly obey DESTDIR. The use of DESTDIR is now documented in INSTALL.

• It is no longer a requirement that the installation step be done by the superuser, as long as the user executing the install has supplied a DESTDIR value that points to a writable directory, and the person or process performing the install corrects the file ownerships when INN is installed on the system on which it's going to run. Non-root installs are now documented in INSTALL.

• Multiple typos in INSTALL were fixed.

Things left to do:

• Make the location of the rnews.libexec subdirectory configurable, the same as auth-dir / pathauth.

• When the --enable-fhs-dirs option is given, only shared/static libraries should be placed into libdir; relocate everything else to appropriate directories.

• Figure out what to do about --bindir, --sbindir, and --mandir. Should we use them (probably in a way not intended by configure), or create new options? Both approaches have disadvantages.

Patch:

• inn-CURRENT-20010405-fhs.patch.txt

Reported by eagle on 14 Dec 2008 06:08 UTC
NHNS was a protocol for putting group information into DNS, including moderation addresses. This is an old patch from Marco d'Itri to add support for this. This project may now be dead; I'm not sure.

• nhns.diff.txt

Reported by eagle on 14 Dec 2008 03:48 UTC
INN originally used a hand-rolled build system and made libtool optional because both were extremely slow on the development platform I had at the time and that's how the original conversion from the old build system was done.

It's now many years later, computers are a lot faster, and Git Autoconf and libtool are considerably faster. We're adding a lot of complexity by maintaining our own build system. (I switched to Automake for all of my other projects some time ago and never looked back.)

A non-recursive build structure would be particularly nice, although it makes partial builds more difficult, but even a traditional recursive Automake setup would be an improvement.

The dynamic generation tricks that storage and history do will need revision for Automake and probably need to be done at configure time instead.

Reported by eagle on 14 Dec 2008 03:40 UTC
When logging incoming article counts, innd logs two types of log messages: closing messages when the remote peer terminates the connection, which summarizes all articles received on that connection and then reset the counter, and checkpoint messages, which say how many articles were received so far.

Currently, innreport takes into account checkpoint messages if no subsequent closing message is seen, but since connections can be open for days, this can produce skewed numbers on how many articles have been received. The articles received on previous days aren't properly subtracted from the checkpoint value.

One possible solution would be to store a local file holding the last checkpoints that innreport processed, and then read that file at the beginning of a new run and subtract off those numbers from subsequent checkpoints. There would need to be some way to run innreport and not save changes to this file.

Reported by eagle on 14 Dec 2008 06:21 UTC
This patch from Christoph Biedl [email protected] allows one to store filtered articles into a separate storage class instead of just rejecting them (allowing one's spam filtering rules to be reviewed, for example).

• store-filtered.diff.txt
• log-filtered.patch.txt (Follow-on to improve logging and outgoing feeds)

Reported by eagle on 14 Dec 2008 06:32 UTC
Sven Paulus wrote in 2000:

Another problem concerning innfeed came up on de.admin.news.misc some days ago: Someone posted an article containing a Message-ID 494 characters long. Now some NNTPRelay and Diablo peers rejected this Message-ID as being too long with an 500 return code (= syntax error). innfeed logged a cxnsleep message and requeued the article for resending it later. You surely will guess what follows? innfeed is happily trying to resend this article over and over again, until you force a shutdown of the innfeed process and dig the Message-ID out of the batch files ...

The real problem is, that innfeed has only one return code handler for all commands, so you have to figure out, whether the 500 was in reply to an IHAVE, to a CHECK or to a TAKETHIS command.

My idea how a handler function for 500 replies could look like is this, but I haven't tested it yet (I'd have to setup a isolated test environment, I don't want to pollute the 'real' net with articles causing problems). But maybe who knows innfeed a little better than me could have a look on it and say if this makes sense.

• innfeed-500-handler.patch.txt

Reported by eagle on 14 Dec 2008 07:34 UTC
A patch from Christopher Biedl to alter ARTcancelverify to check whether at least one group in the cancel message can be found in article to be canceled.

• verifycancel-newsgroups.patch.txt

Reported by eagle on 14 Dec 2008 06:57 UTC
From Dmitry Yasir [email protected], this is a patch to support sending articles to a remote server with POST instead of IHAVE. This is kind of broken from a protocol standpoint, but is a workaround in some situations without real feeds.

• innxmit-post.patch.txt

Reported by eagle on 14 Dec 2008 06:54 UTC
The NNTP protocol uses whitespace as a command and argument separator, which means that passwords containing whitespace don't work. The generic NNTP parser in nnrpd throws away the tail end of the password or produces a syntax error.

However, since the password is the last argument, we can hack around this problem. Here's a patch from Jeffrey M. Vinocur from 2001 that implements that fix, which may require some updating.

• misc.c.txt
• nnrpd-argify.txt

Reported by eagle on 14 Dec 2008 05:44 UTC
Implements Diablo-style MODE HEADFEED. It might be better to wait for some standardization of the protocol before adding something like this.

From Miquel van Smoorenburg:

This is a patch I've had laying around for a few years and that I never got around to testing. It's against inn-2.4.1 and compiled fine in 2004, but its completely untested.

Anyway I'm posting it here so that it's in the archives, so that if anyone ever wants to implement this functionality inn innfeed they have a possible starting point.

• innfeed-headers.patch.txt

Reported by eagle on 14 Dec 2008 06:00 UTC
The new USEPRO draft will recommend that netnews implementations verify that the Path header matches the expected path identity of the peer sending the article and embed a warning into the Path if not. Diablo already does something like this.

Attached to this ticket is an implementation from Andrew Gierth that doesn't use the same keywords that were finally arrived at for USEPRO, but which may be a starting point.

The patch also has other, unrelated changes which ideally should be split out into separate tickets but which I haven't had time to do. The full list of what it does is:

• merged version of NNTPconnect/NNTPlocalopen/NNTPremoteopen; this allows the use of Unix-domain sockets for parameters like nnrpdposthost (I use this to put a filter process between nnrpd and innd)

• patch to the innconfval program to actually recognise the INNCONF variable

• a bugfix to control-only feeds (junked non-control articles were being fed down control-only feeds)

• an RChostlabel function (like RChostname). (I use this in other modifications, not included here, to make most of the logging that previously used the hostname now use the feed label from incoming.conf instead, because I want to. perhaps that should be an option?)

• a few more headers in the header list.

• changed the HTML status filename to end in .html to keep the webserver happy.

Many of these changes are already made in CURRENT.

• auth-path-header.patch.txt

Reported by eagle on 14 Dec 2008 06:38 UTC
This patch from Andrew Gierth adds the capability to feed articles accepted and filed in junk (due to wanttrash) to peers based on their feed patterns (applied to the Newsgroups header as if the article were accepted and all those groups were carried). This is required if you want to run INN with a minimal active file and propagate all posts.

• feedtrash.patch.txt

Reported by eagle on 14 Dec 2008 06:10 UTC
A rewrite of sendinpaths in Perl from Mohan Kokal.

• sendinpaths.pl.txt

Reported by eagle on 14 Dec 2008 04:25 UTC
The different implementations of innshellvars currently use different names for the same variables (SPOOLBASE, for example, in the shell version). We should standardize so that everyone uses the same name for the same thing and everyone exports the same variables.

This will break backward compatibility, so needs to be done in a major release.

Reported by eagle on 14 Dec 2008 06:34 UTC
Patch from Yury B. Razbegin [email protected] to add support to innd for prepending a static header to all HTML status output. This can be used to customize the HTML, add a style sheet, etc.

• innd-status-header.patch.txt

Reported by eagle on 14 Dec 2008 05:37 UTC
GnuTLS has a nicer API and a very active upstream, as well as a nicer license for some purposes. It would be nice to support either TLS library in nnrpd (which would probably require refactoring the TLS code extensively so that we could support multiple underlying layers, since the OpenSSL compatibility code in GnuTLS is probably not up to the task).

Reported by eagle on 14 Dec 2008 08:43 UTC
When a newsgroup is removed with rmgroup, nothing cleans up the articles in tradspool and timehash (and possibly also timecaf). The old articles continue consuming disk space and, if the group is recreated, serve as land mines for the server when the article numbers get back to the same range.

The easiest way to fix this is probably to provide an interface to delete all the articles from the spool immediately on an rmgroup. We lose our current partial ability to recover from a mistaken rmgroup, but I think that's a good tradeoff.

Reported by eagle on 14 Dec 2008 07:27 UTC
The current history file format on disk varies depending on whether INN was built on a 32-bit or 64-bit system, or was built with large file support or not. The on-disk file format should be standardized and dynamically updated if need be so that systems can move from 32-bit to 64-bit.

Attached is a patch from Marco d'Itri that was used for the Debian INN packages, which adds a 64-bit variant of the history backend. This isn't the best solution, but it's an interesting workaround.

• his64.diff.txt

Reported by eagle on 14 Dec 2008 03:36 UTC
INN has enough documentation that it would benefit from having an installed index page that points to the other man pages. Following Perl, having an inn(1) man page that lists the other available man pages is probably the easiest way to do this.

Reported by eagle on 14 Dec 2008 04:08 UTC
nnrpd currently has no way of limiting connections per IP address other than using the custom auth hooks. In its daemon mode, it could in theory keep track of this and support throttling. It's probably not worth trying to support this when invoked via inetd, since at that point one could just use xinetd and its built-in support for things like this.

When started from innd, this is a bit harder. innd has some basic rate limiting stuff, but nothing for tracking number of simultaneous connections over time. It may be fine to say that if you want to use this feature, you need to have nnrpd be invoked separately, not run from innd.

Reported by eagle on 14 Dec 2008 03:11 UTC
innd doesn't support matching IP address ranges in incoming.conf (entries such as 192.168.0.0/16) the way that nnrpd does for readers.conf. This was requested for dealing with uu.net feeds, where they have a /24 that might send outgoing news.

Due to the way that incoming connections are matched, this isn't a trivial change. innd would need to store the strings to match instead of address structs and then use network_addr_match().

Reported by eagle on 14 Dec 2008 07:54 UTC
Reported by Julien ÉLIE:

There is a problem in the name of the last report of the year. Instead of being named news-notice.2006.12.31-04.15.02.html, it is named news-notice.2006.01.01-00.00.00.html and thus breaks everything in the html page (it is put at the bottom...).

And the line is Jan 1 00:00:00 -- Dec 31 23:59:59 instead of Dec 31 04:15:02 -- Jan 2 04:15:03.

Reported by eagle on 14 Dec 2008 03:30 UTC
Add encoding specifications such as:

  # Output encoding for newsgroups file.
  /encoding/:utf-8

  # Incoming encodings in checkgroups.
  /encoding/:*:cp1252
  /encoding/:cn.*:gb18030
  /encoding/:fido.*:utf-8
  /encoding/:fr.*:iso-8859-15

and then update docheckgroups processing to use iconv to convert newsgroup descriptions to the output encoding before adding them to newsgroups.

Reported by eagle on 14 Dec 2008 06:16 UTC
The attached patch from Sergey Babitch [email protected] adds the article size and post time to the innfeed tape files by letting innfeed understand (in a backward-compatible way) additional information in the channel feed from innd.

The patch doesn't make use of this data, but it can be used to show total article size in backlogs or to not transmit articles if the remote peer is known not to want articles that old.

• innfeed-log-size.patch.txt

Reported by eagle on 14 Dec 2008 04:40 UTC
inn-workers mail from Christiaan den Besten [email protected]:

We have recently been starting to compile INN in 64-bit on our (newer) 64-bit Linux spool servers. Since some time I have noticed we see more and more of ..

Jul 28 12:26:24 spool nnrpd[CNFS-sm: fudge size overflows bitmaps @03147374313600000000082C271800000002@ st16:0x10f7ff3b000: 179120864
Jul 28 12:26:24 spool nnrpd[753](753]:): CNFS-sm: fudge size overflows bitmaps @03147374313600000000082C271800000002@ st16:0x10f7ff3b000: 179120864

It looks likes articles are being 'overwritten' after some period of time or something like that. From what we have noticed it looks like postings arrive 'complete', but after some weeks they get broken, which would imply something is writing to the spool file at the wrong place ... which might explain the overflows.

Reported by eagle on 14 Dec 2008 06:28 UTC
There was a discussion of utilities to clean and merge newsgroups files in news.software.nntp in 1999. Here are two of the utilities posted. Something like this might be useful for contrib, or even as a regularly installed utility.

• mkngfile.txt
• cleannewsgroups.txt

Reported by eagle on 14 Dec 2008 03:21 UTC
The long-term intention is for the new config parser in lib/confparse.c to be used for parsing as many INN configuration files as possible. It would be nice to have Perl bindings to this interface so that Perl utilities could also make use of it (inncheck would immediately benefit).

Reported by eagle on 14 Dec 2008 07:51 UTC
INN has a generic hash table implementation, but it has no documentation. A man page or something would be nice.

Reported by eagle on 14 Dec 2008 06:05 UTC
Attached is a tradspool variation developed by Preben Guldberg [email protected] that stores additional metadata in the file name. The goal is to reduce the length of time it takes for expire to scan the spool. I haven't evaluated the merits of this in any depth.

• tradext.diff.txt
• tradspool.tar.gz
• tradext.tar.gz

Reported by eagle on 14 Dec 2008 05:29 UTC
signcontrol is currently unconditionally installed even though it has per-site configuration, so that configuration would be overwritten on make update.

It's not clear that INN should be shipping this program at all. Only a few people will need to issue PGP-signed control messages, and those who do can easily get it as part of the pgpverify distribution (or download one of the many other programs for this purpose).

Reported by eagle on 14 Dec 2008 05:55 UTC
Provide a Perl interface to the ctlinnd protocol. Marco d'Itri wrote a Perl module that reimplemented the protocol in native Perl in 1999 (attached), but even better would be to provide Perl bindings to the code in lib/inndcomm.c. Cleaning that code up first and abstracting it into a nice interface and protocol specification first would be nice....

• News-ICC-0.2.tar.gz

Reported by eagle on 14 Dec 2008 03:26 UTC
The only difference between doit and mail in control.ctl configuration of checkgroups handling is whether controlchan runs the checkgroups through docheckgroups to generate a shell script first. There's no way to tell the server to just make the necessary changes.

If this is added, there should probably be a corresponding configuration option telling controlchan the maximum number of changes that could be made at one time before bailing and mailing the changes to the admin.

Reported by eagle on 14 Dec 2008 05:35 UTC
Local postings are logged to the news log as originating from a site from the Path or possibly from elsewhere in memory. I see not-for-mail entries in the news logs, and other people have seen various peer sites.

Reported by eagle on 14 Dec 2008 08:26 UTC
After analysis of a syscall trace of expiration through tradindexed, the following would at least reduce the number of system calls:

• group.index is being opened and closed between every single group expiration, which is really rather unnecessary (and mmap isn't the world's fastest system call, so it may well be noticably slower to do this).

• Overview files that are empty shouldn't be expired in the first place; there's no point, and it would save a bunch of opens and renames.

• Setting the file descriptors to close on exec looks pretty painful in a trace, although I'm not sure how much of a performance hit it really is. It's an additional two system calls for every open, though, and Solaris's system call interface, unlike Linux's, is pretty painful. Those are only in there for innd; we should be able to make this some sort of configuration flag, maybe another flag to pass into OVopen() like the existing modes.

Reported by eagle on 14 Dec 2008 05:13 UTC
gpgverify uses the old attached signature verification method, which doesn't work properly for new-style GnuPG signatures that require Hash headers for attached signatures.

Given that pgpverify does the right thing and gpgverify was added just because it was a simplified version that assumed GnuPG, perhaps it should be removed.

Reported by eagle on 14 Dec 2008 07:58 UTC
Reported by Julien ÉLIE:

In newsfeeds, it appears that variables are not expanded when used within other variables.

For instance:

$VAR1 = group.test
$VAR2 = group.*,@$VAR1

If I feed a site with $VAR2, group.test is still sent to it.

It is not a problem of @$ since $VAR1 = @group.test or $VAR1 = !group.test leads to the same result with $VAR2 = group.*,@VAR1.