Score:0

How can the local time clock of a server become the NTP time source in a network?

ck flag

I want to make a the local te clock in a Stratum 1 server be the network time source for my network (I don't want a Stratum 0 server with the antenna). How may I set this up in a network? Is there a tutorial which explains how to use network time protocol and set this up? I have not found anything so far on Google on how to achieve this. I would really appreciate your help.

pt flag
"I have not found anything so far on Google." Really? What did you search for? A brief search for "linux ntp server" turns up several useful looking articles.
Baldovín Cadena Mejía avatar
ck flag
I was looked for, "how to set local clock time as ntp source time".
John Mahowald avatar
cn flag
Which operating system of the "server", and do you prefer certain NTP implementations?
vidarlo avatar
ar flag
Why do you *not* want to fetch time from the internet? You can be a timeserver that fetches time from other NTP servers. That's the *normal* mode of operation.
Score:1
cn flag

Clocks in general purpose computers are garbage, relative to the accuracy expected in modern devices. Not precisely calibrated, and a server's thermal changes can cause the drift to vary. So it needs some method to be updated, or eventually it will become inaccurate, by minutes in extreme cases. Sometimes just having the clocks agree is enough, but people tend to expect better.

Onward to practical configurations. On Linux for example, chrony is popular, and has features for manually setting the clock and dealing with getting disconnected. Start with examples such as RHEL documentation on time keeping, and refer to the chrony manual as reference.

Most time servers have at least one of internet access, a sat nav antenna, or accurate clock hardware. By default chrony will serve time if it ultimately comes from a reference clock via NTP. Set allow directive to your net and use your NTP server. If however, you have none of these, you can make chrony serve time anyway with the local directive.

If this is truly an airgapped network with no time hardware either, also enable the manual directive, so you can tell it the time manually with chronyc settime.

chrony.conf with these on, some commentary on what you can use for a NTP server, and some things I like from the EL default config:

# chrony.conf that still serves time if not syncronized 

# Options for time sources

# NTP appliance
# For example, sat nav modules are inexpensive
# Assuming it is available over IP, it is an NTP server
#server time.zone.example.net iburst

# Isolated computers need software updates too!
# If there is an update server on the local net via IP,
# it can serve NTP as well as patches
#server updateproxy.example.net iburst

# Public internet NTP
# Use if you actually have internet
# But no local time source somehow
#pool 2.pool.ntp.org iburst


# Pretend local clock is syncronized
# Enabling serving time
# Use a high stratum, as a lower priority over better clocks 
local stratum 10

# Allow "chronyc settime"
# Run this with input time based on e.g. a watch or other clock
# Regularly and when the time is wrong
manual

# Allow clients to query this server
# Replace with your local net prefix
allow 2001:db8:2ea1::/48


### End source customization
### Begin other configuration

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

logdir /var/log/chrony
log measurements statistics tracking
cn flag
Agreed, and given that most hosts are virtuals, that accuracy is wildly inaccurate. Almost always better to sync over the network. Most modern Linux/Windows have hyper accurate (<1 ms) time sync implementations now.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.