'386 Unix Wars

[Brandon S. Allbery KB8JRR]

As quoted from <188 at raysnec.UUCP> by shwake at raysnec.UUCP (Ray Shwake):
+---------------
| allbery at NCoast.ORG (Brandon S. Allbery KB8JRR) writes:
| 
| >MMDF is one of the things SCO did right.  I plan to bring it up on a number of
| >other systems --- it beats sendmail all hollow for ease of maintenance.  And
| >the fact that it can handle a pathalias file by itself is nice, too.
| 
| 	Consider yourself one of the lucky ones. I've had a few frustrating
| years working with earlier and more recent versions of the package, and 
+---------------

Let me correct that:  one of the first things I did was replace SCO's MMDF
with the distribution from louie.udel.edu, which was more recent.  It also got
me full documentation.

My experience is that MMDF is quite robust when treated correctly.  It *can*
be thrown out of whack by incorrect permissions... but that's what
/usr/mmdf/checkup (/usr/mmdf/bin/checkup under SCO UNIX) and /usr/mmdf/setup
(also in bin/ under SCO) are for.  Checkup gives reports and can fix things on
the fly; setup fixes up more things than checkup does, and is intended for
fixing up new installations.  Run setup after making major changes to
mmdftailor and checkup weekly, is my suggestion.  (And show me a tool for
sendmail that makes sure things will work!)

+---------------
| more reliable the box became. The last straw came one morning when I found
| 104 undelivered messages in the spool directory, but all the tools indicated
| an empty queue. I'll certainly check out the next version when ODT 1.1 comes
+---------------

I had this happen to me once as well... but when I ran checkque as root
instead of mmdf, I saw stuff in the queue.  Red flag... I immediately ran
checkup and it straightened out permissions for me.  And pointed out the only
bug I've found in MMDFIIb #43 to date:  you can't change the lock directory in
mmdftailor, it gets misread.  Since I've got the source, if it annoys me
enough I'll track it down and fix it.

+---------------
| 	As to pathaliasing, we found no way to use the existing paths file;
| rather we had to create an mmdf-specific variant of same. Given a 1 MB paths
| file, the variant came to more than 2 MB. We junked it.
+---------------

You have to build the MMDF database (using dbm) with it, which gets large.
But you'd be crazy not to use the dbm paths databases that smail and
sendmail+IDA use, and those get big as well.  Perhaps release #32 didn't use
the same format, but #43 looks an awful lot like the stuff I feed smail on our
SVR3.1 box....

MMDFIIb #32 was, admittedly, a mistake.  (And I'm told that SCO has put the
finishing touches on their own port of #43.  I hope they found and fixed the
bug with the lock directory.)  But MMDF itself is much easier to babysit than
sendmail, which I've been trying to maintain on ncoast for a few years.  That
SCO went with MMDF instead of sendmail is what I find commendable --- they
broke with what everyone else did (as usual) but there is a net gain in this
case because sendmail is widely known to be a pain in the *ss to maintain.
(Mind you, there are sendmail gurus out there who can read a sendmail.cf as if
it were English.  G*d alone knows how....)  And it's one h*ll of a lot better
than the "execmail" nonsense under Xenix (a poor, unconfigurable sendmail
clone).

++Brandon
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery at NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY