Connaisez vous Usenet? I did, and I was an avid consumer of Usenet news which trickled in over UUCP, carried by a then tremendously expensive Telebit Trailblazer modem which cost me the equivalent of EUR 1300 today. But we tried everything to squeeze every last bit through those telephone wires at the time… I digress.


More than twenty (yes: 20!) years have passed for me since that time, and I’ll admit to having assumed that Usenet news was just about dead. I was wrong. It’s not dead, even though usage is perhaps on the decline, the volume of cra^W data that is carried over NNTP today is mind boggling.

I have inherited a rather large Diablo newsfeeding and news-reading/posting environment at a customer site which used to cater for several million clients. Most of those have meanwhile gone away, and we’re now trying to very heavily slim down the number of servers involved in the News operation.

Diablo was new to me (I was, at the time, very familiar with INN), so I got down and studied the (cough) documentation (cough), wading through sample configuration files, source code etc. until I felt I had a grasp of its inner workings.

Hah. Little did I know…

Diablo is typically used in large environments with specialized servers which act as so-called “feeders” and “readers”, and that is the setup I find before me. But I wanted to slim all this down and put all the components on a single machine.

To cut a very long story short, I don’t think I’ve ever given up on getting a piece of software do do what I expected it to do, but I almost did here. Most of the bits and pieces I wanted consolidated worked, but only “most” – not all.

After a plea of help, Johan came to my rescue late last night and drummed up an example configuration which worked out of the box. Thanks again, Johan!

Meanwhile I’m getting quite familiar with Diablo, and I’ve done the following, for posterity:

  1. I’ve set up a Github repository with Diablo patched with most of the XS4ALL patches.
  2. I’ve added a new LDAP authentication plugin to Diablo which does away with the ridiculous “copare passwords” operation and which supports returning different so-called _readerdef_s.

The LDAP authentication plugin allows me to differentiate between, say, free users and paying customers; if a user has a particular LDAP attribute type with a particular value, that user is marked as “PAYING”, and is then allowed, say, more newsgroups, etc.

The configuration in dreader.access looks like this:

authdef chooseauth
   ldap    /news/etc/ldap.params

readerdef PAYUSER
  read                  yes
  post                  yes
  groups                grouppaylist
  idletimeout           900

readerdef freeuser
  read                  yes
  post                  no
  groups                groupfreelist
  idletimeout           300

# This `rcluster` readerdef will use my (JP's) new LDAP plugin
# to search for and authenticate users. The plugin returns a
# string in the form '110 yyyyyy'. The 'yyyyyy' is used to
# associate with ANOTHER readerdef. So, for example, if
# "110 PAYUSER" is returned for AUTHINFO, the user will be
# associated with the `PAYUSER' readerdef above.

readerdef rcluster
  read                  yes
  post                  no
  auth                 chooseauth

access  0/0  rcluster

The ldap.params file contains four lines of text with an LDAP URI, the search base, a DN of an entry allowed to search the directory and the latter’s password:


The consolidation of the News infrastructure isn’t complete, but I did breathe a sigh of relief late last night, when the bits started coming together!