Bug 9692 - wrong timestamp with LAST_MODIFED in NIS maps
Summary: wrong timestamp with LAST_MODIFED in NIS maps
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ypserv
Version: 4.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-02-22 20:05 UTC by cdent
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-05-19 13:47:01 UTC
Embargoed:


Attachments (Terms of Use)

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
     {


Note You need to log in before you can comment on or make changes to this bug.