Advanced NTP client and server
bbeec7361c
The NTP SHM refclock protocol has the following properties: - the memory segments have a predictable key (first segment 0x4e545030) - it's expected to work in any order of starting chronyd and the program providing samples to chronyd, i.e. both the consumer and producer need to be able to create the segment - the producer and consumer generally don't know under which user is the other side running (e.g. gpsd can create the segment as root and also as nobody after it drops root privileges) - there is no authentication of data provided via SHM - there is no way to restart the protocol This makes it difficult for chronyd to ensure it is receiving measurements from the process that the admin expects it to and not some other process that managed to create the segment before it was started. It's up to the admin to configure the system so that chronyd or the producer is started before untrusted applications or users can create the segment, or at least verify at some point later that the segment was created with the expected owner and permissions. There doesn't seem to be a backward-compatible fix of the protocol. Even if one side could detect the segment had a wrong owner or permissions, it wouldn't be able to tell the other side to reattach after recreating the segment with the expected owner and permissions, if it still had the permissions to do that. The protocol would need to specify which side is responsible for creating the segment and the start order would need to strictly follow that. As gpsd (likely the most common refclock source for chronyd) now supports in the latest version SOCK even for message-based timing, update the man page and FAQ to deprecate SHM in favor of SOCK. |
||
|---|---|---|
| contrib | ||
| doc | ||
| examples | ||
| test | ||
| .gitignore | ||
| addressing.h | ||
| addrfilt.c | ||
| addrfilt.h | ||
| array.c | ||
| array.h | ||
| candm.h | ||
| client.c | ||
| clientlog.c | ||
| clientlog.h | ||
| cmac.h | ||
| cmac_gnutls.c | ||
| cmac_nettle.c | ||
| cmdmon.c | ||
| cmdmon.h | ||
| cmdparse.c | ||
| cmdparse.h | ||
| conf.c | ||
| conf.h | ||
| configure | ||
| COPYING | ||
| getdate.h | ||
| getdate.y | ||
| hash.h | ||
| hash_gnutls.c | ||
| hash_intmd5.c | ||
| hash_nettle.c | ||
| hash_nss.c | ||
| hash_tomcrypt.c | ||
| hwclock.c | ||
| hwclock.h | ||
| keys.c | ||
| keys.h | ||
| local.c | ||
| local.h | ||
| localp.h | ||
| logging.c | ||
| logging.h | ||
| main.c | ||
| main.h | ||
| make_release | ||
| Makefile.in | ||
| manual.c | ||
| manual.h | ||
| md5.c | ||
| md5.h | ||
| memory.c | ||
| memory.h | ||
| nameserv.c | ||
| nameserv.h | ||
| nameserv_async.c | ||
| nameserv_async.h | ||
| NEWS | ||
| ntp.h | ||
| ntp_auth.c | ||
| ntp_auth.h | ||
| ntp_core.c | ||
| ntp_core.h | ||
| ntp_ext.c | ||
| ntp_ext.h | ||
| ntp_io.c | ||
| ntp_io.h | ||
| ntp_io_linux.c | ||
| ntp_io_linux.h | ||
| ntp_signd.c | ||
| ntp_signd.h | ||
| ntp_sources.c | ||
| ntp_sources.h | ||
| nts_ke.h | ||
| nts_ke_client.c | ||
| nts_ke_client.h | ||
| nts_ke_server.c | ||
| nts_ke_server.h | ||
| nts_ke_session.c | ||
| nts_ke_session.h | ||
| nts_ntp.h | ||
| nts_ntp_auth.c | ||
| nts_ntp_auth.h | ||
| nts_ntp_client.c | ||
| nts_ntp_client.h | ||
| nts_ntp_server.c | ||
| nts_ntp_server.h | ||
| pktlength.c | ||
| pktlength.h | ||
| privops.c | ||
| privops.h | ||
| ptp.h | ||
| quantiles.c | ||
| quantiles.h | ||
| README | ||
| refclock.c | ||
| refclock.h | ||
| refclock_phc.c | ||
| refclock_pps.c | ||
| refclock_shm.c | ||
| refclock_sock.c | ||
| reference.c | ||
| reference.h | ||
| regress.c | ||
| regress.h | ||
| reports.h | ||
| rtc.c | ||
| rtc.h | ||
| rtc_linux.c | ||
| rtc_linux.h | ||
| samplefilt.c | ||
| samplefilt.h | ||
| sched.c | ||
| sched.h | ||
| siv.h | ||
| siv_gnutls.c | ||
| siv_nettle.c | ||
| siv_nettle_int.c | ||
| smooth.c | ||
| smooth.h | ||
| socket.c | ||
| socket.h | ||
| sources.c | ||
| sources.h | ||
| sourcestats.c | ||
| sourcestats.h | ||
| srcparams.h | ||
| stubs.c | ||
| sys.c | ||
| sys.h | ||
| sys_generic.c | ||
| sys_generic.h | ||
| sys_linux.c | ||
| sys_linux.h | ||
| sys_macosx.c | ||
| sys_macosx.h | ||
| sys_netbsd.c | ||
| sys_netbsd.h | ||
| sys_null.c | ||
| sys_null.h | ||
| sys_posix.c | ||
| sys_posix.h | ||
| sys_solaris.c | ||
| sys_solaris.h | ||
| sys_timex.c | ||
| sys_timex.h | ||
| sysincl.h | ||
| tempcomp.c | ||
| tempcomp.h | ||
| util.c | ||
| util.h | ||
This is the README for chrony.
What is chrony?
===============
chrony is a versatile implementation of the Network Time Protocol (NTP).
It can synchronise the system clock with NTP servers, reference clocks
(e.g. GPS receiver), and manual input using wristwatch and keyboard.
It can also operate as an NTPv4 (RFC 5905) server and peer to provide
a time service to other computers in the network.
It is designed to perform well in a wide range of conditions, including
intermittent network connections, heavily congested networks, changing
temperatures (ordinary computer clocks are sensitive to temperature),
and systems that do not run continuosly, or run on a virtual machine.
Typical accuracy between two machines synchronised over the Internet is
within a few milliseconds; on a LAN, accuracy is typically in tens of
microseconds. With hardware timestamping, or a hardware reference clock,
sub-microsecond accuracy may be possible.
Two programs are included in chrony, chronyd is a daemon that can be
started at boot time and chronyc is a command-line interface program
which can be used to monitor chronyd's performance and to change various
operating parameters whilst it is running.
What will chrony run on?
========================
The software is known to work on Linux, FreeBSD, NetBSD, macOS and
illumos. Closely related systems may work too. Any other system will
likely require a porting exercise.
How do I set it up?
===================
The file INSTALL gives instructions. On supported systems the
compilation process should be automatic. You will need a C compiler,
e.g. gcc or clang.
What documentation is there?
============================
The distribution includes manual pages and a document containing
Frequently Asked Questions (FAQ).
The documentation is also available on the chrony web pages, accessible
through the URL
https://chrony.tuxfamily.org/
Where are new versions announced?
=================================
There is a low volume mailing list where new versions and other
important news relating to chrony are announced. You can join this list
by sending mail with the subject "subscribe" to
chrony-announce-request@chrony.tuxfamily.org
How can I get support for chrony?
=================================
There are two other mailing lists relating to chrony. chrony-users is a
discussion list for users, e.g. for questions about chrony configuration
and bug reports. chrony-dev is a more technical list for developers,
e.g. for submitting patches and discussing how new features should be
implemented. To subscribe to either of these lists, send a message with
the subject "subscribe" to
chrony-users-request@chrony.tuxfamily.org
or
chrony-dev-request@chrony.tuxfamily.org
as applicable.
License
=======
chrony is distributed under the GNU General Public License version 2.
Authors
=======
Richard P. Curnow <rc@rc0.org.uk>
Miroslav Lichvar <mlichvar@redhat.com>
Acknowledgements
================
In writing the chronyd program, extensive use has been made of the NTPv3 (RFC
1305) and NTPv4 (RFC 5905) specification. The source code of the xntpd/ntpd
implementation written by Dennis Fergusson, Lars Mathiesen, David Mills, and
others has been used to check the details of the protocol.
The following people have provided patches and other major contributions
to chrony:
Lonnie Abelbeck <lonnie@abelbeck.com>
Benny Lyne Amorsen <benny@amorsen.dk>
Andrew Bishop <amb@gedanken.demon.co.uk>
Vincent Blut <vincent.debian@free.fr>
Stephan I. Boettcher <stephan@nevis1.columbia.edu>
David Bohman <debohman@gmail.com>
Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>
Leigh Brown <leigh@solinno.co.uk>
Erik Bryer <ebryer@spots.ab.ca>
Jonathan Cameron <jic23@cam.ac.uk>
Bryan Christianson <bryan@whatroute.net>
Juliusz Chroboczek <jch@pps.jussieu.fr>
Kamil Dudka <kdudka@redhat.com>
Christian Ehrhardt <christian.ehrhardt@canonical.com>
Paul Elliott <pelliott@io.com>
Robert Fairley <rfairley@redhat.com>
Stefan R. Filipek <srfilipek@gmail.com>
Mike Fleetwood <mike@rockover.demon.co.uk>
Alexander Gretencord <arutha@gmx.de>
Andrew Griffiths <agriffit@redhat.com>
Walter Haidinger <walter.haidinger@gmx.at>
Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
John Hasler <john@dhh.gt.org>
Tjalling Hattink <t.hattink@fugro.nl>
Liam Hatton <me@liamhatton.com>
Jachym Holecek <jakym@volny.cz>
Håkan Johansson <f96hajo@chalmers.se>
Jim Knoble <jmknoble@pobox.com>
Antti Jrvinen <costello@iki.fi>
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Eric Lammerts <eric@lammerts.org>
Stefan Lucke <stefan@lucke.in-berlin.de>
Victor Lum <viclum@vanu.com>
Kevin Lyda <kevin@ie.suberic.net>
Paul Menzel <paulepanter@users.sourceforge.net>
Vladimir Michl <vladimir.michl@seznam.cz>
Victor Moroz <vim@prv.adlum.ru>
Kalle Olavi Niemitalo <tosi@stekt.oulu.fi>
Frank Otto <sandwichmacher@web.de>
Denny Page <dennypage@me.com>
Chris Perl <cperl@janestreet.com>
Gautier PHILIPPON <gautier.philippon@ensimag.grenoble-inp.fr>
Andreas Piesk <apiesk@virbus.de>
Baruch Siach <baruch@tkos.co.il>
Foster Snowhill <forst@forstwoof.ru>
Andreas Steinmetz <ast@domdv.de>
NAKAMURA Takumi <takumi@ps.sakura.ne.jp>
Timo Teras <timo.teras@iki.fi>
Bill Unruh <unruh@physics.ubc.ca>
Stephen Wadeley <swadeley@redhat.com>
Bernhard Weiss <lisnablagh@web.de>
Wolfgang Weisselberg <weissel@netcologne.de>
Bernhard M. Wiedemann <bwiedemann@suse.de>
Joachim Wiedorn <ad_debian@joonet.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Michael Witten <mfwitten@gmail.com>
Doug Woodward <dougw@whistler.com>
Thomas Zajic <zlatko@zlatko.fdns.net>
Many other people have contributed bug reports and suggestions. We are sorry
we cannot identify all of you individually.