Red Hat Bugzilla – Bug 9692
wrong timestamp with LAST_MODIFED in NIS maps
Last modified: 2008-05-01 11:37:54 EDT
using: [root@foucault kiva]# rpm -q libc ypserv libc-5.3.12-18.5 ypserv-1.3.9-0.4.2 On occasion NIS maps which are pushed from a redhat 6.0 NIS master to a redhat 4.2 slave are given the wrong LAST_MODIFIED timestamp. The timestamp given is up in the year 2038, indicating that perhaps a value is going negative when it shouldn't. When this happens the slave will no longer accept updated version of that particular map from the master because the master's version appears to be older. I have contacted Thorsten Kukuk and he is aware of the problem. Here is a part of our conversation: -=-=- > Looking in the source I find the clnt_perror that is producing > this output at line 350 in ypxfr.c: > > req_nokey.domain = SourceDomain; > req_nokey.map = mapName; > if ((resp_order = ypproc_order_2 (&req_nokey, clnt_udp)) == NULL) > { > clnt_perror (clnt_udp, "masterOrderNum"); > masterOrderNum = 0x7fffffff; This is wrong. Here the current time should be used. I will fix it the next days. The rpc code in libc5 is very buggy, so I don't care any longer about it, since nearly everybody uses now glibc. Thorsten -=-=- So apparently he is working on a fix. I'm posting here for completeness and to encourage the creation of a new "official" rpm.
The following patch appears to clear up this problem. Or at least since applying this patch we no longer have the problem. diff -r -u ypserv-1.3.9.orig/ypxfr.c ypserv-1.3.9/ypxfr.c --- ypserv-1.3.9.orig/ypxfr.c Sat Aug 21 02:22:20 1999 +++ ypserv-1.3.9/ypxfr.c Mon Feb 28 23:52:59 2000 @@ -348,7 +348,9 @@ if ((resp_order = ypproc_order_2 (&req_nokey, clnt_udp)) == NULL) { clnt_perror (clnt_udp, "masterOrderNum"); - masterOrderNum = 0x7fffffff; + masterOrderNum = time (NULL); /* We set it to the current time. + So a new map will be always newer. */ + } else {