Sacred cows of Linux--two of...

[Dave Laird]

Good morning, everyone...

There are sacred cows in Linux, just as there are in Windows software
design and deployment. One of Linux's most sacred cows, based upon my
experience, is that of *permissions*; another are the directories where
binaries and configuration files (/etc) are generally to be found. Among
those I have seen over the last few weeks of testing various Linices
(unapproved as yet by the Bob-a-do) is that the old reliable "standard" by
which Linux expects certain applications to run have fallen by the
wayside, although some of the old directories stand.

I've known for well over a year that Mandrake breaks a lot of the old
standard directory locations, but until this last week, I hadn't truly
examined Debian well enough to consider that possibility. I have since
rectified my error, as there are many changes that Debian brings to the
fore, some of which are merely logical outcome of a distribution growing.
Part of this, as I have just seen, is simply because I am not running the
latest *stable* version of Debian, but Sarge, which is still listed as
unstable. Since, before I updated to Sarge, I made a disk image of the
Woody file system, I was able to examine some of the changes that took
place during the upgrade to Sarge.

One of the sacred cows of Debian just rose to bite me in the butt,
although it was strictly my own fault, because I *knew* from the git-go
that the directory tree would be vastly different than anything I had
seen, thus far, because it was my first *non-RPM* file system. Everything
I have used, for nearly a decade, has either been built following the
official Bob-a-Do rules, from source OR from an RPM-based distribution,
such as Mandrake or Red Hat. I also learned a brittle lesson about Debian,
just now.

If you want to run a full-blown news server you *still* need to download
the source, compile it using the latest-and-greatest compiler, and install
it in the appropriate directories. You *can* run INN beneath Debian using
the default .deb files, but all you have to do is lift the hood and peer
at the wires and cables, and you'll see there are things missing and/or
replaced. Everything that is missing is "hard-wired" into the binaries,
the INN Libs and the INN-Vars. That *isn't* the way INN is built from
source, not even in Red Hat. It's different. It's not necessarily a bad
thing, mind you, and I'm not even certain it is a sacred cow, because
there are lots of admins who won't even let INN run on their precious
servers.

Since I am being somewhat pedantic about this all, I also am aware I can
put the source to INN in /usr/local, which is NOT affected by any of
Debian's .deb constraints, compile it there, build the links to the
various binaries myself, and PRESTO! I have a full-blown INN server.

I have seen the same things where Debian Sendmail is concerned. Since I
didn't run Sendmail under Debian Woody, I cannot tell how Sendmail ran
there, but having downloaded and installed the *REAL* Sendmail from source
within the last week, I *know* what I am seeing in Debian is Sendmail,
perhaps on training wheels, perhaps not.

There are two sacred cowbowzen of Linux, and both have changed beneath
Debian. Should I simply remove both from my test Debian system and put
them both in /usr/local to be compiled from source? Jump in! The water's
fine!

Dave

[James Vahn]

Post by Dave Laird
Part of this, as I have just seen, is simply because I am not running the
latest *stable* version of Debian, but Sarge, which is still listed as
unstable.

Sarge is supposed to become "stable" Real-Soon-Now. Next month? "stable" is
almost two years old (woody). "unstable" is current, "testing" follows it in
a couple/few weeks. At the moment, Sarge is in "testing" but not yet
"frozen". Frozen means no new software, only bugfixes. After activity quiets
down, it will be released as "stable" and the next version will begin.
In the meantime, you are expected to update your Sarge system often.

The offical advice is to run "stable" on servers (security updates only),
and "testing" or "unstable" on the GUI desktop.

Post by Dave Laird
the INN Libs and the INN-Vars. That *isn't* the way INN is built from
source, not even in Red Hat. It's different. It's not necessarily a bad
thing, mind you, and I'm not even certain it is a sacred cow, because
there are lots of admins who won't even let INN run on their precious
servers.

I have to wonder then at why they would go through the trouble other than to
meet a self-imposed requirement. They're pretty fussy about things, their
rules and all. Marco d'Itri is the maintainer. He'd be the one to ask.

Post by Dave Laird
Since I am being somewhat pedantic about this all, I also am aware I can
put the source to INN in /usr/local, which is NOT affected by any of
Debian's .deb constraints, compile it there, build the links to the
various binaries myself, and PRESTO! I have a full-blown INN server.

