Network Time Protocol (NTP): Für und Wider?!

[BenutzerGa4gooPh]

Die Überschrift sagt eigentlich alles. In diversen Threads wurde NTP angeschnitten, teilweise (unterschwellig) abgelehnt. Ich bitte euch darum, Unterschiede für Desktop-PCs und Server zu berücksichtigen. Schon bei der jährlichen Zeitumstellung fehlt im Extremfall eine Stunde in Logs? Des Weiteren gibt es Alternativen zu NTP:
https://de.wikipedia.org/wiki/Network_Time_Protocol

[DeletedUserReAsG]

Hättest du mal ein Beispiel für einen Beitrag, in dem es abgeleht wurde? Ich wüsste nicht, was generell gegen das Protokoll spräche, von Ausnahmen mal abgesehen. Allerdings gibt es mehrere Möglichkeiten, sich dessen zu bedienen und da gibt’s z.B. durchaus welche, die nicht sehr feinfühlig sind und Programme durcheinanderbringen können (ntpdate wäre da so’n Kandidat). Dem gegenüber stehen Programme, welche die Zeit kontinuierlich anpassen und syncron halten. Den Sonderfall Sommer-/Winterzeit mal außen vor gelassen (imho haben Server eh mit UTC zu laufen), wüsste ich nicht wirklich, was dagegen spricht.

[BenutzerGa4gooPh]

Hättest du mal ein Beispiel für einen Beitrag, in dem es abgeleht wurde?

Nicht so richtig, ist mehr so ein Bauch-Gefühl aus mehreren Beiträgen, deshalb auch der Thread zur Klärung. Eine Suche fällt mir entsprechend schwer.

imho haben Server eh mit UTC zu laufen

Dem stimme zu. Aber wie? Lokalzeit/BIOS? Und Desktop-PCs, Clients vs Servern?

[MSfree]

Schon bei der jährlichen Zeitumstellung fehlt im Extremfall eine Stunde in Logs?

Nein, zumindest bei Linux und Unix nicht. Bei unixoiden Betriebssystem läuft intern ohnehin alles in UTC ab und UTC kennt keine Sommer- und Winterzeit. Die Zeit, die dir vom System angezeigt wird, ist immer eine in "Realtime" auf deine Zeitzone umgerechnete Uhrzeit. Dadurch sind Logs überhaupt nicht betroffen, die laufen einfach ganz normal weiter:

Zum Zeitpunkt der Zeitumstellung stehen in meinem Log z.B. folgende Einträge:

Code: Alles auswählen

Oct 30 02:59:42 viaduct kernel: incoming: ...
Oct 30 02:00:00 viaduct kernel: incoming: ...

Man sieht hier sehr schön, daß die lokale Uhrzeit einfach um eine Stunde zurück geschaltet hat, der Rest ist völlig unbetroffen.

[BenutzerGa4gooPh]

Ja gut. In mein journalctl -b greift ntp ein, verstellt oder stellt die Uhrzeit korrekt. Desktop-PC, kein Problem. Aber Server Logs?
Na, macht was aus dem Thread, ich höre erst mal zu.

[DeletedUserReAsG]

Auch in den Serverlogs steht der Timstamp fortlaufend.

[MSfree]

Ja gut. In mein journalctl -b greift ntp ein, verstellt oder stellt die Uhrzeit korrekt. Desktop-PC, kein Problem. Aber Server Logs?

Wie gesagt, da wird gar nichts verstellt. Einzig der Umrechnungswert, wie viele Stunden (und Minuten) deine aktuelle Winter/Sommer-Zeitzone von UTC entfernt ist, ändert sich. Die Zeitmarken im Journal werden einfach immer in UTC geschrieben und vom Porgramm journalctl entsprechend umgerechnet ausgegeben.

In meinen (Server)logs kümmert sich rsyslogd darum, daß die Zeitmarke vor dem Schreiben des Logtextes in die Lokalzeit umgerechnet wird.

[spiralnebelverdreher]

Auch in den Serverlogs steht der Timstamp fortlaufend.

Trifft das für alle Logs zu wenn am Ende des Jahres mal wieder eine schaltsekunde eingefügt wird? UTC enthält per Definition die schaltsekunde, aber logt dein serverprozess das auch so oder steht da dann 23:59:58 23:59:59. 23:59:59. 00:00:00 00:00:01 ?

[MSfree]

Auch in den Serverlogs steht der Timstamp fortlaufend.

Trifft das für alle Logs zu wenn am Ende des Jahres mal wieder eine schaltsekunde eingefügt wird?

Ja, und zwar zwangsläufig.

Der Logprozeß ruft im Falle von (r)syslogd die Funktion localtime und im Falle von journlad gmtime auf, trägt die Zeit entsprechend in der Logdatei ein und hängt den Meldungstext dahinter. Ob local/gmt-time nun eine Schaltsekunde enthält oder nicht, ist an der Stelle völlig egal. Die Meldungen kommen immer streng in der Reihenfolge in die Logdatei, in der sie vom Logprozeß empfangen wurden, die Zeit wird dann als "Dekoration" noch davor geschrieben. Daher ja auch eine Ausgabe, wie in meinem Beispiel weiter oben, wo die Uhrzeit scheinbar rückwärts läuft zum Zeitpunkt der Zeitumstellung.

