Sun Managers,
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
-- >From bill@Access.COM Tue Dec 14 08:44:20 1993 Posted-Date: Tue, 14 Dec 1993 07:45:47 -0700this 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- >From ndd@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 -- >From strombrg@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
>From sls@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 -- >From art@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
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:34 CDT