Bug 9692 - wrong timestamp with LAST_MODIFED in NIS maps
wrong timestamp with LAST_MODIFED in NIS maps
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: ypserv (Show other bugs)
4.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-22 15:05 EST by cdent
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-19 09:47:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description cdent 2000-02-22 15:05:09 EST
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 10:24:59 EST
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.