Change of the guard...

[Dave Laird]

Good evening, everyone...

There are some more sacred cows in Debian when it comes to setting up a
"standard" INN news server that *none* of the documentation bothers to
describe, and some of the changes are pretty heavy, indeed. First, there's
a runt in every family, and in the case of Debian, they have introduced a
runt that isn't *really* INND, but hides behind its name and even uses
some of its Shell Vars. For the sake of the naming it is called INN.

Then, hidden in a nearby Debian galaxy there is the REAL INN news server
which, unlike the runt, includes what appears to be 98% of the original
INN news server's latest edition according to its authors, with several
minor and unneeded files omitted from the /etc/news/directory. Like most
miracles of modern scripting, miraculously if you follow the secret
procedure to unfurl the REAL INN from the .deb file, it actually
configures, installs and builds a history database for the news server.

You could put the amount of documentation which clearly differentiates
between the runt and its more mature INN family members with a match
stick, because in the harsh reality of the world, there is very little to
tell you about the perils of the runt, or the intricacies of the mature
version of INN built by Debian. One of the more embittering facets of
installing *either* of the two versions is that they are not script
compatible in the slightest, and there are no tools to overcome the errors
inherent in the scripting that installs the binaries.

Install the runt-version of INN. It runs pretty much out of the box, with
only a very few modifications to what few configuration files that ship
with it. It took me less than half an hour to make the first version of
INN I installed (the petite version, if you will) work. I was impressed.

However, if you install INN2, which is what the *real* version of INND is
called by Debian, although it does install fairly easily, it will not
function because, although the install script tells you it has
un-installed the INN baby brother for you, as part of the install, it
*never* gets the job quite right. From that point forward, everything
pretty much runs downhill as follows:

1. It never uninstalls either the /etc/init.d/inn or the /etc/init.d/inn2
startup scripts for you. However, if you mistakenly believe that you
should manually uninstall the inn script because you're going to run inn2,
guess again. There are numerous undocumented dependencies, any of which
will rise up and bite you in your anterior end.

2. Some, not all, the binaries in /usr/lib/inn/bin, get changed out if you
try to change versions. As a result, a *key* binary, ctlinnd, gets caught
in the middle, with /sbin/ctlinnd being installed for the small version
and /usr/lib/news/bin/ctlinnd being installed for the main version of INN.
Ditto goes for the startinnd binaries. This is not a good thing, folks.

3. It took *four* times of uninstalling and then re-installing INN before
it finally decided I *wanted* /etc/init.d/inn2, and then it totally
trashed the news history file, necessitating another frustrating 30 minute
wait while the history database was rebuilt from scratch.

ARGH! It was then and only then, after I had spent an additional five
hours attempting to configure and run the *real* INND daemon, that I
finally threw in the towel once I got INN actually running. The version of
INN that Debian refers to as INN2 is flawed in its installation, and it
requires dexterity and a fair amount of moxy to make it work.

Debian Woody (stable), despite it being out-of-date, is installed once
again, and then it took less than twenty minutes to configure both
sendmail and the real INN. I'll write this down as a lesson learned. There
is a *reason* why Debian refers to a release as unstable.

Dave

[James Vahn]

Post by Dave Laird
1. It never uninstalls either the /etc/init.d/inn or the /etc/init.d/inn2
startup scripts for you.

That could be a bug, but if you read the script chances are that is is a
non-function. "dpkg --purge inn" should purge them (different than remove).

Post by Dave Laird
2. Some, not all, the binaries in /usr/lib/inn/bin, get changed out if you
try to change versions. As a result, a *key* binary, ctlinnd, gets caught
in the middle, with /sbin/ctlinnd being installed for the small version
and /usr/lib/news/bin/ctlinnd being installed for the main version of INN.
Ditto goes for the startinnd binaries. This is not a good thing, folks.

I kinda doubt that you have two ctlinnd's installed, did you panic and
abort something midstream?

Post by Dave Laird
3. It took *four* times of uninstalling and then re-installing INN before
it finally decided I *wanted* /etc/init.d/inn2, and then it totally
trashed the news history file, necessitating another frustrating 30 minute
wait while the history database was rebuilt from scratch.

All that is stated in the README.Debian.gz ..

INN 2.X is substantially different in terms of configuration file contents
and filesystem layout than previous versions. The Debian INN package installs
a minimal but functional local-only server configuration. Configuring feeds
to/from other servers, and many other details, is up to you.

and before you even get that far, it says this in the description of inn:

This is INN version 1.x, provided for smaller sites which do not need the
complexity of INN 2.x. Large sites should use Debian's inn2 package
instead.

It would be best if you purged both, deleted the news spool, and installed
inn2. They are incompatible.

apt-get remove --purge inn inn2
apt-get install inn2


--

[Dave Laird]

Good morning, James...

Do you know how many YEARS I have held my Masters Degree in all-nighters?
8)

Post by James Vahn

