Hallo Tobias,
der timesyncd ist wohl jetzt so ein Standard NTP Dienst der auf den lokalen Maschinen perse für die richtige Zeit sorgt. chrony und ntp sind „mächtigere“ alternativen. Spätestens auf einem DC brauch man mehr… (Client - Server Kommunikation, zertifikate, usw.) will man dann noch Windows Clients unterhalten müssen auch dessen Standards unterstützt werden…
Das haben wir oben entsprechend umgesetzt
siehe auch: https://wiki.samba.org/index.php/Time_Synchronisation
Grüße,
gerd
Hi. Ich habe das Update gerade eingespielt und mit den von Gerd vorgeschlagenen Änderungen verglichen. Den Eintrag
finde ich aber nirgendwo … ist das nun ein Versehen oder ist der Eintrag nicht notwendig?
Danke,
Michael
Hi.
… also nach einem linuxmuster-distupgrade und einem Serverneutstart kann ich keine Änderung feststellen. Der Bugfix #78 hat nicht oder nicht vollständig geholfen – jedenfalls wird bei mir weiterhin gemeldet:
systemctl status ntp.service
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:ntpd(8)
[root@server:~]$ systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-12-05 19:57:02 CET; 13min ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 694 (systemd-timesyn)
Status: "Synchronized to time server 10.16.1.254:123 (10.16.1.254)."
Tasks: 2 (limit: 4915)
CGroup: /system.slice/systemd-timesyncd.service
└─694 /lib/systemd/systemd-timesyncd
Ich werde die von Gerd vorgeschlagenen zusätzlichen Änderungen nun mal per Hand eintragen…
Schönen Gruß,
Michael
Ok, nach den oben beschriebenen Änderungen startet der ntp-Server.
Eine Sache ist jetzt aber widersprüchlich:
Gerd hat bei sich die Server 0.de.pool.ntp.org usw hinzugefügt … das Bugfix hat meines Wissens den Eintrag pool 10.16.1.254 gemacht, oder? (Kann ich nicht mehr sicher sagen). Was ist nun richtig?
Hallo Michael,
den Buxfix kann ich erst nächste Woche testen, bin gerade bei Firmenmigration W7->W10 usw.
0.de.pool.ntp.org (0-3) ist ein allgemein empfohlener und öffentlich verfügbarer NTP Server Pool aus Deutschlad, einer von denen funktioniert immer .
10.16.1.254 ist ein lokaler Server, der kann nur funktionieren wenn im lokalen Netz exakt auf der IP selbst ein richtiger NTP läuft - keine gute Idee, wenn der so gepatcht würde…
Am Rande:
Grüße,
gerd
Hi Gerd.
Hier steht ja halbwegs, was geschehen sollte (und welche Files geändert werden)
Kann nun aber nicht mehr sehen, ob ntp oder timesyncd benutzt werden soll, es klingt aber alles nach ntp
Was die ntp.conf angeht: du hast Einträge Server… und nicht Pool … . Warum?
Schöne Grüße
Michael
Hallo,
- Damit die öffentlichen NTP Server im Netz nicht völlig überlastet
werden, gilt es als gute Praxis, dass man im LAN nur genau 1 (einen)
NTP Server hat, der die öffentlichen abfragt, und zB nicht jeden der
500 Clients das selbst machen lässt
deswegen ist die OPNsense unser NTP im Netz.
Die OPNSense wird dann an einen externen Pool gebunden.
Deswegen ist es schon richtig, meine ich, wenn der server die Firewall
fragt.
Weiterer Vorteil: man muß den NTP Port 123 nur für die Firewall frei
machen, nicht für das Netz (oder den Server).
LG
Holger
Moin!
Das ist so konzipiert, dass die FW die zentrale NTP-Instanz im LAN ist. Sie holt sich die Zeit von pool.ntp.org. Der Server holt sich die Zeit von der FW, die Clients holen sich die Zeit vom Server.
VG, Thomas
Hi Thomas,
ok, aber dann sag doch gleich noch dazu, ob der NTP Server laufen mus oder ob timesyncd ausreicht? Das ist weiterhin nicht ganz klar, meine ich??
Schönen Gruß,
Michael
Hallo Michael,
der ntp dienst muss auf dem Server laufen. Auf meinem Produktivsystem hat das nach dem Upgrade auch funktioniert. Das Paketskript aktiviert und startet den ntp service.
Evtl. musst du ihn neu starten, wenn er schon gestartet war.
VG, Thomas
Ok, habe es gerade nochmal kontrolliert. Heißt das nicht, dass der Eintrag
pool pool.ntp.org in der ntp.conf nach dem Bugfix deaktiviert sein müsste? War hier nicht der Fall. Am einfachsten wäre es, wenn du mal eine komplette /etc/ntp.conf hier postest, oder?
Schönen Gruß,
Michael
Hallo,
Um zu testen, dass der NTP-Server-Patch das notwendige „authenticated time synchronisation with NT5DS“ für den DC umsetzt, müsste man zuvor die /etc/ntp.conf wieder auf default stellen, auf jeden Fall die Zeile
ntpsigndsocket /var/lib/samba/ntp_signd/ vor dem Patch raus nehmen. Die Rechte des Verzeichnisses /var/lib/samba/ntp_signd/ müssten vor dem Einspielen wieder zurück auf root: chgrp root /var/lib/samba/ntp_signd/.
Nach dem Patchen ist zu prüfen,
[EDIT]:
ob die jeweils individuelle IP der Firewall eingestellt wird. oder ob die vorgegebene feste IP individuell anzupassen ist
ob der ntp.service wieder die benötigten Rechte auf /var/lib/samba/ntp_signd/ hat
und die notwendige Zeile: ntpsigndsocket /var/lib/samba/ntp_signd/ eingetragen wurde
dass der ntp.service in Datei: /var/log/ntp seine Log-Einträge schreiben kann.
Siehe die Ausgabe von:
root@server:~# systemctl status ntp.service
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2019-12-03 20:17:55 CET; 6 days ago
Docs: man:ntpd(8)
Process: 1286 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
Main PID: 1294 (ntpd)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/ntp.service
└─1294 /usr/sbin/ntpd -p /var/run/ntpd.pid -4 -g -u 113:119
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.Die letzte Zeile kam bei mir, wenn Punkt 4 nicht erfüllt ist. Statt dessen muss da in etwa folgendes stehen:
Dez 10 21:06:14 server.bs-wiz.llan ntpd[19835]: switching logging to file /var/log/ntp[EDIT Ende]
Zum Schluss vor allem aktuelle Windowse checken - siehe Post 13.
Richtig?
Grüße,
gerd
Hi Gerd,
bei mir ist linuxmuster-base7 7.0.45-0ubuntu0 installiert und es wäre doch am einfachsten, ich wüsste jetzt, was in meiner /etc/ntp.conf drinstehen sollte.
Denn es hat sich gegenüber der 7.0.44 Version nur geändert, dass jetzt die IP drinsteht, statt „firewall“
22c22
< pool firewall
---
> pool 10.16.1.254Ich sehe nichts von ntpsigndsocket oder ähnlichem in meiner /etc/ntp.conf.
Ich kann allerdings bestätigen, dass der ntp-daemon läuft und dass - im Gegensatz zu vorher, der timesyncd als „inactive (dead)“ markiert ist. Ich wäre auch geneigt den zu disablen, aber das scheint ja nicht nötig zu sein, wenn der sich zurückzieht sobald ntp daher kommt.
VG, Tobias
Hi.
Ich kann nur wiederholen, dass der ntp-Service bei mir nach dem Update nicht lief (der ntpsignsocket wurde da auch nicht automatisch eingetragen) … ich musste die Einstellungen, die Gerd vorgeschlagen hatte, manuell durchführen.
Als Pool steht bei mir nun auch die IP der Firewall, alle anderen Serveradressen kann man sich (wenn ich das richtig verstehe) dann ja sparen?!
Aber eine ntp.conf so wie sie nach dem Upgrade sein soll, wäre schon gut … wer hat eine?
Schöne Grüße,
Michael
Hi.
Ergänzung … die Sache mit der Zeit scheint tatsächlich kritisch zu sein.
Zunächst: der NTP-Server läuft auf dem Server, win10 ist in der Domäne aufgenommen, die Anmeldung funktiniert. Zufällig bin ich nun aber in den Windows-Ereignisprotokollen über diese Meldung gestolpert:
und auch dies:
Hallo,
Innerhalb einer Windows Domäne ist es nicht zwingend nötig, per Gruppenrichtlinie einen Zeitserver zu setzten, da der DC automatisch als Zeitserver gesetzt wird. Vorausgesetzt es ist alle richtig eingerichtet.
Wir erstellen in Samba 4 Domänen trotzdem folgende GPO und haben die Erfahrung gemacht, dass ohne diese die Zeit eben nicht überall gesetzt wird.
Dazu verwenden wir ein virtualisiertes aktuelles Windows 10 Pro System, auf dem wir über „Apps und Features“ die benötigten RSATs nachinstalliert haben. Hierüber können u.a. Gruppenrichtlinien verwaltet werden, die über den DC (=Samba 4 Schulserver) im Netz an die Windows Clients verteilt werden …
Hier konnte ich keine GPO bezüglich des NTP Servers finden.
Nach meinem Kenntnisstand sollte aber eine entsprechende Gruppenrichtlinie angelegt sein, wenn ich in meiner Domäne Windows Clients habe, siehe auch den Screenshot, unter:
Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Windows Zeitdienst\Zeitanbieter\sind folgende zwei Einstellungen zu setzten:
Windows-NTP-Client konfigurieren => A: Aktiviert; B: unter NtpServer: den DNS Namen des DCs, also des Schulservers bzw. dessen IP
und:
Windows-NTP-Client => aktivieren
Wenn der Typ defaultmäßig auf NT5DS bleiben soll, muss das natürlich wie oben - Post 13 - beschreiben, umgesetzt werden, ansonsten kann hier auch auf unsigniertes NTP umgestellt werden.
Welche Auswirkung unsigniertes NTP in einer Windows Domäne hat, weiss ich nicht.
Grüße,
gerd
Hallo Michael,
hier hast du aber erst mal ein DNS Problem.
Wo kommt den bei dir die Domäne „LINUX“ her? Oder ist das eure schulweite Domäne?
Ich würde erst mal das DNS überprüfen, Namensaufllösung …
Das wäre dann schon wieder ein neues Thema 
Grüße,
gerd
Hallo Gerd.
Noch eine Ergänzung: Wenn ich das richtig verstehe, sollte man beim NTP-Server den Eintrag 0x8 dahinter schreiben, damit der in den Client-Modus gezwungen wird. Das habe ich mir nicht selbst ausgedacht sondern hier gefunden:
https://blog.kopfteam.de/timeserver-sauber-konfigurieren-neue-methode/
Bei mir sieht der Screenshot bei erstmaligem Aufruf so aus:
… und müsste entsprechend geändert werden.
Das andere Problem (DNS) wundert mich. Ich kann problemlos in einer cmd.exe sowohl ping server als auch ping firewall absetzen. Wird alles richtig aufgelöst – es könnte sich aber wieder um ein Problem drehen, ob da der komplette Name oder nur der erste Teil als Windows-Domäne hineingehört?!? … Ist aber wirklich ein neues Thema für einen neuen Thread…
Schöne Grüße,
Michael
Hallo Michael,
ja, zu diesn Flags habe ich auch versucht was hilfreiches zu finden:
Hier von Microsoft
Aber ob und welches Flag wirklich notwendig ist, habe ich noch nicht raus gefunden, also habe ich sie weg gelassen. Was für mich gleichbedeutend ist, mit „default“. Dann habe ich geprüft, ob’s tut was es soll - und dem war so, auch ohne dieses Flag.
Und wenn man dann das noch liest:
blogs.msdn.microsoft.com
hmmm, versuch doch mal den Effekt der Flags nachzuvollziehen … :-))
und sag mir dann Bescheid… haha
Wichtig ist für mich dabei immer im Hinterkopf zu behalten, dass seit den aktuellen Samba 4 Versionen, das für eine Windows AD Umgebung einem „echten“ Windows DC entspricht und daher möglichst wenig oder besser gar nichts umgebogen werden muss, wenn denn an der Samba 4 Seite alles richtig gemacht wurde…
EDIT:
hier sind vor allem die Windows (10) Clients gemeint, an denen seit Samba4 nichts mehr extra ein- oder umgestellt werden muss, bevor einer Samba4 Domäne beigetreten werden kann.
Grüße,
gerd
