Zeitserver - Die Uhr geht eine Stunde nach

UCS - Univention Corporate Server
#1

Hallo zusammen,

ich kämpfe mit dem Problem das die Uhr meines UCS 3.1 um eine Stunde nach geht.

Die Installation läuft in einer Hyper-V VM auf Server 2012.

Die BIOS Uhr und die Uhr des Hosts laufen korrekt.

Folgendes habe ich bisher probiert:

  • ucr set timeserver=“ptbtime1.ptb.de”
  • /etc/init.d/ntp restart
  • ntpdate -ub ptbtime1.ptb.de
  • VM neugestartet
  • Zeit verstreichen lassen (das System einfach mal 2 Stunden in Ruhe gelassen)

Der Zeitserver selber läuft (/etc/init.d/ntp status)

Der Symbolische Link ist auf die richtige Zeitzonge gesetzt

Das bekomme ich als Ausgabe von “ntpq -p”[code] remote refid st t when poll reach delay offset jitter

*LOCAL(0) .LOCL. 10 l 10 64 37 0.000 0.000 0.001
ptbtime1.ptb.de .PTB. 1 u 11 64 7 34.656 -49.889 2.768[/code]

Das bei Ausgabe von “date”Do 7. Mär 10:14:28 UTC 2013 (Wir haben gerade exakt eine Stunde später)

Ich weiß nicht was er von mir will :stuck_out_tongue:

Hat jemand einen Ansatz was noch schief sein könnte?

Ich bin nicht so der Linux Profi, bitte etwas langsamer sprechen =)

mfg der Path

EDIT:

Habe jetzt nochmal neugestartet und der externe Zeitserver hat wieder einen sehr hohen Offset, das ist doch nicht gut oder?[code]root@ucs:~# ntpq -p
remote refid st t when poll reach delay offset jitter

*LOCAL(0) .LOCL. 10 l 55 64 7 0.000 0.000 0.001
ptbtime1.ptb.de .PTB. 1 u 57 64 1 35.285 923.818 0.001[/code]

Und drei Minuten später einen negativen Wert und der Jitter Wert schießt hoch?[code]root@ucs:~# ntpq -p
remote refid st t when poll reach delay offset jitter

*LOCAL(0) .LOCL. 10 l 31 64 37 0.000 0.000 0.001
ptbtime1.ptb.de .PTB. 1 u 28 64 7 33.707 -0.681 653.720[/code]

Was bedeutet das genau?

#2

Ich beobachte das gerade mal aufmerksam.

Der Offset Wert hat sich bei “-0.681” stabil eingependelt.

Der Jitter Wert des externen Zeitservers sinkt gerade stetig.

Ich schau das durch wiederholte eingabe von “ntpq -p” an.

Das was ich zu dem Grundproblem Setup nun geändert habe, ist das abschalten der Zeitserver Synchronisation, in den Hyper-V Integrationsdiensten für die UCS VM.

Mal sehen.

EDIT:

Hier ist unteranderem die Bedeutung der ausgegebenen Tabelle bei “ntpq -p” super erklärt!
jfranken.de/homepages/johann … lt.de.html

Die ganze Sache ist ordentlich in Bewegung:

Offsetwert des externen Zeitservers ist weiter gesunken. Jitter Werte auch um dann wieder zu steigen.

An der Systemzeit ändert sich garnichts. Exakt eine Stunde zurück.

Was sagt mir das alles? =))

EDIT:
Das hier ist der entscheidende Punkt oder?
wiki.ubuntuusers.de/Systemzeit#F … stallation

#3

Hallo,

