Hallo Tobias,
oben hatte ich das nicht richtig beantwortet…
IMHO wird auf den Clients weder chrony noch zusätzlich ntp auf aktuellen Debian und Ubuntus benötigt, hier reicht der Standard timesyncd aus, siehe
oben unter „Achtung!“
und https://wiki.ubuntuusers.de/systemd/timesyncd/
hier kommt der lokale (!) NTP Server rein (bei uns der „server“) fertig.
Grüße,
gerd
Hallo Gerd,
danke. Das bisherig am weitesten verbreitete cloop von Dominik und Holger hat den chrony drauf. Ich werde mit Ubuntumate jetzt auf timesyncd setzen und „server“ einsetzen, mal sehn, ob das auch geht.
VG, Tobias
Huch, mir fällt gerade auf, dass ich bei mir für den CLIENT da auch die Firewall rein habe. Ist evtl. nicht so gedacht… Ich schreib mal besser den server bzw. dessen IP rein.
VG, Tobias
ja, so wie weiter oben (?) zu lesen ist, soll wohl offiziell und gegenwärtig die Firewall den NTP Außenkontakt herstellen, so dass auch im NTP des Schulservers die Firewall rein soll.
Fakt ist in einer Standard Windows AD-Domäne ist der DC Standardmäßig der lokale Zeitserver.
Ich verwende daher auch lokal den DC (=Schulserver / Samba4).
In der LMLv7 sollte beides funktionieren. Auch wenn der Schulserver die „Zeit“ von der Firewall holt, kann er selbst wiederum diese lokal weiter reichen. Wichtig finde ich, dass man vor allem nicht überall öffentliche Zeitserver einträgt, nach dem Motto „geht doch“…
Ich kenne das letztendlich gewünschte Timeserver Setup der Entwickler nicht.
Weiß aber, wie ich es funktionierend zum Laufen bekomme 
Grüße,
gerd
Was gpeter hier schreibt ist das korrekte Vorgehen.
Gedacht ist folgender Aufbau:
Client -> Server (AD Controller) -> Firewall -> Öffentlicher Zeitserver
Und ist auf dem Server aktuell der von Gerd oben beschriebene AD-konforme Zeitserver konfiguriert? Falls (noch) nicht: ist angedacht, das zentral zu ändern oder müsste da jeder selbst ran?
Danke und Grüße,
Jochen
Hallo!
Habe es mal in die Struktur eingepflegt. structure_of_version_7_more_detailed.pdf (475,1 KB)
Wo bei ich die Richtung gedreht habe. Vom öffentlichen Zeitserver zu den lokalen. Passt das so?
Beste Grüße
Thorsten
Hallo zusammen,
ich greife das nochmal auf, weil ich a.) der Meinung bin, dass laut Gerd
und b.) Gerd sich wohl auskennt, es sich bei ihm laufbar macht, aber
Ich kann nur rückmelden:
ja, das hat geklappt, bei mir stehen aber beim Server zwei „pool“ Einträge: die Firewall IP und pool.ntp.org
Nein, ntpsignedsocket steht bei mir nicht in der /etc/ntp.conf
Auch das nicht, das schalte ich aber als erstes ein.
Außerdem schlug Gerd vor die Option -4 für IPv4 in /etc/default/ntp zu setzen. Warum, habe ich nicht ganz verstanden, zumindest weniger Fehler danach.
Ich sehe das grade so: es gibt scheinbar kein Problem, aber ordentlich gemacht scheint es mir auch nicht, denn meine Vermutung: solange bei mir „pool pool.ntp.org“ eingetragen ist, wundert es mich auch nicht, dass ich als Antwort auf meinem Server das hier bekomme:
root@server(Humboldt):~# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.16.1.254 .POOL. 16 p - 64 0 0.000 0.000 0.000
pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.000
-firewall.linuxm 217.172.180.40 4 u 641 1024 377 0.507 -2.132 2.933
+static.29.14.20 158.75.5.245 2 u 385 1024 377 24.897 -0.181 2.004
+spacys.de 131.188.3.222 2 u 460 1024 377 25.268 -1.124 7.431
-ernie.gerger-ne 213.172.96.14 2 u 644 1024 377 20.894 -0.360 6.161
-tped-ptl-t01.sm 5.147.240.110 3 u 616 1024 377 24.020 -2.012 7.364
+batleth.sapient 131.188.3.222 2 u 60 1024 377 25.782 -2.915 3.562
*195.50.171.101 192.53.103.108 2 u 113 1024 377 22.844 -0.751 2.678
+ns1.customer-re 192.53.103.104 2 u 978 1024 377 25.822 -0.568 1.999
Was mich noch stutzig macht ist das bei der firewall ein „-“ davor steht und nicht das „*“…
Ich nehme es zurück, ntpdate funktioniert doch. Weiß nicht, woran ersteres Problem lag.
Da habe ich mal noch getestet, ob ich denn von der firewall meine Zeit beziehen kann, in dem ich ntpd ausschalte, ntpdate firewall aufrufe und danach ntpd wieder anschalte.
Das klappt gar nicht. Da scheint die Firewall gar nicht zu reagieren. Vermutlich fehlt da noch eine Regel…
@gpeter: kannst du nochmal sagen, ob
a.) der eintrag ntpdsigndsocket wirklich notwendig zum betrieb ist, das scheint der patch von damals nicht eingetragen zu haben
b.) man noch einen weiteren pool neben der firewall haben sollte
c.) du empfehlen würdest auch im default-fall das logging anzuschalten
d.) ob denn ein ntpdate firewall funktionieren müsste.
e.) ob das ipv4 auch immernoch von dir empfohlen würde, auch im default fall.
VG, Tobias
EDIT: noch was fällt mir auf: warum hast du „server“ einträge und ich einen bzw. zwei „pool“ einträge?
Ich bekomme übrigens nur mit dem logging eingeschalten keine Fehlermeldung, weder zu ipv6 noch zu anderen problemen.
Jetzt habe ich neben logging einschalten auch noch den pool ntp.org auskommentiert. JETZT, steht nach einer Weile auch das „*“ bei der firewall:
root@server(Test):~# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.16.1.254 .POOL. 16 p - 64 0 0.000 0.000 0.000
*firewall.lmn.la 37.58.57.238 3 u 53 64 77 0.420 1.464 0.987
Grüß dich Tobias,
Wir setzten hier bei Domain Controller zZ immer auf Samab 4, also nicht nur auf den Schulsystemen - und hier ist der absolut essentielle Dienst oder Service, der DNS, dieser wiederum ist sehr pingelig, was die Uhrzeit anbelangt, sprich: die sollte überall mind. 10-20 Sek.-genau sein. Die Probleme, bei falscher Uhrzeit => nicht korrekt funktionierendem DNS … sind Sche…e 
zu a.): kommt darauf an, ob es Windows Domainmitglieder gibt, welche automatisch über den Timesever des Domaincontrollers ihre Uhrzeit bekommen sollen oder nicht. Anders ausgedrückt: Windows Clients in der Schule, sind in der Samba4 Domäne des Schulservers und synchronisieren per default über diesen DC auch ihre Uhrzeit und zwar „authenticated time synchronisation with NT5DS“. Über den
ls -alh /var/lib/samba/
drwxr-x--- 2 root ntp 4,0K Jun 8 20:59 ntp_signd
....
ls -alh /var/lib/samba/ntp_signd
srwxrwxrwx 1 root root 0 Jun 8 20:59 socketwerden die benötigen Signaturen oder Tokens zwischengespeichert (weis ich nicht genau, aber egal).
Damit das Funktioniert, müssen die Gruppen-Rechte des Verzeichnisses ‚‚ntp_signd‘‘ auf die Gruppe des auf dem DC eingesetzten NTP-Systems umgestellt werden, bei NTP=ntp, bei chrony=_chrony.
Bei Linux Clients wird das meines Wissens nicht benötigt.
zu b.):
weiter oben schrieb Till:
„Client → Server (AD Controller) → Firewall → Öffentlicher Zeitserver“
Also: kann, muss aber nicht ;-).
Wenn das Setup so ist, dann sollten auch nur in der Firewall öffentliche NTP-Server stehen und gepflegt werden, sonst möglichst nirgends. Aus verschiedensten Gründen (Motto: weil ich dem einen System nicht vertraue, verdopple ich die Einstellung, „wird schon eins davon funktionieren…“ = NEIN!)
Entweder die öffentlichen Zeitserver stehen in der Firewall ODER auf dem Server, nicht beides.
ABER: da ich selbst, wie unten beschrieben, den NTP immer auf dem DC betreiben, kontrollieren und pflegen möchte, stehen bei mir auch die öffentlichen NTP-Server immer direkt in der /etc/ntp.conf drin.
zu c.):
erst mal nur zur Fehlersuche. Bei meinen Setups habe ich immer den Zeitserver für die gesamte Domäne direkt auf dem DC laufen, daher stehen bei mich auch immer (nur) hier die öffentlichen NTP Server oder Pools drin und hier lasse ich das logging auch meistens durchlaufen, um ab und zu mal „nachzuschauen“. Ist das mal richtig eingerichtet das läuft aber sehr stabil, so dass das logging an Wichtigkeit verliert.
zu d.):
habe ich gerade mal probiert:
root@server:~# ntpdate firewall
10 Jul 16:33:48 ntpdate[30371]: the NTP socket is in use, exiting
root@server:~# systemctl stop ntp
root@server:~# ntpdate firewall
10 Jul 16:34:12 ntpdate[30535]: adjust time server 10.16.0.254 offset 0.079668 sec
root@server:~# systemctl start ntpgenau; damit dieser Test funktioniert, musst du zuvor den NTP stoppen, dann testen, dann NTP wieder starten.
So sollte dieser Test mit deinem NTP-Server entprechend funktionieren.
zu e.): ja, solange wir (leider) IPv6 noch nicht im Einsatz haben, schalte ich bei allen Diensten wo das grundsätzlich möglich ist, grundsätzlich auf „nur IPv4“ um.
(=> Postfix, Bind, NTP, SSH …)
Anders als bei Windows, habe ich bei Linux noch von keinen negativen Auswirkungen vom ausschliesslichen Betrieb von IPv4 in reinen IPv4 Netzwerken gehört. Nur von Vorteilen. Bei Windows schon, da sollte insbesondere auf Servern nicht IPv6 abgeschaltet werden, sondern IPv4 durch ein Registry Eintrag priorisiert werden…
Ansonsten ist mein Setup immer noch so, wie weiter oben beschrieben, (ausser dass ich bei sonstigen Samba 4 Setups lieber auf chrony setze, das ist aber unwichtig) auf dem Schulserver just now:
root@server:~# cat /etc/ntp.conf | grep "^[^#]"
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp
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
server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict 127.0.0.1
restrict 0.de.pool.ntp.org notrap nomodify noquery
restrict 1.de.pool.ntp.org notrap nomodify noquery
restrict 2.de.pool.ntp.org notrap nomodify noquery
restrict 3.de.pool.ntp.org notrap nomodify noquery
restrict source notrap nomodify noquery
ntpsigndsocket /var/lib/samba/ntp_signd/Grüße,
gerd
Hallo Gerd,
danke für deine Antworten (auf die ich hier nicht eingehe)
Ich will bloß berichten: Immer wenn ich firewall und server in meiner VBox-Umgebung „speichere“ statt herunterzufahren, dann hat die firewall nach dem Hochfahren eigentlich sofort wieder die richtige Uhrzeit, während mein Server nach der alten Zeit fährt. Vllt. kann an das in VirtualBox tweaken. Ist aber ideales Testfeld, um ntp zu testen.
Jetzt weiß ich, warum ich dachte, dass ein ntpdate firewall nicht funktioniert: Es funktioniert auch nicht für eine ganze Weile, dann funktionierte es. Vermutlich liegt es daran, dass der ntpd auf der Firewall erst dann auf Anfragen reagiert, wenn er sich in eine synchronisierten Zustand mit den anderen vom pool befindet, zumindest ist das der einzig erkennbare Unterschied, wenn ich ntpdate firewall auf dem Server versuche, und es klappt zunächst nicht.
root@server(Test):~# ntpdate firewall
9 Jul 21:07:01 ntpdate[10750]: no server suitable for synchronization found
root@server(Test):~# ntpdate firewall
10 Jul 20:48:04 ntpdate[10772]: step time server 10.16.1.254 offset 85055.178251 sec
Dabei ist der erste Test um ca. 20:44 gewesen, also kurz vorher.
Der einzige Unterschied ist auf der Firewall zu den Zeitpunkten:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*ec2-3-121-254-2 192.53.103.108 2 u 26 64 17 36.558 -3.458 4.205
vs. dasselbe ohne das „*“ am Anfang kurz vorher.
VG, Tobias