Post by Dave Laird
1. It never uninstalls either the /etc/init.d/inn or the /etc/init.d/inn2
startup scripts for you.

That could be a bug, but if you read the script chances are that is is a
non-function. "dpkg --purge inn" should purge them (different than remove).

I did that. In fact, running apt-get and dpkg is almost second nature to
me now, which is about how far I have progressed with Debian. Other than
it has five bazillion more applications than any distro I've seen, this is
very much Linux, quite similar to RedHat and perhaps the easiest to
install of all the distros I've examined in two weeks.

Post by James Vahn

Post by Dave Laird
2. Some, not all, the binaries in /usr/lib/inn/bin, get changed out if
you try to change versions. As a result, a *key* binary, ctlinnd, gets
caught in the middle, with /sbin/ctlinnd being installed for the small
version and /usr/lib/news/bin/ctlinnd being installed for the main
version of INN. Ditto goes for the startinnd binaries. This is not a good
thing, folks.

I kinda doubt that you have two ctlinnd's installed, did you panic and
abort something midstream?

No, but I did forget to dpkg toward the end. Hell, I'm *entitled* to screw
up at age 59 after an all-nighter, am I not? However, the install script
should have detected the previous version and done it for me in a perfect
world. 8-)

Post by James Vahn
It would be best if you purged both, deleted the news spool, and installed
inn2. They are incompatible.
apt-get remove --purge inn inn2
apt-get install inn2

That is where I completed my work, at six fifteen this morning, and lay my
head down on the back of my chair. Behold, I give you a news server, and
it took less than four hours to spool. It is Debian Woody, and as such,
updated itself for nearly an hour before it announced I had a
fully-patched Debian box ready for work. I'm going to let it run over the
weekend and see where it goes from there, but I still have two more
distributions to test.

However, I do now know a means to migrate my primary news spool to the
latest version of INN. It will require, unfortunately, that I tear down my
working server, at some point, or else build a second server and THEN
migrate over. That is unfortunate.

However, the packaging system in Debian makes it shine like a star,
because you can upgrade quickly, almost too quickly, because you can
inadvertently make mistakes. You just have to watch your versions of
applications you are installing because Debian doesn't do it for you
necessarily, and learn the lesson to *never* run either testing or
unsecure releases on production boxes, but you also told me that.

However, what you didn't tell me was that I could essentially tear a box
completely down, zero the drive and install a working news-and-mail server
from scratch in a little under four hours, start to finish, including the
importation and configuration of a 10 gig news spool. Once I learned the
trick of installing Sendmail the old-fashioned way using Debian's new
methodology, building a mail server took a little less than ten minutes,
no make that fifteen, because I added TLS and the encryption stuff.

Score major points to Debian as a server. I'll have to decide another time
whether it will be my next default workstation, because I've still got to
solve how to upgrade a running production server. Time and energy
constraints, unfortunately, will not allow me to build it under Debian
because Debian and RedHat are so different in so many ways.

Oh, and I forgot to mention, in the middle of the night I took out an old
beater of a box, a dual Pentium single-stage, that in its day was a power
house of a server for Kharma. I installed one gig of memory and installed
the high-memory SMP kernel from Debian Woody for about ten minutes, and
ran some analysis tools to see how it compared to my client's dual Zeon in
the colo room downtown. Whoa dude! The Red Hat memory leak, which is by
now well-described and documented, is GONE. This important little snippet
of information is absolutely priceless, because it fixes a rather unusual
load restriction in Red Hat 8.0 and 9.0 that no amount of kernel patching
has cured.

However, at a terrabyte of disk space downtown, there isn't a way to
migrate the Zeon over to Debian, either. But I *have* seen a Debian box
inside another ISP's colo room that runs dual Athlons with four gig of
memory and *NO* memory management problems whatsoever in two years uptime.

Sooooooo, having said all this, I'm going to give Woody a really hard
workout this weekend. I've still got to test Samba and Cups and since
Woody somehow has the latest version of IPTables, I'll probably test my
firewall scripts while I'm at it. I also want to look once again at how
Debian handles its init scripts, because they are so much different than
anything else *anyone* in a RedHat format currently do.

At some point, then we move onto CentOS-386 because I inadvertently forgot
to test that version after testing CentOS-686.

After that, I'll be testing the Apple-compatible from each distribution on
a working Apple box I'm going to borrow from a client, and then I will do
my first attempt at running KDE running on an Apple frame. That should be
interesting. There's a fair amount riding on the deal because the client
really *WANTS* to eliminate OS/X from his desktop in favor of FreeBSD
running KDE. That's his request, mind you. He called me with the idea, not
the other way around. ;-)

So, it's another wonderful day in the kitty litter box. You have a good
day, too. 8-)

Dave

[James Vahn]

Post by Dave Laird
That is where I completed my work, at six fifteen this morning, and lay my
head down on the back of my chair. Behold, I give you a news server, and
it took less than four hours to spool. It is Debian Woody, and as such,
updated itself for nearly an hour before it announced I had a
fully-patched Debian box ready for work.