wir haben recht wenig Erfahrung mit Hyper-V. Die Ausgabe Ihres “date” Befehls gibt die Zeitzone allerdings mit UTC an, die Central European Time ist UTC +1 was die Differenz erklären würde.
Welche Zeitzone haben Sie in UCS Konfiguriert (UCS Handbuch: Konfiguration der Zeitzone / Zeitsynchronisation?

Mit freundlichen Grüßen
Janis Meybohm

#4

Ich habe mich mit Linux unter Hyper-V herumgeärgert, als die Integrationstreiber noch mehr als mau waren (Kernel panics und kaputte FS), kenne aber das Verhalten von Linux nur bis
Hyper-V 2008 R2 als host, wie sehr sich die Linux-Module unter 2012 anders verhalten, damit habe ich keine Erfahrung.

Mir ist aufgefallen, dass das hiesige, erste 3.1-1 System als DC master nach der Installation keine NTP peer Server definiert hat(te) und nur den Hyper-V provider benutzt, als Zeitzone hatte ich UTC+1, auf dem Host ebenfalls eingerichtet. Hier scheint die Zeit mal zu stimmen.

MS empfiehlt es bei WIndows DCs den Time provider für DCs als VM auszuschalten, da ein DC in einer Windows Domain selber
NTP server ist, dann beisst das ganze, wenn der Host selber in der Domain ist (und vom DC die Zeit bekommt und ihm sie liefert)
Das dürfte bei UCS mit Kerberos und Co. nicht viel anders sein empfohlen werden. Solltest du eine zu schnelle Zeit haben, müsstest du mit adjtimex spielen, das war bei SL 5.x noch nötig.

Übrigens kann man die aktuelle Clock source des kernels über folgenden Befehl in der VM herausgeben, available_clocksource zeigt die verfügbaren an.

root@hlinux:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource hyperv_clocksource

Ich werde ebenfalls NTP noch konfigurieren und schauen, wie es sich verhält, ich vermute nicht, dass der Time provider unter 2012 so viel anders als unter 2008 R2 sein müsste, bin aber gespannt wie es bei dir aussieht.

#5

Ja, ich habe noch etwas Erkenntnisse, allenfalls etwas für einen Bug-Report:

Der Debian installer ermöglich es, im Setup zu sagen, dass die BIOS-Zeit NICHT in UTC ist und da gibt es im Zusammenspiel mit Hyper-V etliche mehr oder wenig ungangenehme Nebeneffekte. Da Hyper-V (eben leider) auf die MS-Welt ausgerichtet ist, stellt der dortige Hypervisor die BIOS-Zeit auf lokale Zeit jedes Mal wenn die VM (neu) gestartet wird.

Das ist so lange kein Problem, wenn auf Hyper-V Ebene der Time-provider für die UCS-VM aktiviert ist, denn dann korrigiert der Kernel sehr früh in der Bootphase die Systemzeit noch ehe die ersten Daemons starten. Setzt man aber auf NTP als Zeitquelle und deaktiviert den Time-provider von Hyper-V (was ja MS auch für die eigenen DCs empfiehlt), bootet UCS vor dem ersten NTP-Sync mit der aktuellen Sommerzeit um 2h voraus in den Login prompt. Dass dabei einige Dienste kurz mal husten (Kerberos…) scheint mir dann einleuchtend.

Das Problem ist, dass der UCS-Installer anders als der von Debian derzeit keine Option besitzt, dass die BIOS-Zeit in lokaler und nicht in UTC-Zeit gesetzt ist
(gerade bei Dual-Boot mit Windows nötig). Aktuell konnte ich mir damit behelfen, dass ich den entsprechenden Eintrag in /etc/default/rcS nach der Installation dann angepasst habe. (und erst danach den Time-Provider für diese VM deaktiviert habe)

Hat man den Time-Provider übrigens während der Installation inaktiviert, gibt das ganz noch interessantere Effekte, weil dann während der Installation das Zertifikat der UCS CA erstellt wird - und alle Zertifikate bei aktueller Sommerzeit 2h zu früh ausgestellt sind. Die UMC etwa funktioniert dann nicht bzw. bleibt beim Login mit 100% CPU-Last von univention-management-console-web… stehen. Tja, so viel nach ein paar Stunden investierter Zeit :wink:

Mastodon