Endnu et projekt...

Hvis vi er i gang med at skære overflødig kompleksitet væk, er SNTP så ikke rigeligt til størstedelen af denne klients målgruppe?

Kan du ikke skynde dig lidt med at release? :-)

Dec 19

The Network Time Protocol (NTP) provides networked systems with a way to synchronize time for various services and applications. ntpd version 4.2.7 and pervious versions allow attackers to overflow several buffers in a way that may allow malicious code to be executed. ntp-keygen prior to version 4.2.7p230 also uses a non-cryptographic random number generator when generating symmetric keys.

Source: http://www.kb.cert.org/vuls/id/852879 og der er flere artikler om det.

Jo, hvis jeg ellers kunne finde min tidsvender... :-)

Du kan låne min, men skynd dig at levere den tilbage, jeg skal bruge den igår.

Hvad er fordelen ved dette projekt frem for OpenNTPD ( http://www.openntpd.org/ )? (Udover at OpenNTPD ikke lader til at have en maintainer uden for OpenBSD...)

OpenNTPD lader til at bestå af 3843 SLOC, inklusive server og klient. Jeg ved dog intet om featuresæt eller begrænsninger i forhold til dine behov.

OpenNTPD har elendig tids-styring og giver ikke rigtig nogen platform for viderudvikling/kodedeling til stratum 1 servere mv.

Efter at have læst op på det, så er det også hvad jeg kom frem til (og især at OpenNTPD bare er en SNTP-implementering). Min umiddelbare konklusion er at OpenNTPD er OK til perifære klient-knuder i NTP-netværket (som f.eks. min hobbyserver), men ikke ret meget andet. Og man skal have det OK med at komme nogle millisekunder for sent til møder fra tid til anden.

Meget spændende - lad os endelig høre mere løbende og ser frem til den første endelige release.

Mener at det 4'e øverste apparat i stakken t.v. er en frekensnormal. Kan i øvrigt huske, at min far, der var ingeniør i SAS, fortalte om eksperimentet med "the flying clocks". Urene fløj med Swissair til Europa og på det tidspunkt havde SAS og Swissair et meget tæt teknisk samarbejde.

Det lyder spændende med den nye NTP klient. Er i øvrigt røget ind i phkmalloc i forbindelse med mine undersøgelser omkring secure C programming.

Fandt lige et billede på "www.hpmemory.org" hvor man kan se hvordan en af disse "Flying Clocks" er på vej ombord på en SAS DC-7C fly.

Nogen chance for at ntimed er så simpel og velskrevet at den ville kunne formelt verificeres?

...når den bruges som server ?

Hos mig (hhv. SuSE og OpenSuSE) kører ntpd i øvrigt pr. default i chroot jail uanset om den kører som ntp server eller ntp client.

Har du hentet noget input Fra Henning Brauer? Ser overordnet rigtig spaendende ud, vil gerne bygge en OpeBSD port.

Har du hentet noget input Fra Henning Brauer?

Næppe

Hvad med den oven på din computer. Hvad laver den?

Maskinen til højre for tower PC'en er formodentligt din SDR Loran-C modtager. Jeg har svært ved at finde en SRS PRS10, men antager at den befinder sig under "den hvide køleplade" til venstre for tower PC'en.

Hej Poul-Henning,

Her i SmartShare Systems har vi også udviklet en NTP-klient til vores produkter, og jeg vil gerne dele lidt af den viden, vi har herfra - i håb om at du kan få gavn heraf i dit særdeles tiltrængte projekt. Jeg har ikke kigget på din kode, så måske tager du allerede højde for nogle af disse detaljer.

1. I SmartShare Systems udvikler vi båndbreddestyringsprodukter, der bl.a. kan reducere latency for brugerne af en internetforbindelse, og vi ved derfor, at de fleste internetforbindelser ind imellem bliver udsat for spidsbelastninger, hvor latency stiger med adskillige millisekunder, ofte mere end 100 ms. Længerevarende spidsbelastninger kan skyldes "busy hour", hvor mange brugere er aktive samtidig, og kortvarige spidsbelastninger kan skyldes bursty netværkstrafik, fx at en webserver afleverer en stor mængde data på meget kort tid. Vores NTP-klient holder øje med den sædvanlige RTT til NTP-serveren, og hvis den modtager et NTP-svar med en væsentligt højere RTT end normalt, antager vi, at der var forhøjet latency på forbindelsen (enten længere ude på internettet eller på "the last mile", dvs. på den lokale internetforbindelse), og kasserer svaret som ubrugeligt. (Det er en almindelig reguleringsopgave at holde styr på den sædvanlige RTT til NTP-serveren. Og det er en definitionssag, hvad der er en væsentligt højere RTT end normalt.)
2. Nogle NTP-servere sætter tidsstemplerne i pakkerne ud fra en systemtimer, der tikker med en frekvens under 100 Hz, dvs. der er mere end 10 ms jitter på svarene herfra. Dette har vi bl.a. observeret ved NTP-servere hos en meget stor Content Delivery Network-udbyder, der bl.a. leverer tidsservice for et meget udbredt operativsystem.
3. Mange offentligt tilgængelige NTP-servere på internettet, bl.a. dem hos pool.ntp.org (som også er et glimrende initiativ), er helt ude af synkronisering.

mvh Morten Brørup CTO, SmartShare Systems

... en flux capacitor! Måske derfor du arbejder på en tidsklient, så du kan holde styr på rejserne ?

Godt nytår, vi ses i 1915 ;-)

Lidt pop info om tid: Nye atom ure er super praecise og maaler taet paa "sand" space-time continuum tid. Det betyder at to ure aldrig vil vise samme tid da de er to forskellige ure i tid og rum. Tid er tilsyneladende en funktion af tyngekraft. Man fristes til at spoerge hvad tid egentlig er for en stoerrelse?

http://www.livescience.com/39096-new-atomic-clock-built.html

/Jan

Pga. julen har jeg først set dette indlæg nu. Men det er alligevel den bedste julegave jeg har fået i år. Jeg har ansvaret for et stykke over 100 servere og jeg ved ikke hvor mange gange jeg har været ved at rykke håret af mig selv over den gamle NTPD.

Jeg har aldrig forstået hvorfor det var en god idé at det program som alle bruger til at sætte uret som udgangspunkt er beregnet til at være server, ikke klient. Det er helt sort. Og rækken af problemer det har givet i tidens løb, er da også lang.

At det så er PHK der er ved at skrive en erstatning, gør blot min entusiasme endnu større. Jeg vil straks installere på et test-system og vente spændt på et "produktions-release".

Det er lige som juleaften... bare mere spændende.