ypxfr NIS map transfer problem

[Brendan Newport_2]

I have been building an 11i server in a legacy 10.20 environment. My new server is a NIS slave in a NIS environment with a number of 10.20 slaves and a 11.00 master.

I followed the documented process for creating the NIS slave server which included defining the new slave in the masters ypmasters map, and running ypinit -s on the proposed slave. The default maps were transferred and these don't seem to pose a problem.

However there are a few custom maps defined, and I'm struggling to get these transferred to the new slave server. Forcing a ypxfr through Sam of all the maps has no effect, but no specific error other than for the Solaris-specific maps that I'd expect to see. So I tried yppush (not something I'd normally try as the maps aren't new)

One of the custom maps is pw_exire.byname

----------------------------------
(from the NIS server)
# yppush -v pw_expire.byname
Finding NIS servers:Map ypslaves. unknown NIS client error code -- using ypservers
slave1 slave2 mynewserver
mynewserver has been called.
slave2 has been called.
slave1 has been called.
has been called.
Status received from ypxfr on slave2:
Transfer not done: master's version isn't newer.
Status received from ypxfr on slave1:
Transfer not done: master's version isn't newer.
Status received from ypxfr on :
Transfer not done: master's version isn't newer.
No response from ypxfr on mynewserver

--------------------------------

Performing a yppush on a conventional map, such as hosts.byname doesn't see an error, and the ypxfr.log on the new NIS slave will report the attempted transfer (stopped because it has already been transferred).

Trying to send anyone of the custom maps though with yppush or straight ypxfr which it uses, all fail with the same

"No response from ypxfr on mynewserver"

...and no enties in mynewservers ypxfr.log with respect to the attempted transfer.

Looking at another slave server, the *.dir and *.pag files for the normal & customised maps can be seen in /var/yp/ but (not surprisingly) in the same location on mynewserver.

Any clues or suggested paths to pursue would be very helpful.

ta!

[Andrew J. Boyda]

Brendan,

I had the same issue on hpux 10.20. What I did to get the custom maps pushed out to the slave servers was to touch empty map files on the slave in /var/yp/domain.com.
Then on the master touch each text file for the custom maps.
/var/yp/ypmake now pushed the new custom maps out to the slaves.

[Andrew J. Boyda · Accepted solution]

Brendan,

I had the same issue on hpux 10.20. What I did to get the custom maps pushed out to the slave servers was to touch empty map files on the slave in /var/yp/domain.com.
Then on the master touch each text file for the custom maps.
/var/yp/ypmake now pushed the new custom maps out to the slaves.

[A. Clay Stephenson]

One other thing to check is that the system times on the master and slave servers. They should all agree with fairly high precision and you be running NTP on all boxes. They don't have to have the same default TZ setting but they do need to have very nearly identical values for epoch seconds so that the file modification times can be compared. If this issue isn't dealt with, even after you have created null files, the problem can reoccur in the future.

[Brendan Newport_2]

Terrific answers gents - and thanks for reviewing these subjects. I am going to combine both ideas tomorrow morning and I will report on their result.


Bren

[Brendan Newport_2]

>Brendan,
>
>I had the same issue on hpux 10.20. What I >did to get the custom maps pushed out to >the slave servers was to touch empty map >files on the slave in /var/yp/domain.com.
>Then on the master touch each text file for >the custom maps.
>/var/yp/ypmake now pushed the new custom >maps out to the slaves.

This worked first time - no errors in the ypxfer log and the maps transferred and populated the /var/yp/ files that I had touched on my new slave server.

I've tried to allocate points but it hasn't taken yet - but I will continue persisting.