OpenNTPD

OpenNTPD (part of the OpenBSD project) is a daemon that can be used to synchronize the system clock to internet time servers using the Network Time Protocol, and can also act as a time server itself if needed. It implements the Simple Network Time Protocol version 4, as described in RFC:5905, and the Network Time Protocol version 3, as described in RFC:1305.

Installation

Install the openntpd package. The default configuration is actually usable if all you want is to sync the time of the local computer.

Configuration

To configure OpenNTPD, you need to edit /etc/ntpd.conf. See ntpd.conf(5) for all available options.

Tip: After configuring, check the configuration file for validity by executing:

$ ntpd -n

Client

To sync to a single particular server, uncomment and edit the "server" directive.

/etc/ntpd.conf

server ntp.example.org

The "servers" directive works the same as the "server" directive, however, if the DNS name resolves to multiple IP address, ALL of them will be synced to. The default, "pool.ntp.org" is working and should be acceptable in most cases. You can find the server's URL in your area at www.pool.ntp.org/zone/@.

/etc/ntpd.conf

servers pool.ntp.org

Any number of "server" or "servers" directives may be used.

Server

If you want the computer you run OpenNTPD on to also be a time server, simply uncomment and edit the "listen" directive.

For example:

/etc/ntpd.conf

listen on *

will listen on all interfaces, and

will only listen on the loopback interface.

Your time server will only begin to serve time after it has synchronized itself to a high resolution. This may take hours, or days, depending on the accuracy of your system.

Usage

Start OpenNTPD at boot

Enable .

Making openntpd dependent upon network access

If you have intermittent network access (you roam around on a laptop, you use dial-up, etc), it does not make sense to have running as a system daemon on start up. Here are a few ways you can control based on the presence of a network connection.

Using NetworkManager dispatcher

OpenNTPD can be brought up/down along with a network connection through the use of NetworkManager's dispatcher scripts.

Install .

Using wicd

Create these two scripts and mark them executable.

/etc/wicd/scripts/postconnect/openntpd-start.sh

#!/bin/sh
systemctl start openntpd.service

Using dhclient hooks

Another possibility is to use dhclient hooks to start and stop openntpd. When dhclient detects a change in state it will run the following scripts:

See

Using dhcpcd hooks

See

Troubleshooting

Error adjusting time

If you find your time set incorrectly and in log you see:

openntpd adjtime failed: Invalid argument

Try:

# ntpd -d

This is also how you would manually sync your system.

constraint: failed to load constraint ca

OpenNTPD will fail to start on a system with AppArmor if HTTPS constraints are configured in /etc/ntpd.conf. Journal will show .

This is because AppArmor's profile does not have read access to LibreSSL's CA certificate file /etc/libressl/cert.pem.

The solution is to grant access with a local override:

/etc/apparmor.d/local/usr.sbin.ntpd

...
/etc/libressl/{,cert.pem} r,

After editing, reload the AppArmor profile:

# apparmor_parser -r /etc/apparmor.d/usr.sbin.ntpd

gollark: It could record locally and upload later, though.

gollark: This person apparently reverse-engineered it statically, not at runtime, but it *can* probably detect if you're trying to reverse-engineer it a bit while running.

gollark: > > App behavior changes slightly if they know you're trying to figure out what they're doing> this sentence makes no sense to me, "if they know"? he's dissecting the code as per his own statement, thus looking at rows of text in various format. the app isn't running - so how can it change? does the app have self-awareness? this sounds like something out of a bad sci-fi movie from the 90's.It's totally possible for applications to detect and resist being debugged a bit.

gollark: > this is standard programming dogma, detailed logging takes a lot of space and typically you enable logging on the fly on clients to catch errors. this is literally cookie cutter "how to build apps 101", and not scary. or, phrased differently, is it scary if all of that logging was always on? obviously not as it's agreed upon and detailed in TikTok's privacy policy (really), so why is it scary that there's an on and off switch?This is them saying that remotely configurable logging is fine and normal; I don't think them being able to arbitrarily gather more data is good.

gollark: > on the topic of setting up a proxy server - it's a very standard practice to transcode and buffer media via a server, they have simply reversed the roles here by having server and client on the client, which makes sense as transcoding is very intensive CPU-wise, which means they have distributed that power requirement to the end user's devices instead of having to have servers capable of transcoding millions of videos.Transcoding media locally is not the same as having some sort of locally running *server* to do it.