On 2006-06-22, John Oliver <[EMAIL PROTECTED]> wrote:
> But port 123 is not available to other hosts on the same subnet. No,
> there is no iptables or any other firewall running on this host. How do
> I make it actually listen for connections?
There's nothing special that you have to do to ntpd other than to make
sure that it is running.
Have you tried:
ntpq -p
netstat -na | grep 123
Have you grepped the process tree for ntpd?
Are you sure that one copy of ntpd is running and that the coorect
configuration file is being used?
Have you tried using nmap from a client system to see if port 123/UDP is
open?
Are you _sure_ that there is no other firewall between your time server
and client subnet?
If ntpd is running, have you confirmed that is shows a sys.peer (i.e.
a '*' in the 'ntpq -p' billboard) and the it is at state 4 and not at
stratum 16 (see 'ntpq -crv')?
> Googling around results in an awful lot of "It just works!" answers.
> Well, it doesn't :-)
>
> Here's the ntp.conf I'm using:
None of the following comments are related to your port 123 problem ...
[ good configuration lines elided ]
> server 0.pool.ntp.org iburst
> server 1.pool.ntp.org iburst
> server 2.pool.ntp.org iburst
pool.ntp.org is a global zone. You might get better time servers by
using the pool zone for your region. More information is available at
http://ntp.isc.org/pool
> server time.nist.gov
It is not usually considered appropriate for end-user systems to
directly use Stratum-1 time servers. More information is available at
http://ntp.isc.org/rules
> # Undisciplined Local Clock.
> fudge 127.127.1.0 stratum 9
You are not using the Undisciplined Local Clock (aka LocalCLK). So this
line serves no purpose. If you wish to use the LocalCLK you must include
the following line in your ntp.conf:
server 127.127.1.0
ntpd will use the last known values to discipline your clock in the
event that you lose connectivity with all of your time sources. The only
time that using the LocalCLK makes sense is when you are serving time to
others and you need to always claim that your are synced to something.
> broadcastdelay 0.008
You are not operating as a broadcast client. So this 'broadcastdelay' is
unnecessary.
It is only useful if you are a broadcast client _and_ ntpd is unable to
calculate the broadcast delay.
> keys /etc/ntp/keys
You have not configured any symmetric keys. So this 'keys' line is
unnecessary.
--
Steve Kostecke <[EMAIL PROTECTED]>
NTP Public Services Project - http://ntp.isc.org/
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