I think the choice of inn or inn2 also existed in Woody.

It brings up a point. As far as the packaging system goes, inn and inn2 are
two separate entities that conflict. You can upgrade inn, and you can
upgrade inn2, but there is no upgrade path from inn -> inn2. I think the
same situation exists for bind and bind9.


--

[Dave Laird]

Good evening, James...

Say, don't I know you from somewhere? You sound vaguely familiar... 8-)

Post by James Vahn
I think the choice of inn or inn2 also existed in Woody.

It does, it does! However, once burned twice shy, as they say, so I didn't
repeat my mistake of the first time out of the box.

Post by James Vahn
It brings up a point. As far as the packaging system goes, inn and inn2
are two separate entities that conflict. You can upgrade inn, and you can
upgrade inn2, but there is no upgrade path from inn -> inn2. I think the
same situation exists for bind and bind9.

What is equally interesting for those purists who might be listening in,
the latest version of INN according to Debian is 2.32.xx, but the latest
according to isc.org is 2.4.1. You might think that is bad until you
discover that both Mandrake and Red Hat are running 2.23 as the latest
stable version of INN, which has a number of vulnerabilities. (When did
INN ever *NOT* have vulnerabilities?)

Likewise, the only version of Bind that isc.org recommends anyone use is
Bind 9.3.0, and Debian isn't that far behind the developer of Bind with
their version, but once again, Red Hat and Mandrake both are half a
version behind the curve.

So, once again, there is something to be said about Debian's package
distribution system, as it seems to have key packages ready for users long
before the competition.

Dave
--
Dave Laird (***@kharma.net)
The Used Kharma Lot
Web Page: http://www.kharma.net updated 11/24/2004
Usenet news server : news://news.kharma.net

Fortune Random Thought For the Minute
"A raccoon tangled with a 23,000 volt line today. The results blacked
out 1400 homes and, of course, one raccoon."
-- Steel City News

[James Vahn]

Post by Dave Laird
What is equally interesting for those purists who might be listening in,
the latest version of INN according to Debian is 2.32.xx, but the latest
according to isc.org is 2.4.1.

They don't put new software in Woody, that's why it's called "stable".
The latest version of INN according to Debian is 2.4.2

*** 2.4.2-1 0
500 http://ftp.us.debian.org testing/main Packages
50 http://ftp.us.debian.org unstable/main Packages


--

[Dave Laird]

Good morning, James!

Post by James Vahn
They don't put new software in Woody, that's why it's called "stable".
The latest version of INN according to Debian is 2.4.2
*** 2.4.2-1 0
500 http://ftp.us.debian.org testing/main Packages
50 http://ftp.us.debian.org unstable/main Packages

I also did another no-no last night, just to see how it would work,
especially since I'll be dusting this server sometime later this weekend
as the testing continues. I removed and flushed the current Debian version
of sendmail from the test box and downloaded the latest version from
sendmail.org and compiled it from source. In particular, what I was
looking for was the STARTTLS bug I'd seen in nearly every new version of
Sendmail I've tested thus far.

After the usual S&S (swearing and sweating) I managed to get it compiled
correctly, and then read the documentation. I should have known, in fact,
if in my rush to test one more feature, I should have read the web site,
because then I would have known there was a fixed bug in STARTTLS. You may
slap me around the head.

Other than the pedantic crap Sendmail does with the connections
themselves, which are not present in the default Debian configuration for
some reason, I couldnt' tell much difference between the .DEB file and
compiled-from-source software. I tried a couple of different settings for
STARTTLS and the handshake, but I couldn't really do too much with it
because the test box is not listed in the DNS, among other things.

I was going to test Postfix2, because I've heard such rave reviews about
it, but I'm out of time. <sigh>

Dave
--
Dave Laird (***@kharma.net)
The Used Kharma Lot
Web Page: http://www.kharma.net updated 11/24/2004
Usenet news server : news://news.kharma.net

Fortune Random Thought For the Minute
It is indeed desirable to be well descended, but the glory belongs to
our ancestors.
-- Plutarch

[James Vahn]

Post by Dave Laird

Post by James Vahn
The latest version of INN according to Debian is 2.4.2

Did you miss that? This is newer than isc.org says - apparently ISC
hasn't updated their web site yet. :-)

Post by Dave Laird
sendmail.org and compiled it from source. In particular, what I was
looking for was the STARTTLS bug I'd seen in nearly every new version of
Sendmail I've tested thus far.

Read the changelogs. The Woody upgrades largely consist of backported fixes,
which isn't clear if you judge simply by the version numbers.

Post by Dave Laird
some reason, I couldnt' tell much difference between the .DEB file and
compiled-from-source software. I tried a couple of different settings for

You might find it easier (sometimes) to look at their diffs. A Debian source
package comes in three parts: a control file, the ORIGINAL author's source,
and a diff.



--