...and totally out of the package management loop. Or waiting to become
a victim of it. Better might be to "apt-get source" it, make those ODD
changes of yours (they're odd, admit it ;-), install the resulting .deb and
put it on *hold*. In that way you'll continue to be in line for various
updates but anything harmful will cause apt-get to complain first.

Post by Dave Laird
I have seen the same things where Debian Sendmail is concerned. Since I
didn't run Sendmail under Debian Woody, I cannot tell how Sendmail ran
there, but having downloaded and installed the *REAL* Sendmail from source
within the last week, I *know* what I am seeing in Debian is Sendmail,
perhaps on training wheels, perhaps not.

"sendmailconfig" was written by a Man from Mars (.org) for Woody(?),
prior to that we used m4.


--

[Dave Laird]

Good morning, James, everyone...

I am somewhat surprised at the sudden upswing in the number of local
people reading this newsgroup. I guess we're not alone in the slightest.
;-)

Post by James Vahn
Sarge is supposed to become "stable" Real-Soon-Now. Next month? "stable"
is almost two years old (woody). "unstable" is current, "testing" follows
it in a couple/few weeks. At the moment, Sarge is in "testing" but not yet
"frozen". Frozen means no new software, only bugfixes. After activity
quiets down, it will be released as "stable" and the next version will
begin. In the meantime, you are expected to update your Sarge system
often.
The offical advice is to run "stable" on servers (security updates only),
and "testing" or "unstable" on the GUI desktop.

Since this box is, for the moment, 100% a test-only system, and locked
from public access/use, and since I am monitoring its activities closer
than any server I control, it gets updated twice daily via cron, with the
verbose switch turned on so I can see the package(s) being updated in the
log. My comfort level regarding this is pretty high. In the cron script
the log file is then sent via e-mail to me, and then overwritten the next
time it runs.

Post by James Vahn

Post by Dave Laird
Since I am being somewhat pedantic about this all, I also am aware I can
put the source to INN in /usr/local, which is NOT affected by any of
Debian's .deb constraints, compile it there, build the links to the
various binaries myself, and PRESTO! I have a full-blown INN server.

...and totally out of the package management loop. Or waiting to become
a victim of it. Better might be to "apt-get source" it, make those ODD
changes of yours (they're odd, admit it ;-), install the resulting .deb
and put it on *hold*. In that way you'll continue to be in line for
various updates but anything harmful will cause apt-get to complain first.

<huge grin> No, the changes are not odd. What I *was* trying to do was get
the same levels of flexibility given to me in the /etc/news directory as
the compiled-from-source version. An example is the default inn.conf file
from Debian consists of four actual (less comments) lines; the default
from the INN source is twenty-five. What are these "missing lines" you
might ask? A *lot* of the stuff controls the peering connections,
cybercancels (handled in control.* now) and the various PATH statements
that INN likes, such as the location of the spool. (In Debian those are
now handled ONLY by the INNVARS file (/usr/lib/news/innshellvars, in the
INN source it is still handled by inn.conf).

For example, the ability to set the news spool location appearing in
/var/spool/news, instead of appearing in /var/spool/news/articles (the INN
default) does not appear in inn.conf, but in innshellvars, and any
attempts to change the setting in inn.conf established by the shell
variables at load time simply falls on deaf ears. However, if you change
the shellvars and restart the server, you essentially accomplish the same
goals as if you had edited inn.conf in the compiled-from-source INN.

[Application] During the course of eight years running INN I have had to
change the spool location three or four times, usually because I bought a
new hard disk for the spool. In each case, I simply mounted
/var/spool/news on the new drive by altering inn.conf, and move the spool
to the appropriate place, reload using ctlinnd and we're off to the races.
In the Debian view of things, I alter the /usr/lib/news/innshellvars to
match my new settings and reboot the news server. There's not a LOT of
difference between running INN-from-source and Debian, there, but some.

Another *important* alteration is under INN-from-source, I have pinpoint
control of the peering connections, themselves. Tinkering with and
refining those settings is one of the secrets to allowing peering
connections over DSL without packet-flooding my entire network or pissing
off the folks at Cutting Edge. ;-) Under Debian, those controls are no
longer in /etc/news/inn.conf, and I haven't gotten to that point yet in
discovering *that* fine-tuning.

Another, one that I also have used to good effect, is the ability to set
the type of spool (tradspool,timehash, etc) storage method. This is set,
by default, in /etc/news/storage.conf, a file which does not exist in the
Debian /etc/news directory, although tradspool does appear to be the
default setting. Again, the only reason I would be interested in using
/etc/news/storage.conf is a lack of storage space. Expire.ctl handles when
it expires, but storage.conf sets the storage method, and judicious
fine-tuning can save disk space.

So you see, there are some considerable deviations from the standard
plain-jane INN as compiled from source. I made a real mess of things
yesterday compiling from source and running the default server for awhile,
and then switching back to Debian's version. Still, overall, I think
you're quite right in urging me to stick with the Debian packaging,
although I am still a bit worried about being able to control the peering
connections.

Post by James Vahn

Post by Dave Laird
I have seen the same things where Debian Sendmail is concerned. Since I
didn't run Sendmail under Debian Woody, I cannot tell how Sendmail ran
there, but having downloaded and installed the *REAL* Sendmail from
source within the last week, I *know* what I am seeing in Debian is
Sendmail, perhaps on training wheels, perhaps not.

"sendmailconfig" was written by a Man from Mars (.org) for Woody(?),
prior to that we used m4.

<evil grin> I tried the "old-fashioned" way of using m4 and a hand-built
.mc file, and it still works. However, if you run sendmailconfig it carps
a lot about things, but it works, nonetheless. I particularly like the
fact it rebuilds the .mc file for you and then restarts the mail server.
Not bad, not bad at all. 8-)