[dufty2]

Des Weiteren gibt es Alternativen zu NTP:
https://de.wikipedia.org/wiki/Network_Time_Protocol

Die in dem wiki-Artikel 3 genannten sind keine wirkliche Alternativen:
PTP ist fürs LAN, aber nicht fürs WAN gedacht,
Ntimed ist eine neuere Implementierung von NTP,
und tlsdate ist mehr oder weniger auch nur eine Art Implementierung.

Mach mal ein

Code: Alles auswählen

$ grep time /etc/services

dann siehst Du die Alternativen (aus vergangenen Jahrhunderten-ähem-zehnten ).

Eine daraus wollen wir hervorheben, die "Implementierung" ist einfach zu Unixoid

Code: Alles auswählen

$ cat < /dev/tcp/time.nist.gov/13

[BenutzerGa4gooPh]

Also nichts spricht gegen NTP - weder auf Servern noch auf Clients. Locales von Server (umgerechnete Anzeigen/Ausgaben) lässt man wohl sicherheitshalber auf UTC.

Spricht was dagegen, diese auf UTC+1 ohne Sommer-/Winterzeit zu stellen? Könnte mir eventuell Probleme mit Fremdservern auf UTC+0 vorstellen .,. .

Und das finde ich richtigt spitzfindig - interessant

Auch in den Serverlogs steht der Timstamp fortlaufend.

Trifft das für alle Logs zu wenn am Ende des Jahres mal wieder eine schaltsekunde eingefügt wird? UTC enthält per Definition die schaltsekunde, aber logt dein serverprozess das auch so oder steht da dann 23:59:58 23:59:59. 23:59:59. 00:00:00 00:00:01 ?

MSFrees AW mit Analogie zur Zeitumstellung klingt plausibel:

Die Meldungen kommen immer streng in der Reihenfolge in die Logdatei, in der sie vom Logprozeß empfangen wurden, die Zeit wird dann als "Dekoration" noch davor geschrieben. Daher ja auch eine Ausgabe, wie in meinem Beispiel weiter oben, wo die Uhrzeit scheinbar rückwärts läuft zum Zeitpunkt der Zeitumstellung.

Danke euch allen!

[MSfree]

Also nichts spricht gegen NTP - weder auf Servern noch auf Clients.

Das einzige, was eventuell gegen NTP ansich spricht, ist, daß es wohl Schwachstellen in der Software gibt/gab.
https://portal.cert.dfn.de/adv/DFN-CERT-2016-0898/

In meinem LAN habe ich den Zugriff auf NTP-Server im Internet gesperrt und leite locale LAN-Clients per Portforwarding auf meinen eigenen NTP-Server um. Ganz paranoide Naturen können den eigenen NTP-Server z.B. an einen Zeitzeichenempfänger (Raspi plus DCF77-Modul) oder einen GPS-Empfänger hängen und sind dann völlig unabhängig von möglicherweise gekaperten NTP-Servern im Internet.

Locales von Server (umgerechnete Anzeigen/Ausgaben) lässt man wohl sicherheitshalber auf UTC.

Das ist nicht nötig. Im Kernel läuft die Uhr ohnehin in UTC, die locales bzw. TIMEZONE greifen in keiner Weise in die Funktion der Uhr ein, die werden nur als Korrekturwert von der C-Funktion localtime berücktsichtigt. Diese Funktion wird von allen relevanten Programmen aufgerufen, also auch den diversen Shells, aber auch Python, PHP und anderen interprätierten Sprachen.

[hikaru]

Spricht was dagegen, diese auf UTC+1 ohne Sommer-/Winterzeit zu stellen?

Vielleicht die komplette Verwirrung?
Wenn man schon mal dabei ist, sich von dem ganzen Zeitzonengeraffel zu befreien, dann sollte man mMn den ganzen Weg gehen und nicht in der Mitte stehen bleiben. Aber ich mag da auch voreingenommen sein, als jemand, der UTC selbst auf seiner Armbanduhr hat.

[wanne]

Gab immer wieder Propleme mit amplifications bei DDOS attacken. Sonst spricht absolut nichts gegen NTP.

Trifft das für alle Logs zu wenn am Ende des Jahres mal wieder eine schaltsekunde eingefügt wird? UTC enthält per Definition die schaltsekunde

Deswegen nutzt ein vernünftiges betriebssystem (Also nicht DOS. Sogar Windows hat das seit dem Milleniums Bug mittlerwerweile an fast allen Stellen hinbekommen.) intern nicht UTC sondern Unixtime.

[MSfree]

Deswegen nutzt ein vernünftiges betriebssystem intern nicht UTC sondern Unixtime.

