|
|
- # Configuring NTPD with UCI
-
- ## Precedent
- Sysntpd is the lightweight implementation of the NTP protocol under
- Busybox. It supports many (but not all) of the same parameters.
-
- It is configured as a `config timeserver ntp` section in `/etc/config/system`,
- below.
-
- ## Configuration
-
- A sample configuration looks like:
-
- **/etc/config/system**:
-
- ```
- config timeserver ntp
- option enabled 1
- option enable_server 1
- list server tick.udel.edu
- list server tock.udel.edu
- list interface eth0
- list interface eth1
- list interface eth2
- ```
-
- If you want to temporarily disable the service without deleting all of the
- configuration state, this is done by clearing the `enabled` parameter. If
- this parameter is `1` (the default), the service is enabled.
-
- The service can run as a stand-alone client (`enable_server 0`, the default)
- or it can also operate as a server in turn to local clients, by setting this
- parameter to `1`.
-
- The parameter(s) `server` enumerate a list of servers to be used for
- reference NTP servers by the local daemon. At least one is required,
- and two or more are recommended (unless you have an extremely available
- local server). They should be picked to be geographically divergent,
- and preferrably reachable via different network carriers to protect
- against network partitions, etc. They should also be high-quality
- time providers (i.e. having stable, accurate clock sources).
-
- The `interface` parameter enumerates the list of interfaces on which
- the server is reachable (see `enable_server 1` above), and may be a
- subset of all of the interfaces present on the system. For security
- reasons, you may elect to only offer the service on internal networks.
- If omitted, it defaults to _all_ interfaces.
-
- ## Differences with `sysntpd`
-
- Busybox `sysntpd` supports configuring servers based on DHCP
- provisioning (option 6, per the [DHCP and BOOTP
- Parameter](https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml)
- list from IANA). This functionality is enabled (in Busybox) with the
- `use_dhcp` boolean parameter (default `1`), and the `dhcp_interface`
- list parameter, which enumerates the interfaces whose provisioning
- is to be utilized.
-
- ### Considerations for DHCP-provisioned NTP servers
-
- Most terrestrial and satellite ISPs have access to very high-quality
- clock sources (these are required to maintain synchronization on T3,
- OC3, etc trunks or earth terminals) but seldom offer access to those
- time sources via NTP in turn to their clients, mostly from a misplaced
- fear that their time source might come under attack (a slave closely
- tied to the master could also provide extremely high-quality time
- without the risk of network desynchronization should it come under
- sophisticated attack).
-
- As a result, the NTP servers that your ISP may point you at are
- often of unknown/unverified quality, and you use them at your own
- risk.
-
- Early millenial versions of Windows (2000, XP, etc) used NTP only
- to _initially set_ the clock to approximately 100ms accuracy (and
- not maintain sychronization), so the bar wasn't set very high.
- Since then, requirements for higher-qualty timekeeping have
- arisen (e.g. multi-master SQL database replication), but most ISPs
- have not kept up with the needs of their users.
-
- Current releases of Windows use Domain Controllers for time
- acquisition via the [NT5DS protocol](https://blogs.msdn.microsoft.com/w32time/2007/07/07/what-is-windows-time-service/)
- when domain joined.
-
- Because of the unreliable quality of NTP servers DHCP-provisioned by
- ISPs, support for this functionality was deemed unnecessary.
|
