2: problem building NIS mail for mail.aliases
I got more responses to my Summary than to my original problem posting, so
I thought I'd pass those along. The consensus is that the version of
Berkeley sendmail I am running (5.65) does not include a `local order number'
when it rebuilds the alias database during a ypmake for mail.aliases. The
absence of this data item is then noticed by yppush when it tries to push
the map. Responses are attached.
Thanks to the second wave of responders:
bill@Access.COM (Bill Hunter)
ndd@sunbar.mc.duke.edu (Ned Danieley)
strombrg@hydra.acs.uci.edu (Dan Stromberg)
sls@cs.duke.edu (Shelley Shostak)
art@infinity.com (Art Hebert)
David Way McDonald Observatory/Astronomy Dept.- Univ. of Texas, Austin
(office) RLM 16.206 (voice) 471-7439 (internet)dpw@astro.as.utexas.edu
-->Frombill@Access.COM Tue Dec 14 08:44:20 1993
Posted-Date: Tue, 14 Dec 1993 07:45:47 -0700
this is from sun's database.
SRDB ID : 6046
SYNOPSIS : ypwhich -m returns NIS database error using mail.aliases
DETAIL DESCRIPTION :
The mail.aliases map is only map which does not report success upon make.
This is on the NIS master.
Error messages during make are:
# touch /etc/aliases
# make
81 aliases, longest (sunflash) 203 bytes, 3655 bytes total
updated aliases
Can't bind master to send ypclear message to ypserv for map mail.aliases.
Status received from ypxfr on shape:
Failed - no local order number in map - use -f flag to ypxfr.
When this happens, ypwhich -m on NIS master produces error message for
only the mail.aliases map. All other maps report "servername map."
ypwhich: Can't find the master of mail.aliases. Reason: NIS map data base
is bad
SOLUTION SUMMARY :
This problem was caused by a public domain version of sendmail.mx (5.65b).
It corrupted the mail.aliases map.
Back out the public domain sendmail.mx and use Sun's sendmail.mx.
mv /usr/lib/sendmail /usr/lib/sendmail.bogus
cp /usr/lib/sendmail.mx /usr/lib/sendmail
The public domain sendmail might have been confused by problems
pwck found in the passwd file.
KEYWORDS : ypwhich -m, NIS database error, mail.aliases
PRODUCT : NIS
SUNOS RELEASE : 4.1.1
UNBUNDLED RELEASE : n/a
HARDWARE RELEASE : All
ISO-9001 STATUS : Uncontrolled
_________________________________________________________________
Bill Hunter Access Graphics "..and the torture never stops"
bill@access.com Sun Instructor -frank zappa
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-->Fromndd@sunbar.mc.duke.edu Tue Dec 14 09:25:46 1993
Posted-Date: Tue, 14 Dec 1993 10:25:31 -0500
[replayed text deleted]
I think the problem lies in the fact that you're using Berkeley sendmail.
seems like Sun did something to their version of sendmail that produces
the 'local order number'. this happened to me when I installed 5.65, I
think. the fix that I used was to edit /var/yp/Makefile and change the
aliases.time entry to use sun's sendmail:
aliases.time: $(ALIASES)
@cp $(ALIASES) $(YPDBDIR)/$(DOM)/mail.aliases;
@/usr/lib/sendmail.mx -bi -oA$(YPDBDIR)/$(DOM)/mail.aliases;
...
that fixed it for me. interestingly, the lastest version (8.6.4) doesn't
seem to need that change.
--
Ned Danieley (ndd@sunbar.mc.duke.edu)
Basic Arrhythmia Laboratory
Box 3140, Duke University Medical Center
Durham, NC 27710 (919) 660-5111 or 660-5100
-->Fromstrombrg@hydra.acs.uci.edu Tue Dec 14 10:17:20 1993
Posted-Date: Tue, 14 Dec 1993 08:15:59 -0800
-ypsetme is safer than -ypset. I use -ypsetme now and then,
particularly when an NIS master insists on binding to a slave (argh!).
I've experienced no negative side-effects from this, aside from the
obvious: if someone configures another host with the servers IP
address, they might be able to impersonate the server and snag a copy
of the password file. This would probably be noticed, since the
router would likely get confused, and our passwords aren't shadowed
anyway.
You might also add "-v" to the yppush definition in your NIS Makefile.
Finally, if you get really stuck, and have some time to put into this
(and this'd be something of an act of activism), you port one of the
freely redistributable NIS clones to SunOS, so you can really see
what's going on inside the NIS subsystem. Binary-only distributions
are, relatively speaking, a black hole from which debugging forays are
hard pressed to escape.
[replayed text deleted]
Dan Stromberg - OAC/DCS strombrg@uci.edu
>Fromsls@cs.duke.edu Tue Dec 14 11:27:45 1993
Posted-Date: Tue, 14 Dec 93 12:27:31 -0500
[replayed text deleted]
Gee, I remember seeing this kind of problem when I upgraded all of our hosts
to 4.1.3. I don't remember what the answer was, but it definitely not a
sendmail problem. I don't remember how I fixed it (GGGGRRRRR), but it took
a few days to get things straightened out. I think that it in fact was a yp
problem. Although I don't remember the solution, I'll take a stab at things
to look for, which I remember doing, but don't remember if they worked.
Make sure you don't have any other hosts running ypserv. Make sure that the
ypslaves map (whatever you call yours) contains the correct information. If
I remember correctly the problem is that the slaves contain incorrect
information which cannot be updated because of this problem. If you remove
all of the maps on the slaves and then send out new ones, that may work.
Good luck, and please post of you figure out what the problem is. It will
drive me nuts that I forgot what the solution was!!
Shelley
--
Shelley L. Shostak (919) 660-2565
Senior Systems Programmer sls@phy.duke.edu
Physics Dept.
Box 90305
Duke University Durham, N.C. 27708-0305
-->Fromart@infinity.com Tue Dec 14 11:58:55 1993
Posted-Date: Tue, 14 Dec 93 07:47:19 PST
I had the same problem, my sendmail.cf had
Dwifinity.com
So I put infinity.com in my hosts table as an alias to the mailhost
Everything fine afterwards.
art hebert
