Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Sep 1996 11:55:49 -0400 (EDT)
From:      Bill Paul <wpaul@skynet.ctr.columbia.edu>
To:        ccote@gandalf.ec.camitel.com (Claude Cote)
Cc:        current@freebsd.org
Subject:   Re: Re: Problems with mail-aliasing using NIS
Message-ID:  <199609291556.LAA10103@omnivax>
In-Reply-To: <199609290624.CAA06931@gandalf.ec.camitel.com> from "Claude Cote" at Sep 29, 96 02:24:27 am

next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Claude Cote had 
to walk into mine and say:

 
> Hi Bill,
> 
> I'm very grateful for your help. Sorry for my bad English... it
> sometimes makes me write things I don't really mean %-} So this time,
> I'll try to make things a little more explicit.

[chop]
 
> > You don't need to reboot, just restart sendmail. This isn't Windoze,
> > you know.
> 
> Hopefully!
> 
> I used to send signals, but since nothing was working, I decided to
> reboot (to be sure that no esoteric forces was taking over the
> machine ;-)

Sendmail doesn't re-read /etc/sendmail.cf on a SIGHUP (when running in
daemon mode); you actually have to kill -TERM it and restart it.

[chop]
 
> Oops! Here's the output of ypcat -k mail.aliases:
> 
> ingres root
> @ @
> bin root
> postmaster root
> webmaster root
> mailer-daemon postmaster
> nobody root
> daemon root
> toor root
> games root
> system root
> uucp root
> toto ccote

Hm, okay: this looks correct. Since the map is formatted correctly and
you can read it on the clients, I'm inclined to think the problem isn't
stictly with NIS.
 
> >> BTW, the NIS master server is running -current of last Monday (23 sep)
> >> and the clients are running 2.2-960801-SNAP. All the others NIS databases
> >> (passwd, group, hosts, ...) are working just fine.
> >
> > You must have compiled -current yourself: check that the latest
> > /var/yp/Makefile was installed (it's in the source tree as
> 
> I make a diff and it's the good one.

Ok.

[chop]

> Cut from /usr/src/usr.sbin/sendmail/RELEASE_NOTES:
> 
>         Check for @:@ entry in NIS maps before starting up to avoid  
>                 (but not prevent, sigh) race conditions.  This ought to
>         ...
>         Fix a problem that caused aliaswait to go into infinite recursion
>                 if the @:@ metasymbol wasn't found in the alias file.

Hunh. Never saw that one before. But then I don't use NIS for the
aliases database on my system.
 
> Here's the output of the above commands:
> 
> NIS Map update started on Sun Sep 29 01:29:22 EDT 1996 for domain gandalf
> Updating mail.aliases...
> /etc/aliases: 12 aliases, longest 10 bytes, 131 bytes total
> Pushed mail.aliases map.
> NIS Map update completed.

Hm... do you actually have an NIS slave server running? Normally, you
should only see the 'Pushed %s map' message if you comment out the
'NOPUSH=True' line to enable propagation of maps to slave servers.

One possibility here is that you do have a slave server, and the client
is bound to it, but your map updates aren't being propagated to the
slave properly. If you really do have slaves, did you remember to add
them to the /var/yp/ypservers file?
 
> Maybe something is missing on the client side? I will keep on working...

I think it is something on the client. Like I said, if you have a
slave server, and you aren't pushing map updates to it correctly, that
could hose the client.

Also, did you check that you enable NIS access to the mail.aliases
map in the client's /etc/sendmail.cf file? Did you restart sendmail
on the client machines as well as the server after you added NIS
support to the config file? Can you confirm that sendmail on the client 
was really built with NIS map support? If you copy the sendmail binary 
from the server onto the clients, does that work? If you do

% sendmail -bt
> 3,0 toto

does it resolve the alias correctly? If you can do

% ypmatch toto mail.aliases

and that works, but sendmail can't resolve the alias when you run it
in test mode, then it could be your sendmail configuration.

-Bill

-- 
=============================================================================
-Bill Paul            (212) 854-6020 | System Manager, Master of Unix-Fu
Work:         wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home:  wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
 "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you."
=============================================================================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609291556.LAA10103>