Just my notes/copy pastes from reading on the following links
|
My sources for this:
Plus two more cant find em
DATETIME AND NTP CLIENT AND SERVER
##################################
##################################
#########
DATETIME
#########
SET TIME
=========
To see the time on Debian GNU/Linux, use the command
# date
To see the time in UTC, use command
# date -u.
Set the time manually
=====================
When setting the time manually, the time string may be confusing. The command date –set … accepts the date and time in many formats. You can read the man page of date, or use the example below to figure out one possible format. The date is given in ISO 8601 standard format YYYY-MM-DD for Year-Month-DayOfMonth, and time of day using 24 hour clock. Leading zeros are significant.
date –set 1998-11-02
date –set 21:08:00
######################
NTP CLIENT COMMANDS
######################
For Client the following commands should be installed on debian:
# apt-get install ntp ntp-simple ntpdate
NTP.CONF
#########
The minimum system configuration is a couple of lines in your ntp configuration file, typically /etc/ntp.conf. You will need a line or two or three like this:
server some.timeserver.com
server othertime.server.org
Note: The version of ntpd released with Red Hat 7.3 (4.1.1) could not handle hostnames in the configuration, only IP addresses. The server would send requests and the remote servers would respond, but the local server would ignore the responses. For older versions of ntpd you may need to use IP addresses instead of names.
SELECT NTP: http://www.eecis.udel.edu/~mills/ntp/clock2b.html
NOTE BEFORE SYNCING:
####################
Before you synchronize with a time server you will want to check how close your system clock is to the correct time and whether it is ahead or behind the correct time. If your clock is within a minute or two of the correct time you may be happy with the standard simple procedure. If your clock is behind the correct time you are probably still OK, but be aware that your clock may jump forward some time within the first hour after you start your local time server. If your clock is ahead, starting the time server may make your system time jump backward while the system is running. This can have effects like making copies of files look older than the original, and can confuse your system in a number of ways. This tends to affect services that deal with data modification times: database servers, network file systems, distributed file synchronization, some cryptographic protocols, etc.. See Carefully Adjusting Your Clock for a procedure to set your clock back carefully.
TO SYNC WITH NTPDATE
####################
If your time is too far out, NTP will assume that it has contacted a broken server and will not adjust your time. Thus it is suggested that after installing you run
# ntpdate
run ntpdate command against your server
# ntpdate 192.168.1.1
STARTING NTPD – TO SYNC
########################
# /etc/init.d/ntpd restart
. . . or
# /etc/init.d/xntpd restart
SYNCING WITH HARDWARE CLOCK
############################
If you use the date command to change time, it is worth setting also the hardware clock to the correct time. Otherwise, the time is wrong after the next reboot, since the hardware clock keeps the time when power is turned off. When the clock in the operating system shows the correct time, set the hardware clock like this
# hwclock –systohc
Remember to add the –utc -option if the hardware clock is set to UTC!
# hwclock –systohc –utc
BIG NOTE: At least from Debian version 2.2 onwards, the system automatically saves the system time to hardware clock on shutdown, and sets the system clock from hardware clock when Debian boots up. This is done in the script /etc/init.d/hwclock.sh.
OPTIONAL FIREWALL RULE
#######################
Linux kernel-level firewalling can also interfere with your clock synchronization. A typical problem is that your system’s kernel firewall rejects incoming NTP packets. A simple measure to avoid this is to make sure UDP port 123 is open for incoming packets from your selected time servers. If you are using ipchains, a command to allow NTP packets from one of your time servers looks something like this:
# /sbin/ipchains -A input –proto udp -s onetime.server.com ntp –jump ACCEPT
MONITORING
###############
NTPQ
=====
ntpq -p
A most useful command for querying any time server’s status is “ntpq -p”. You can query a remote time server for the same kind of information with “ntpq -p <hostname>”.
# ntpq -p
remote refid st t when poll reach delay offset jitter
——————————————————————————
LOCAL(0) LOCAL(0) 10 l 22 64 377 0.000 0.000 0.001
*poolxxx.ntp.org .CDMA. 2 u 118 256 377 21.631 -0.401 0.544
+tick.somnet.net 132.249.20.88 2 u 102 256 377 35.372 -0.264 9.730
The first position in the output lines is a quick indicator of the status of the remote server. A “*” indicates the server to which you are currently synchronized. It may take some part of an hour before your server considers itself synchronized. A “+” is a candidate to take the leading role if the current server becomes unsuitable for some reason.
The labeled columns for this are:
* remote: The IP address or DNS name of the remote server
* refid: An identification of the type of the reference clock.
* st: The “stratum” or level of the server: for almost all systems, 2 is great. Your local system will have a higher number.
* t: The type of service. Your setup will show “l” for local on your local system, or “u” for “unicast” for communicating with remote servers.
* when: This is the number of seconds since the server was last heard from. After a couple of minutes of operation your server should start to report numeric values here.
* poll: Current polling interval in seconds. When remote servers are responding, “when” should be no greater than “poll”.
* reach: This and the remaining fields are important indicators of the health of your local server, your remote servers, and their communication. This field is really a bit array indicating whether responses have been received to your local server’s eight most recent requests. The value starts at 0. If your local server is receiving responses to all its requests, it will go to 1, then 3, then 7. The display is in octal, so 377 is the maximum value. Anything less indicates that either your local server recently started or some requests did not receive responses.
* delay: Recent average roundtrip time in milliseconds from request to response.
* offset: Estimated differential between your system clock and this time server’s clock, in milliseconds. You may consider this the “bottom line” on the accuracy of your system clock. NTP can usually drive this down to the level of the jitter or less.
* jitter: A measure of the variability of the delays between request and receipt of a response, in milliseconds. High jitter tends to limit your server’s ability to synchronize accurately.
Another interesting option is -n:
-n : Output all host addresses in dotted-quad numeric format rather than converting to the canonical host names.
NTPSTAT
=======
The ntpstat command will report the synchronisation state of the NTP daemon running on the local machine. If the local system is found to be synchronised to a reference time source, ntpstat will report the approximate time accuracy.
You can use the exit status (return values) to verify its operations from a shell script or command line itself:
exit status 0 – Clock is synchronised.
exit status 1 – Cock is not synchronised.
exit status 2 – If clock state is indeterminant, for example if ntpd is not contactable.
Type the command as follows:
# ntpstat
Sample outputs:
synchronised to NTP server (149.20.54.20) at stratum 3
time correct to within 42 ms
polling server every 1024 s
Use the echo command to display exit status of ntp client:
# echo $?
Sample outputs:
0
0 means Clock is Synchronised
TROUBLESHOOTING
################
PACKET CAPTURES
===============
# tcpdump udp port 123
Allow it to monitor traffic for up to an hour. You should see packets going out to your time servers port 123 (ntp) and replies coming back from each of them. Your local UDP port will probably also be number 123. Kernel firewalling (ipchains or iptables) can prevent synchronization from working even if the servers are replying to your system’s requests.
syslog
=======
Your ntpd will log various events through your system’s syslog facility. This typically means the messages will show up in /var/log/messages, in lines containing the string “ntpd”. Configuration problems are reported here. If your local server steps the time ahead or back suddenly, it will report that here also with a message such as: time reset -6.394626 s.
#####################
NTP SERVER
#####################
Install NTP server in Debian
===========================
#apt-get install ntp ntpdate ntp-server
This will install all the required packages for NTP
Configuring NTP Server
======================
By Default main configuration file located at /etc/ntp.conf
Default configuration file looks like below
#/etc/ntp.conf, configuration for ntpd
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example
# pool.ntp.org maps to more than 300 low-stratum NTP servers.
# Your server will pick a different set every time it starts up.
# *** Please consider joining the pool! ***
# *** ***
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst
# By default, exchange time with everybody, but don’t allow configuration.
# See /usr/share/doc/ntp-doc/html/accopt.html for details.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1
# Clients from this (example!) subnet have unlimited access,
# but only if cryptographically authenticated
#restrict 192.168.123.0 mask 255.255.255.0 notrust
# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255
# If you want to listen to time broadcasts on your local subnet,
# de-comment the next lines. Please do this only if you trust everybody
# on the network!
#disable auth
#broadcastclient
Example Configuration
======================
You need to add a number of servers to the server list. The Debian default is pool.ntp.org which works but isn’t always amazingly accurate because it makes no attempt to use time servers near you. If you want more accuracy use the time servers either on your continent (for instance europe.pool.ntp.org) or your country (for instance uk.pool.ntp.org) one of your local country servers.The optimal number of servers to listen to is three but two will also give a good accuracy. If your ISP runs a time server for you it is worth including it in your server list as it will often be more accurate than the pooled servers and will help keep the load down on the pool.
I am using the following two servers for my configuration
server ntp0.pipex.net
server ntp1.pipex.net
Restrict the type of access you allow these servers. In this example the servers are not allowed to modify the run-time configuration or query your Linux NTP server.
restrict otherntp.server.org mask 255.255.255.255 nomodify notrap noquery
restrict ntp.research.gov mask 255.255.255.255 nomodify notrap noquery
The mask 255.255.255.255 statement is really a subnet mask limiting access to the single IP address of the remote NTP servers.
If this server is also going to provide time for other computers, such as PCs, other Linux servers and networking devices, then you’ll have to define the networks from which this server will accept NTP synchronization requests. You do so with a modified restrict statement removing the noquery keyword to allow the network to query your NTP server. The syntax is:
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
In this case the mask statement has been expanded to include all 255 possible IP addresses on the local network.
We also want to make sure that localhost (the universal IP address used to refer to a Linux server itself) has full access without any restricting keywords
restrict 127.0.0.1
Save the file and exit
Now you need to run the ntpdate command against your server
#ntpdate ntp0.pipex.net
restart NTP for these settings to take effect using the following command
#/etc/init.d/ntp restart
You can now configure other Linux hosts on your network to synchronize with this new master NTP server in a similar fashion.
Determining If NTP Is Synchronized Properly
=============================================
Use the ntpq command to see the servers with which you are synchronized. It provided you with a list of configured time servers and the delay, offset and jitter that your server is experiencing with them. For correct synchronization, the delay and offset values should be non-zero and the jitter value should be under 100.
#ntpq -p
Output looks like below
A star by any one of the names means that the system clock is synchronising with the NTP clock. If you don’t have a star (as in the example above) it means that the clocks are unreachable, already synchronized to this server or has an outrageous synchronization distance. Try running ntpdate (you will need to stop the ntp server) with your first ntp server as an argument. This will set your system clock fairly accuratly and mean that the server will be able to choose a clock to synchronize with.
Firewall Configuration for NTP
================================
NTP servers communicate with one another using UDP with a destination port of 123. Unlike most UDP protocols, the source port isn’t a high port (above 1023), but 123 also. You’ll have to allow UDP traffic on source/destination port 123 between your server and the Stratum 1/2 server with which you are synchronizing.
|