Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!ncoast!allbery From: allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) Newsgroups: comp.unix.sysv386 Subject: Re: '386 Unix Wars Message-ID: <1991Jan4.032920.13524@NCoast.ORG> Date: 4 Jan 91 03:29:20 GMT References: <1990Dec31.100329.23178@kithrup.COM> <1991Jan1.025724.25700@NCoast.ORG> <188@raysnec.UUCP> Reply-To: allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) Followup-To: comp.unix.sysv386 Organization: North Coast Computer Resources (ncoast) Lines: 68 As quoted from <188@raysnec.UUCP> by shwake@raysnec.UUCP (Ray Shwake): +--------------- | allbery@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@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