From owner-freebsd-current Sun Sep 29 09:07:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA12836 for current-outgoing; Sun, 29 Sep 1996 09:07:10 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA12820 for ; Sun, 29 Sep 1996 09:07:08 -0700 (PDT) Received: from omnivax (skynet.ctr.columbia.edu [128.59.64.70]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA17852 for ; Sun, 29 Sep 1996 09:07:01 -0700 (PDT) Received: (from wpaul@localhost) by omnivax (8.6.12/8.6.9) id LAA10103; Sun, 29 Sep 1996 11:56:24 -0400 From: Bill Paul Message-Id: <199609291556.LAA10103@omnivax> Subject: Re: Re: Problems with mail-aliasing using NIS To: ccote@gandalf.ec.camitel.com (Claude Cote) Date: Sun, 29 Sep 1996 11:55:49 -0400 (EDT) Cc: current@freebsd.org In-Reply-To: <199609290624.CAA06931@gandalf.ec.camitel.com> from "Claude Cote" at Sep 29, 96 02:24:27 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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." =============================================================================