Unix-tips: NTP-kommandon
ITworld.com – Skicka in dina Unix-frågor idag!
Se fler Unix-tips och -tricks
Förra veckans spalt presenterade vi NTP, Network Time Protocol, och konceptet med mycket noggrann tidtagning. Även om det finns många kommandon som hjälper systemadministratörer att hålla ganska exakt tid på de system de förvaltar, är de mest uppenbara mycket begränsade. Som ett resultat av detta lider de flesta nätverk av stora avvikelser i systemtiden. Tidsskillnader som de som visas nedan (tagna från ett verkligt nätverk) är inte ovanliga:
host01: Thu Oct 14 10:50:23 EDT 2004
host02: Thu Oct 14 10:43:53 EDT 2004
host03: Thu Oct 14 10:41:52 EDT 2004
host04: Thu Oct 14 10:50:13 EDT 2004
host05: Thu Oct 14 10:33:59 EDT 2004
host06: Thu Oct 14 14:48:17 GMT 2004
host07: Thu Oct 14 10:52:04 EDT 2004 *
host08: Thu Oct 14 10:52:33 EDT 2004
host09: Thu Oct 14 10:49:55 EDT 2004
host10: Thu Oct 14 10:33:33:20 EDT 2004 *
host11: Thu Oct 14 10:51:22 EDT 2004
Bara inom dessa elva sekventiellt avlyssnade system kan vi se en betydande variation i den rapporterade tiden. Även om omröstningarna ägde rum inom loppet av några sekunder är tidsskillnaderna betydligt större än några sekunder. Det är faktiskt en skillnad på 18 minuter och 44 sekunder mellan den tidigaste och senaste rapporterade tiden. Om vi hade gjort en omröstning i hela nätverket skulle skillnaden mellan den tidigaste och senaste rapporterade tiden ha varit ännu större.
För att tvinga system som dessa att ligga närmare varandra i tid kan systemadministratören använda något av ett antal kommandon med varierande framgång.
Datakommandot
Datakommandot, som gör det möjligt för systemadministratören att ställa in datum och tid, är det mest uppenbara kommandot för att korrigera tiden i ett system, men det är beroende av att systemadministratören har en ganska noggrann tidsreferens. Det här kommandot körs också ett system i taget. Om en systemadministratör använder datumkommandot för att synkronisera två system är det osannolikt att han eller hon kan få systemtiderna närmare än inom några sekunder från varandra. Date-kommandot är helt klart inte det bästa kommandot när synkronisering är viktig. Och i ett nätverk med flera hundra system kan detta tillvägagångssätt vara både omständligt och felaktigt.
Om en systemadministratör skulle utfärda ett datumkommando i en slinga som den som visas nedan, skulle systemtiderna ligga närmare varandra än de som visas ovan, men skulle fortsätta att variera med så många sekunder som slingan tog att slutföra. Och naturligtvis kommer denna tidsvariation att bli alltmer betydande om ett lösenord måste anges för varje ssh-kommando.
for host in `cat host_list`do ssh $host "date 10141045"done
Datumkommandot är uppenbarligen endast minimalt användbart för att synkronisera system. Systemklockor som tenderar att vinna eller förlora tid, även om det bara rör sig om ett par sekunder varje dag, kommer snabbt att öka tidsskillnaderna igen. Dessutom skulle system som är konfigurerade för andra tidszoner – t.ex. det system som rapporterar tiden som GMT i listan ovan – få sina klockor förskjutna med flera timmar om vi använde datumkommandot på det sätt som visas.
Kommandot rdate
Kommandot rdate, som är ett mycket bättre val för att synkronisera klockor i ett nätverk, kräver att en systemadministratör väljer ut ett system som är tillgängligt för hans/hennes nätverk, förmodligen ett system som håller en ganska exakt tid och som kan användas som tidsreferens för resten.
Följande slinga skulle ge mycket bättre resultat än den som visas ovan. Den tid som krävs för att slutföra denna slinga kommer trots allt inte att ha någon negativ effekt eftersom varje rdate-kommando kommer att synkroniseras med tiden på referensservern när det kommandot körs.
for host in `cat host_list`do ssh $host "rdate timekeeper"done
Det är dessutom så att rdate-kommandot inte åsidosätter tidszonen på målsystemet. Istället för att ställa in tiden bokstavligen till ett värde som anges på kommandoraden begär rdate tidsdata som är oberoende av tidszonen. Med andra ord, om du kör ”rdate ” på ett system som använder GMT kommer tiden på GMT-systemet att ställas in korrekt.
Kommandot rdate körs i allmänhet vid systemstart eller via cron en gång om dagen eller en gång i timmen för att justera klockorna på system i ett LAN. Jämfört med de odisciplinerade systemklockorna som visades tidigare är detta en stor förbättring. Ur synvinkel för varje system vars klocka ställs om med rdate kan dock några mycket ovanliga saker hända. Klockorna kan hoppa framåt eller bakåt i tiden varje gång kommandot rdate körs. Detta beteende kan leda till mycket märkliga tolkningar av tidskänsliga händelser.
NTP-kommandon
NTP har helt klart avsevärda fördelar jämfört med kommandona date och rdate. För det första ger NTP ett sätt att synkronisera systemklockor med ovanlig precision och att göra nödvändiga justeringar på ett smidigt sätt, så att man undviker de hopp i tiden som kommandon som rdate ofta orsakar. Låt oss ta en närmare titt.
NTP tillhandahåller två kommandon för tidsjustering: kommandot ntpdate – som ställer in systemtiden ungefär som kommandot rdate gör (dvs, genom att referera till ett fjärrsystem för att få fram den aktuella tiden) och NTP-demonen — ntpd eller xntpd — som tillhandahåller en mycket mer utarbetad mekanism för att komma fram till och synkronisera till rätt tid.
Kommandot ntpdate
Kommandot ntpdate — som i allmänhet används, precis som kommandot rdate, vid uppstart av systemet, på begäran eller periodiskt genom cron — synkroniserar tiden på ”ad hoc”-basis på ett liknande sätt som rdate. Kommandot ntpdate har dock två mycket viktiga fördelar jämfört med rdate.
För det första hänvisar ntpdate till en NTP-server, inte bara till en pålitlig tidtagare som är tillgänglig i ditt nätverk. Eftersom NTP-servrar i allmänhet är knutna till NTP-hierarkin (och i slutändan till en mycket noggrann atomklocka) är de nästan garanterat mer exakta än en server som helt enkelt har ett bra klockchip.
För det andra kan ntpdate samla in ett antal tidsprover från ett antal tidskällor (dvs. flera NTP-servrar) och sedan välja den tid som verkar mest exakt. Så kommandot ntpdate hänvisar inte bara till en tidskälla som med större sannolikhet är exakt än de som valts ut för användning med rdate, utan det hänvisar också till ett antal sådana system och tillämpar en sofistikerad urvalsprocess.
Ett ntpdate-kommando kan se ut så här:
# ntpdate 129.6.15.28
14 Oct 10:52:41 ntpdate: adjust time server 129.6.15.28 offset -0.003350 sec
Om ntpdate-kommandot är installerat på ditt system (/usr/sbin/ntpdate på de flesta Solaris-system) kan du faktiskt pröva just det ntpdate-kommandot just nu. Referensservern i det här exemplet är en NTP-server på NIST i Gaithersburg, Maryland.
Alternativt kan du prova ett ntpdate-kommando som detta:
# ntpdate 129.6.15.28 216.200.93.8 208.184.49.9
14 Oct 14:57:41 ntpdate: Justera tidsservern 216.200.93.8 offset 0.015733 sec
I det här fallet frågas flera NTP-servrar.
NTP-daemon
Men medan ntpdate-kommandot ger en tidsstyrning som är en storleksordning bättre än rdate, går NTP-daemon ett gigantiskt steg längre än ntpdate med sina sofistikerade algoritmer för att maximera noggrannhet och tillförlitlighet. Rätt använd använder NTP daemon också en minimal mängd nätverksresurser — vi kommer att undersöka denna fråga nästa vecka.
NTP daemon tillhandahåller sofistikerade algoritmer som smidigt synkroniserar systemklockor genom en process av successiv approximation. Ju längre daemon körs, desto närmare stämmer systemtiden med källans tid. Den gör stora justeringar snabbt och sedan mindre justeringar med tiden för att undvika att överskrida den korrekta tiden.
Det kan ta NTP minuter eller timmar att närma sig en fin nivå av noggrannhet, men när den väl gör det kan systemets tidstillförlitlighet vara häpnadsväckande exakt. Med detta sagt är NTP:s tidsnoggrannhet dock i slutändan knuten till noggrannheten hos de tidskällor som systemet hänvisar till. Varje NTP-server försöker synkronisera till UTC (Universal Coordinated Time) med hjälp av den bästa tillgängliga tidskällan och överföringsvägen. Om de servrar som det hänvisas till sänder tider som inte ligger nära varandra, kommer NTP att betrakta en eller flera av dessa tidsservrar som trasiga och bortse från dem. För att få en exakt tid med hjälp av NTP måste ditt val av tidsservrar vara korrekt.
Nybörjare av NTP bör notera att det inte nödvändigtvis gör ett system till en NTP-server om det körs med NTP daemon-processen. Huruvida ett NTP-aktiverat system spelar rollen som klient eller server bestäms av daemonens konfigurationsfiler på det systemet – något som vi ska undersöka i nästa veckas kolumn.
Denna artikel, ”Unix Tip: NTP Commands” publicerades ursprungligen av ITworld .