diff --git a/chrony.texi.in b/chrony.texi.in index 12aa245..cb1d3f5 100644 --- a/chrony.texi.in +++ b/chrony.texi.in @@ -4487,7 +4487,7 @@ command is issued. @menu * Administrative issues:: * Chrony compared to other programs:: -* Selection of NTP servers:: +* Configuration:: * Computer is not synchronising:: * Issues with chronyc:: * Real-time clock issues:: @@ -4507,8 +4507,9 @@ For the current development from the developers' version control system see the @code{Git} link on the web site. @subsection Are there any packaged versions of chrony? -We are aware of packages for Debian, Fedora, Gentoo, Mandriva, Slackware, and -Ubuntu. We are not involved with how these are built or distributed. +We are aware of packages for Arch, Debian, Fedora, Gentoo, Mandriva, Slackware, +Ubuntu, FreeBSD and NetBSD. We are not involved with how these are built or +distributed. @subsection Where is the home page? It is currently at @@ -4534,25 +4535,25 @@ BSD-like license. @c {{{ S:Chrony compared to other programs @node Chrony compared to other programs @section Chrony compared to other programs -@subsection How does chrony compare to xntpd? -If your computer is permenently connected, or connected for long periods (that -is, for the several hours it takes xntpd to settle down), or you need to -support hardware reference clocks to your computer, then xntpd will work fine. -Apart from not supporting hardware clocks, chrony will work fine too. +@subsection How does chrony compare to ntpd? +Chrony can usually synchronise the system clock faster and with better time +accuracy, but it doesn't implement all NTP features, e.g. broadcast/multicast +mode, or authentication based on public-key cryptography. For a more detailed +comparison, see section @code{Comparison with ntpd} in the manual. -If your computer connects to the 'net for 5 minutes once a day (or something -like that), or you turn your Linux computer off when you're not using it, or -you want to use NTP on an isolated network with no hardware clocks in sight, -chrony will work much better for you. +If your computer connects to the 'net only for few minutes at a time, you turn +your Linux computer off or suspend it frequently, the clock is not very stable +(e.g. it is a virtual machine), or you want to use NTP on an isolated network +with no hardware clocks in sight, chrony will probably work much better for +you. -The reason I wrote chrony was that I could not get xntpd to do anything -sensible on my PC at home, which is connected to the 'net for about 5 minutes -once or twice a day, mainly to upload/download email and news. Nowadays it is -also turned off for 22-23 hours a day, when not in use. I wanted a program -which would +The original reason chrony was written was that ntpd (called xntpd at the +time) could not to do anything sensible on a PC which was connected to +the 'net only for about 5 minutes once or twice a day, mainly to +upload/download email and news. The requirements were @itemize @bullet -@item slew the time to correct it when I go online and NTP servers become +@item slew the time to correct it when going online and NTP servers become visible @item determine the rate at which the computer gains or loses time and use this information to keep it reasonably correct between connects to the 'net. This @@ -4561,22 +4562,21 @@ availability of the references or the fact the computer is turned off between groups of measurements. @item maintain the time across reboots, by working out the error and drift rate of the computer's real-time clock and using this information to set the system -clock correctly at boot up. (In the last few months, it became impossible for -me to leave my computer powered permanently.) +clock correctly at boot up. @end itemize -Also, when working with isolated networks with no true time references -at all, I found xntpd gave me no help with managing the local clock's -gain/loss rate on the NTP master node (which I set from my watch). I -added some automated support in chrony to deal with this. +Also, when working with isolated networks with no true time references at all +ntpd was found to give no help with managing the local clock's gain/loss rate +on the NTP master node (which was set from watch). Some automated support was +added to chrony to deal with this. @c }}} -@c {{{ S:Selection of NTP servers -@node Selection of NTP servers -@section Selection of NTP servers +@c {{{ S:Configuration +@node Configuration +@section Configuration -@subsection I have several computers on a LAN. Should I make one the master, or make them all clients of an external server? -I think the best configuration is to make one computer the master, with the +@subsection I have several computers on a LAN. Should be all clients of an external server? +The best configuration is usually to make one computer the master, with the others as clients of it. Add a @code{local} directive to the master's chrony.conf file. This configuration will be better because @@ -4587,6 +4587,28 @@ chrony.conf file. This configuration will be better because maintain a common time with each other. @end itemize +@subsection Must I specify servers by IP address if DNS is not available on chronyd start? +No. Starting from version 1.25, @code{chronyd} will keep trying to resolve the +hostnames specified in the @code{server} and @code{peer} directives in +increasing intervals until it succeeds. The @code{online} command can be +issued from @code{chronyc} to try to resolve them immediately. + +@subsection How can I make chronyd more secure? +If you don't need to serve time to NTP clients, you can add @code{port 0} to +the @file{chrony.conf} file to disable the NTP server/peer sockets and prevent +NTP requests from reaching @code{chronyd}. + +If you don't need to use @code{chronyc} remotely, you can add the following +directives to the configuration file to bind the command sockets to the +loopback interface + +@example +bindcmdaddress 127.0.0.1 +bindcmdaddress ::1 +@end example + +If you don't need to use @code{chronyc} at all, you can disable the command +sockets by adding @code{cmdport 0} to the configuration file. @c }}} @c {{{ S:Computer is not synchronising @node Computer is not synchronising @@ -4597,16 +4619,13 @@ following questions. @subsection Behind a firewall? If there is a firewall between you and the NTP server you're trying to use, -the packets may be blocked. Try using a tool like etherfind or tcpdump to see +the packets may be blocked. Try using a tool like wireshark or tcpdump to see if you're getting responses from the server. If you have an external modem, see if the receive light blinks straight after the transmit light (when the link is quiet apart from the NTP traffic.) Try adding @code{log measurements} to the @file{chrony.conf} file and look in the measurements.log file after chrony has been running for a short period. See if any measurements appear. -Most people run chronyd on the firewall itself, to avoid all issues of UDP -packet forwarding and/or masquerading. - @subsection Do you have a non-permanent (i.e. intermittent) Internet connection? Check that you're using chronyc's @code{online} and @code{offline} commands appropriately. Again, check in measurements.log to see if you're getting any @@ -4622,21 +4641,21 @@ will arise. You should always make X quite high (e.g. 10) in this directive. @section Issues with chronyc @subsection I keep getting the error @code{506 Cannot talk to daemon} -Make sure that the @file{chrony.conf} file (on the computer where chronyd is -running) has a @code{cmdallow} entry for the computer you are running chronyc -on. This isn't necessary for localhost. +Make sure that the @file{chrony.conf} file (on the computer where +@code{chronyd} is running) has a @code{cmdallow} entry for the computer you are +running @code{chronyc} on. This isn't necessary for localhost. -Perhaps chronyd is not running. Try using the ps command (e.g. on Linux, 'ps --auxw') to see if it's running. Or try 'netstat -a' and see if the ports -123/udp and 323/udp are listening. If @code{chronyd} is not running, you may -have a problem with the way you are trying to start it (e.g. at boot time). +Perhaps @code{chronyd} is not running. Try using the ps command (e.g. on +Linux, 'ps -auxw') to see if it's running. Or try 'netstat -a' and see if the +ports 123/udp and 323/udp are listening. If @code{chronyd} is not running, you +may have a problem with the way you are trying to start it (e.g. at boot time). Perhaps you have a firewall set up in a way that blocks packets on port 323/udp. You need to amend the firewall configuration in this case. @subsection Is the chronyc<->chronyd protocol documented anywhere? -Only by the source code :-) See cmdmon.c (chronyd side) and client.c (chronyc -side). +Only by the source code :-) See cmdmon.c (@code{chronyd} side) and client.c +(@code{chronyc} side). @c }}} @c {{{ S:Real-time clock issues @node Real-time clock issues @@ -4653,13 +4672,13 @@ details. The hwclock program is often set-up by default in the boot and shutdown scripts with many Linux installations. If you want to use chronyd's real-time clock support, the important thing is to disable hwclock in the shutdown procedure. -If you don't, it will over-write the RTC with a new value, unknown to chronyd. -At the next reboot, chronyd will compensate this (wrong) time with its estimate -of how far the RTC has drifted whilst the power was off, giving a meaningless -initial system time. +If you don't, it will over-write the RTC with a new value, unknown to +@code{chronyd}. At the next reboot, @code{chronyd} will compensate this (wrong) +time with its estimate of how far the RTC has drifted whilst the power was off, +giving a meaningless initial system time. -There is no need to remove hwclock from the boot process, as long as chronyd is -started after it has run. +There is no need to remove hwclock from the boot process, as long as +@code{chronyd} is started after it has run. @subsection I just keep getting the '513 RTC driver not running' message For the real time clock support to work, you need the following three things @@ -4674,50 +4693,34 @@ For the real time clock support to work, you need the following three things @section Microsoft Windows @subsection Does chrony support Windows? -No. The chronyc program (the command-line client used for configuring -chronyd while it is running) has been successfully built and run under Cygwin -in the past. chronyd is not portable, because part of it is very +No. The @code{chronyc} program (the command-line client used for configuring +@code{chronyd} while it is running) has been successfully built and run under +Cygwin in the past. @code{chronyd} is not portable, because part of it is very system-dependent. It needs adapting to work with Windows' equivalent of the adjtimex() call, and it needs to be made to work as an NT service. @subsection Are there any plans to support Windows? We have no plans to do this. Anyone is welcome to pick this work up and contribute it back to the project. - -@subsection What alternative NTP clients are there for Windows? -Some of the names we've seen mentioned are -@itemize @bullet -@item Automachron -@item NetTime (nettime.sourceforge.net) -@end itemize @c }}} @c {{{ S:NTP-specific issues @node NTP-specific issues @section NTP-specific issues @subsection Can chrony be driven from broadcast NTP servers? -No. I remember looking at how they worked when I was first writing chrony. -Since the 'target market' then was dial-up systems, broadcast packets were not -relevant so I didn't bother working out how to deal with the complexities of -doing the delay estimation. - -I no longer have root access to a LAN environment to develop and test broadcast -server support. Neither have I the time to work on this. I would be very -happy to accept a patch from anyone who can develop, test and debug the -necessary changes! +No, this NTP mode is not implemented yet. @subsection Can chronyd transmit broadcast NTP packets (e.g. to synchronise other computers on a private LAN)? Yes. Starting from version 1.17, chrony has this capability. @subsection Can chrony keep the system clock a fixed offset away from real time? -I have not experimented much, but I don't believe this would be possible as -the program currently stands. +This is not possible as the program currently stands. @subsection What happens if the network connection is dropped without using chronyc's 'offline' command first? -In this case chronyd will keep trying to access the server(s) that it thinks -are online. Eventually it will decide that they are unreachable and no longer -consider itself synchronised to them. If you have other computers on your LAN -accessing the computer that is affected this way, they too will become +In this case @code{chronyd} will keep trying to access the server(s) that it +thinks are online. Eventually it will decide that they are unreachable and no +longer consider itself synchronised to them. If you have other computers on +your LAN accessing the computer that is affected this way, they too will become 'unsynchronised', unless you have the 'local' directive set up on the master computer. @@ -4728,17 +4731,8 @@ useful to avoid this situation. @node Linux-specific issues @section Linux-specific issues -@subsection Why does the source code include kernel header files? -The program needs to see the definitions of structures used to interact with -the real time clock (via /dev/rtc) and with the adjtimex() system call. Sadly -this has led to a number of compilation problems with newer kernels which have -been increasingly hard to fix in a way that makes the code compilable on all -Linux kernel versions. Hopefully -the situation will not deteriorate further with future kernel versions. - @subsection I get "Could not open /dev/rtc, Device or resource busy" in my syslog file -Check that you haven't accidentally got two copies of chronyd running (perhaps -defined in different start-up scripts.) +Some other program running on the system may be using the device. @c }}} @c {{{ S:Solaris-specific issues @node Solaris-specific issues @@ -4748,10 +4742,9 @@ defined in different start-up scripts.) (The dosynctodr variable controls whether Solaris couples the equivalent of its BIOS clock into its system clock at regular intervals). The Solaris port of chrony was developed in the Solaris 2.5 era. Some aspect of the Solaris kernel -has changed which prevents the same technique working. I no longer have root -access to any Solaris machines to work on this, and am reliant on somebody -developing the patch and testing it. A good starting point would be to see if -xntpd has been modified to work for Solaris 2.8. +has changed which prevents the same technique working. We no longer have root +access to any Solaris machines to work on this, and we are reliant on somebody +developing the patch and testing it. @c }}} @c }}} @c {{{ apx:GNU General Public License