Nunja, Unixtime sind Sekunden seit 1.1.1970 0.00h UTC.

[TomL]

Hättest du mal ein Beispiel für einen Beitrag, in dem es abgeleht wurde?

Nicht so richtig, ist mehr so ein Bauch-Gefühl aus mehreren Beiträgen

Ich habe das schon öfter mal gesagt, dass ich ntp und rsyslog als allererstes deinstalliere. Vielleicht hängt das auch ein wenig mit deinem Bauchgefühl zusammen. Ich meine aber damit nicht, dass die beiden schlecht sind oder so etwas, ganz im Gegenteil... ich nutze solche Dienste selbstverständlich auch. Nur eben statt der traditionellen Programme bin ich umgestiegen auf systemd-timesyncd und systems-journald. Für mich sind beide Dienste unverzichtbar.

[BenutzerGa4gooPh]

Nun wurde Jana sogar vom Verdacht auf Halluzinationen (oder Demenz) freigesprochen.

(Nehme so nach und nach eine Firewall in Betrieb und dabei kommen mir alte Threadbeiträge in den Sinn, die ich nicht mehr alle finde.)

[TomL]

(Nehme so nach und nach eine Firewall in Betrieb und dabei kommen mir alte Threadbeiträge in den Sinn, die ich nicht mehr alle finde.)

Schau Dir das mal an. Ich empfand das als lehrreich und es hat mir bei der Entwicklung meiner iptables geholfen. Hast Du keine Lust dafür mal nen eigenen Thread zu starten? Vielleicht gibts ja noch mehr Interessenten, die sich beteiligen und vielleicht auch noch Lernbedarf haben.

[BenutzerGa4gooPh]

Hallo Thomas,
also ich "mache die FW auf Blech":
http://www.qotom.net/goods-129-QOTOM-Q1 ... ni+PC.html
https://forum.pfsense.org/index.php?topic=114202.0
Dazu mag ich vorrangig eine spezialisierte Distribution einsetzen, ne FW ist kompliziert genug. Egal was man/frau über GUIs denkt, jedenfalls braucht man sich keinen Kopf über die Syntax zu machen, die FW-Semantik (Regeln) ist wesentlich und kritisch. Sicherheit kommt auch von Einfachheit und Übersichtlichkeit (GUI-Darstellung). Derzeit Konfiguration per Webbrowser von PFSense (ClearOS vorerst beiseite gelegt, war mir erst mal nicht intuitiv genug), schnelle Erfolge sind für die Seele wichtig. Jedenfalls mit meinem Netzwerk-Überblickswissen hatte ich meine funktionellen Erfolge (per Webbrowser) sehr schnell.

Unabhängig davon sehe ich für bestimmte Einsatzzwecke (z. B. Laptop an häufig wechselnden, öffentlichen Hotspot für "Weltreisende") eine Desktop-FW ein. Bin von LANCOM-Routern jedoch etwas vorgeprägt: Objektorientierte FW. Es gibt auch objektorientierte Desktop-FWs. Objektorientierte GUIs, die auf iptables & Co. zurückgreifen, diese objektorientiert konfigurieren. Name müsste ich suchen, wenn es denn interessiert. Hatte das vor langer Zeit mal recherchiert, nie getestet.

Ist vlt ne kleine Macke von mir, aber gerade bei FW mag ich Übersichtlichkeit, schnelle Änderungsmöglichkeiten und dadurch wenig Fehlerquellen. Sorry, soll keine Abfuhr sein, wohl eher eine persönliche "Philosophiefrage"

Gern mache ich einen speziellen Thread, Erfahrungsbericht, wenn ich mit meiner Sache fertig bin. Ich gebe auch nicht so schnell auf, ClearOS ist zwar nicht mehr installiert (war nur schnell genervt), teste das diese Woche nochmals per VM/VBox. So es denn geht, 2 phys. Schnittstellen hat mein Lappi (LAN, WLAN). Mit PSense habe ich die einzigen "Luxusprobleme": kein UEFI, kein SSD-Alignment per Legacy/CSM/MBR auf dem Qotom-Mini-PC mit prima AMI-BIOS. Funktionalität von PFSense bestens, Bedienphilosophie etwas gewöhnungsbedürftig aber schnell erfassbar. Darstellungen der Konfigurationen übersichtlich, Installation easy.

Aufgrund des neuen Threads viewtopic.php?f=30&t=162963 kam mir noch ein Gedanke: Auf "Blech" eine Debian-Minimalinstallation mit shorewall
https://de.wikipedia.org/wiki/Shorewall
Deine AW im genannten Thread hatte ich nicht gelesen, als ich schrieb. Nun werde ich erstmal den Thread verfolgen.

Wir sollten wohl splitten/unterscheiden: Desktop-FW und "FW in Blech", für letztere spezielle Distris. Ich tue nur für "Blech-Distris".
(mangelnder Bedarf für Desktop-FWs, "rohe" ip tables etc.)