Question on ypxfr (NIS) on Solaris 2.5.1
>Whenever I push the "aliases" map, I seem to get a ypxfr error/warning
>message.
This doesn't happen for passwd, group, or hosts. Can anyone tell me why
>I'm getting
>these messages and what I should do to fix them?
>
>As far as I can tell, it's seems to be pushing the information just fine.
>
>/var/yp# make aliases
>/var/yp/netgrp.oxhp.com/mail.aliases: 33 aliases, longest 110 bytes, 765
>bytes total
>/usr/lib/netsvc/yp/mkalias /var/yp/`domainname`/mail.aliases
>/var/yp/`domainname`/mail.byaddr;
>updated aliases
>No response from ypxfr on host1
>No response from ypxfr on host2
My thanks to the following people for their suggestions/recommendations:
>From: David Lee[SMTP:T.D.Lee@durham.ac.uk]
>"host1" and "host2" are slave servers, and for some reason they don't
>know about the alias maps. I have no idea why this happens, but we also
>experience it when setting up a new slave server. It also happens
>on all slaves when a new map is introduced.
>
>The solution (which seems to work!) is to sign on to those slaves
>and pull in the maps by hand, using the "ypxfr" command, something like
>(but check!):
> /usr/lib/netsvc/yp/ypxfr -h <NIS-master-host> <mapname>
>
>From that point, things should be OK (your future "push"es should work).
>
>You reckon the "push" is OK. I suspect that it isn't, although other
>factors (such as these perhaps being underused servers, or these servers
>running cron jobs which periodically pull in the maps) may mask this.
-----
>From: Dave[SMTP:dburwell@telecom.com]
>
> Is it possible that the file on host1 and/or host2 are write protected in
some fashion?
-----
>From: mcain@mcs.drexel.edu[SMTP:mcain@mcs.drexel.edu]
>
>Do you have the aliases maps on the host1 and host2? I've had a problem
>with the aliases maps when they were created with the fully qualified
>form of the master host name and all the other maps were created with
>the short form of the mast host name. This kept the alises file from being
>transferred when the slave servers were set up. I'd try using "ypwhich -m"
>to see what the master server associated with each map is. I'd also do
>this on the slave servers (assuming that they are not bound to the master)
>to see what the master host name is for the copies of the maps in case
>they differ between the master and the slaves for the aliases maps.
>
>(The maps on our system (2.5.1) are all using the short form of the host
>name,
>and I don't recall whether I had to do anything special to get this to
>happen.
>Under SunOS 4.1.3, I had to modify the Makefile to get the short form of
>the master name into the aliases maps. The only change I found in the
>current
>setup that looks like it affects the aliases is the definition of the ALIASES
>variable in the Makefile, but I think this was to get it to locate the actual
>aliases file instead of the local machine's file; I don't think it kept the
>resulting incorrect maps from being pushed to the slave servers.)
-----
>From: Leo Crombach[SMTP:lcrombach@tropel.com]
>
>You may want to look at bug ID 1262695. I don't remember exactly what the
>problem was but it had to do with updating the aliases file. It's a simple
>fix in the /var/yp/Makefile.
-----
>From: Gianluca Rotoni[SMTP:gianluca@tell.ascom.ch]
>
>Most likely, ypserv is not running well on host1 and host2.
>
>The pushing process is actually a call to the slave server
>which then grabs the maps from the master using ypxfr (this is a
>security feature to avoid stranger server pushing bad maps).
>
>To manual grab the maps, on the slave servers do the following :
>
>rlogin host1
>ypxfr -h <master> <map.bykey>
>
>The path to ypxfr depends on the OS (/usr/etc/yp SunOS 4.x;
>/usr/lib/netsvc/yp SunOS 5.x)
>
>Do ypwhich -m to check the integrity of the maps.
---
Thanks!
Ju Lim
jlim@oxhp.com
