Bug 9692

Summary: wrong timestamp with LAST_MODIFED in NIS maps
Product: [Retired] Red Hat Linux Reporter: cdent
Component: ypservAssignee: Cristian Gafton <gafton>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.2CC: cdent
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-05-19 13:47:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description cdent 2000-02-22 20:05:09 UTC 
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.
Comment 1 cdent 2000-03-07 15:24:59 UTC 
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
     {