Dave

[James Vahn]

Post by Dave Laird
Since this box is, for the moment, 100% a test-only system, and locked
from public access/use, and since I am monitoring its activities closer
than any server I control, it gets updated twice daily via cron, with the
verbose switch turned on so I can see the package(s) being updated in the
log. My comfort level regarding this is pretty high. In the cron script
the log file is then sent via e-mail to me, and then overwritten the next
time it runs.

"apt-get update ; apt-get dist-upgrade -y" in cron? Someday you'll break
something doing that. I use the "download-only" mode because my modem is
slow, dist-upgrade those downloaded packages later, when I have time.

One annoying thing about APT... If even one package is updated on the
ftp servers, the entire Packages.gz file must be downloaded again. They talk
about an rsync version but I don't think anything ever materialized.

Post by Dave Laird
<......>
the compiled-from-source version. An example is the default inn.conf file
from Debian consists of four actual (less comments) lines; the default

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yup, I'm sure of it now. "apt-get install inn2"
They say inn (v1.7.2) is for smaller systems and inn2 (v2.4.2) for larger.

Good luck with that upgrade, didn't go so smooth for me but maybe things
have improved since then.

Post by Dave Laird

Post by James Vahn
"sendmailconfig" was written by a Man from Mars (.org) for Woody(?),
prior to that we used m4.

<evil grin> I tried the "old-fashioned" way of using m4 and a hand-built
.mc file, and it still works. However, if you run sendmailconfig it carps
a lot about things, but it works, nonetheless. I particularly like the
fact it rebuilds the .mc file for you and then restarts the mail server.
Not bad, not bad at all. 8-)

What's it carping about? Trying to foister the ttls and sasl stuff on
you? I got tired of its complaining and did what it suggested to do.
Don't forget to try FEATURE(greet_pause, 10000)dnl in there, too.


--

[Dave Laird]

Good evening, James...

Post by James Vahn
"apt-get update ; apt-get dist-upgrade -y" in cron? Someday you'll break
something doing that. I use the "download-only" mode because my modem is
slow, dist-upgrade those downloaded packages later, when I have time.
One annoying thing about APT... If even one package is updated on the
ftp servers, the entire Packages.gz file must be downloaded again. They
talk about an rsync version but I don't think anything ever materialized.

HARUMPH!

Post by James Vahn

Post by Dave Laird
<......>
the compiled-from-source version. An example is the default inn.conf file
from Debian consists of four actual (less comments) lines; the default

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yup, I'm sure of it now. "apt-get install inn2"
They say inn (v1.7.2) is for smaller systems and inn2 (v2.4.2) for larger.
Good luck with that upgrade, didn't go so smooth for me but maybe things
have improved since then.

It bombed for me, too. However, I'm in the process of rebuilding. What the
heck is inn, if inn2 is the "real" inn? At least now I know why the first
(inn) news server didn't act like it *knew* what a peering news feed was
about, because it probably didn't. The second (inn2) looks like a lot more
familiar territory, as all the .conf and .cnf files are in place, the
spool looks normal and the startup sounds familiar enough.

HOWEVER, it looks right now like I'll have to delete *both* versions and
install the inn2 clean in order to make things work at all. It's time to
kill KDE entirely and see where I go from there, because inn2 also has
some memory management issues, too. It might be a long evening...

Post by James Vahn
What's it carping about? Trying to foister the ttls and sasl stuff on
you? I got tired of its complaining and did what it suggested to do.
Don't forget to try FEATURE(greet_pause, 10000)dnl in there, too.

Hehehe. I installed openssl, set up ttls and sasl and it finally stopped
carping.

Dave

[James Vahn]

Post by Dave Laird
It bombed for me, too. However, I'm in the process of rebuilding. What the
heck is inn, if inn2 is the "real" inn?

When INN 2.x first came out, we were all using INN 1.x and they were telling
us to bite the bullet and upgrade NOW. A lot of people must've balked,
because Debian has kept INN 1.x around. I would not have updated, knowing
that. Now they are saying INN 1.x is for "smaller systems". Funny, because
it ran some pretty large news servers back in its day. Anyway, you have a
choice now.


--