On 2006-11-16, terrypearl <[EMAIL PROTECTED]> wrote: > Been trying to get my PC to connect to an internet time server via ntpd. > No luck thus far. > > OS - Linux, Fedora Core 5 > Connected to internet via ethernet to Actiontec DSL ethernet hub > > Have tried turning the Actiontec Firewall completely off and setting the > Linux Firewall to allow TCP port 13.
NTP uses port 123/UDP <snip> > The following is the file /etc/ntp.conf file: I see nothing in here that would prevent ntpd from working once you have the correct port open. > restrict default nomodify notrap noquery This restriction line applies to all of your ntpd's "clients" and "servers". There is no need to specify explicit per host / subnet restrict lines unless you wish to modify this restriction. http://ntp.isc.org/Support/AccessRestrictions contains information about setting your ntpd restrictions. > restrict 127.0.0.1 > > # --- OUR TIMESERVERS ----- > server 0.pool.ntp.org > server 1.pool.ntp.org > server 2.pool.ntp.org If you append 'iburst' to these server lines you will speed up ntpd's initial synchronization from ~8 minutes to ~20 seconds. These pool server hostnames can resolve to serves located anywhere in the world. You may wish to restrict the pool to your geographic area. Please see http://ntp.isc.org/pool for more information. > fudge 127.127.1.0 stratum 10 You have not told ntpd to _use_ the undisciplined local clock. To do so you have to include this server line: server 127.127.1.0 There are really only two reasons to use the undisciplined local clock: 1. You are serving time to others and need to be able to continue doing so even if you loose communication with your time sources (e.g. remote time servers or local ref-clocks). 2. You are serving time to others in an isolated network. > driftfile /var/lib/ntp/drift > broadcastdelay 0.008 You do not need to specify the broadcast delay unless this ntpd is operating as a broadcast client _and_ it is unable to calculate the delay itsself. > keys /etc/ntp/keys You have not completed the symmetric key configuration, so that keys line does nothing for you. > restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery > restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery > restrict 2.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery The restrictions for these hosts are redundant as they are the same as the default restriction. > restrict 129.6.15.28 mask 255.255.255.255 nomodify notrap noquery > restrict 129.6.15.29 mask 255.255.255.255 nomodify notrap noquery The restrictions for these hosts are redundant as they are the same as the default restriction. > server time > restrict time mask 255.255.255.255 nomodify notrap noquery > server time > restrict time mask 255.255.255.255 nomodify notrap noquery What's the point of the previous 4 lines? Do you have access to an NTP server named 'time.your.domain' ? > server time-a.nist.gov > restrict time-a.nist.gov mask 255.255.255.255 nomodify notrap noquery > server time-b.nist.gov > restrict time-b.nist.gov mask 255.255.255.255 nomodify notrap noquery These are Stratum-1 servers. Please check the the Rules of Engagement (http://ntp.isc.org/rules) and make sure that you meet the criteria for the direct use of Stratum-1 time servers. Unless you are supporting a large number of client systems you should be using Stratum-2 servers (http://ntp.isc.org/s2) and/or the NTP Pool (http://ntp.isc.org/pool). The comment about redundant restrictions also applies here. -- 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
