Bill,
I'm not certain this is your problem, but . . .
AFAIK, 192.x.x.x is a non routable (internal) address. It's possible
that your DNS server or NTP server is blocking that address from the
DMZ. Perhaps try starting a VPN client on the DMZ machine and see if
that clears it up. Also, check that SELINUX is not interfering.
Good luck.
Tangren, Bill wrote:
I have two essentially identical servers, RHEL ES 4.6 fully patched. The
only difference is, one is in a DMZ and the other is not. Both can do an
nslookup on the time server I use (tick.usno.navy.mil), but when I turn
off ntp and use the ntpdate command, it fails on the server in the DMZ
and succeeds on the one that is not. Here is the output from ntpdate in
debug mode. First the one that succeeds:
[root@ceres ~]# ntpdate -d tick.usno.navy.mil
4 Aug 08:35:11 ntpdate[16244]: ntpdate 4.2.0a@xxxxxxxx Wed Apr 23
07:36:43 EDT 2008 (1) Looking for host tick.usno.navy.mil and service
ntp host found : ntp0.usno.navy.mil
transmit(192.5.41.40)
receive(192.5.41.40)
transmit(192.5.41.40)
receive(192.5.41.40)
transmit(192.5.41.40)
receive(192.5.41.40)
transmit(192.5.41.40)
receive(192.5.41.40)
transmit(192.5.41.40)
server 192.5.41.40, port 123
stratum 1, precision -20, leap 00, trust 000 refid [USNO], delay
0.02966, dispersion 0.00238 transmitted 4, in filter 4
reference time: cc4175f6.c33a64a3 Mon, Aug 4 2008 8:35:02.762
originate timestamp: cc4175ff.647a9322 Mon, Aug 4 2008 8:35:11.392
transmit timestamp: cc4175ff.62961c36 Mon, Aug 4 2008 8:35:11.385
filter delay: 0.02966 0.03514 0.03532 0.03551
0.00000 0.00000 0.00000 0.00000 filter offset: -0.00061
0.002036 0.002256 0.002382
0.000000 0.000000 0.000000 0.000000 delay 0.02966, dispersion
0.00238 offset -0.000610
4 Aug 08:35:11 ntpdate[16244]: adjust time server 192.5.41.40 offset
-0.000610 sec
Now, the one that fails:
[root@aa ~]# ntpdate -d tick.usno.navy.mil
4 Aug 07:34:12 ntpdate[26513]: ntpdate 4.2.0a@xxxxxxxx Wed Apr 23
07:36:43 EDT 2008 (1) Looking for host tick.usno.navy.mil and service
ntp host found : 192.5.41.40
transmit(192.5.41.40)
transmit(192.5.41.40)
transmit(192.5.41.40)
transmit(192.5.41.40)
transmit(192.5.41.40)
192.5.41.40: Server dropped: no data
server 192.5.41.40, port 123
stratum 0, precision 0, leap 00, trust 000 refid [192.5.41.40], delay
0.00000, dispersion 64.00000 transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 1:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 1:28:16.000
transmit timestamp: cc4167b7.6069a4df Mon, Aug 4 2008 7:34:15.376
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000 filter offset: 0.000000
0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000 delay 0.00000, dispersion
64.00000 offset 0.000000
4 Aug 07:34:16 ntpdate[26513]: no server suitable for synchronization
found
You can see that in the latter case, it found the ntp server, but it got
no response from the transmit commands.
I noticed this problem just after updating to RHEL ES 4.6, though may
well have been coincidental. I talked to the firewall guy, and he says
that the port is open both ways into and out of the DMZ and no error
messages show up in the firewall logs when I run this command.
Can anyone point me in the right direction to solving this mystery?
---
Bill Tangren
U.S. Naval Observatory
--
veritatas simplex oratio est
-Seneca
Andrew Bacchi
Systems Programmer
Rensselaer Polytechnic Institute
phone: 518.276.6415 fax: 518.276.2809
http://www.rpi.edu/~bacchi/
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
