Hallo,
das Problem ist doch größer als gedacht und sollte gelöst werden:
Meldet man sich als Netzwerkuser an, bevor der Zeitunterschied von chrony korrigiert worden ist, dann fehlen Home- und Tauschverzeichnisse.
Viele Grüße
Wilfried
Hallo Wilfried,
das Problem ist doch größer als gedacht und sollte gelöst werden:
Meldet man sich als Netzwerkuser an, bevor der Zeitunterschied von
chrony korrigiert worden ist, dann fehlen Home- und Tauschverzeichnisse.
ich denke das Problem tritt bei mir nicht auf, weil ich dafür gesorgt
habe, dass linbo die Systemzeit (BIOS Uhr) korrekt setzt.
Leider macht linbo das nicht immer,weil der Dienst (Zeitserver) auf dem
Server immer mal „wakelt“.
Schau mal in diese Tread:
LG
Holger
Hallo Wilfried,
poste mal deine /etc/chrony/chrony.conf
LG
Thorsten
Hallo Thorsten,
bitte:
# /etc/chrony/chrony.conf
#
# thomas@linuxmuster.net
# 20181017
#
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usuable directives.
# This will use (up to):
# - 4 sources from ntp.ubuntu.com which some are ipv6 enabled
# - 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
# - 1 source from [01].ubuntu.pool.ntp.org each (ipv4 only atm)
# This means by default, up to 6 dual-stack and up to 2 additional IPv4-only
# sources will be used.
# At the same time it retains some protection against one of the entries being
# down (compare to just using one of the lines). See (LP: #1754358) for the
# discussion.
#
# About using servers from the NTP Pool Project in general see (LP: #104525).
# Approved by Ubuntu Technical Board on 2011-02-08.
# See http://www.pool.ntp.org/join.html for more information.
#pool ntp.ubuntu.com iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2
server server.linuxmuster.lan
# This directive specify the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys
# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift
# Uncomment the following line to turn logging on.
#log tracking measurements statistics
# Log files location.
logdir /var/log/chrony
# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0
# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
rtcsync
# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 1 3
@Holger: In linbo startet die Zeit auch ganz kurz falsch, wird aber sofort korrigiert.
Viele Grüße
Wilfried
Hallo Wilfried,
das ist das selbe Problem, das ich oben beschrieben habe. Linbo schreibt die Localtime in die RTC; für Windows ist das genau richtig, aber für Linux falsch. Da Linux die Zeit nicht direkt beim Systemstart aktualisiert, sondern nach einer zufälligen Zeit, funktioniert das SSO nicht, also keine Shares und keine Anmeldung am Proxy.
Solange das mit der Zeit nicht funktioniert, bleiben die Computer bei uns erstmal ungenutzt. 
Ich hatte einen pull-request mit einer Korrektur gemacht, glaube aber, dass aktuell noch geprüft werden soll, wie Win10 mit UTC läuft (funktioniert mit einem Reg-Patch). In unserem aktuellen 7er-System wird durch linbo noch die Localtime geschrieben.
Ich würde das zum Testen gerne auf UTC umstellen, weiß aber nicht, woher sich der Server die Linbo-Umgebung holt - ich vermute, dass die vorkompiliert ist; ich konnte die Datei auf dem Server nicht finden.
Vielleicht wäre es sinnvoll, wenn Linbo die Systemzeit nicht direkt beim System-Init in die RTC schreibt, sondern vor/beim Start eines Betriebssystems und die Zeit dann Systemabhängig setzt. Das könnte man auf dem Server über die Gruppen vorgeben.
Übergangsweise schlage ich vor, die Code-Zeile, die die RTC schreibt auszukommentieren und den Nutzer darauf hinzuweisen, dass sich das gestartete OS um die korrekte Zeit kümmern muss. Man muss dann nur bei Inbetriebnahme eines Computers auf die korrekte Zeit achten, aber danach hätte man sowohl für Win10, als auch für Linux immer die korrekte Zeit.
Viele Grüße
Fabian
Hallo Fabian,
das wundert mich: ich meine linbo schreibt UTC (wie es alle machen …
außer Windows) un ddie Einigung war, dass man windows per regeintrag auf
UTC umbiegt.
Genau so habe ich es bei mir in der SChule: linux macht das richtig,
windows hat einen Regeintrag bekommen und tut jetzt auch. linbo schreibt
utc: alles fein bei mir jetzt.
Schau mal hier:
LG
Holger
Moin!
Heißt das jetzt, dass es so wie es jetzt implementiert ist (Linbo-Client ruft hwclock --systohc auf), bleiben soll? Ich habe halt die Befürchtung, wenn ich das wieder rausnehme, melden sich zig andere, bei denen die Zeit nicht stimmt.
Das sollte jetzt mal endgültig festgelegt werden.
Ich habe es oben schon geschrieben, der Linbo-Client nutzt dieselbe timezone wie der Server. Ändert man die TZ auf dem Server und ruft anschließend update-linbofs auf, hat man auf dem Client auch die TZ geändert.
VG, Thomas
Hallo Thomas,
Einigung war, dass man windows per regeintrag auf UTC umbiegt.Heißt das jetzt, dass es so wie es jetzt implementiert ist (Linbo-Client
ruft hwclock --systohc auf), bleiben soll? Ich habe halt die
Befürchtung, wenn ich das wieder rausnehme, melden sich zig andere, bei
ich meine (meine private Meinung: ich bin kein Entwickler), dass die
Sache so läuft:
Server steht auf UTC
Linbo setzt die BIOS Zeit beim starten auf dem Client auf UTC
Windows wird per regpatch auf UTC umgemünzt.
Dann sollte das doch für alle stimmen, oder?
Oder hab ich da was nicht verstanden?
LG
Holger
Nochmal: Linbo setzt die BIOS Zeit auf genau das, was auf dem Server eingestellt ist.
VG, Thomas
Hallo Thomas!
Auch auf die Gefahr hin das ich nerve, ich sage vorab schon einmal Entschuldigung dafür! 
Ich finde die Idee von
sehr charmant. Damit ließe sich das für alle Zeit einfach lösen, wie ich finde. Kein Reg-Patch, oder sonst was, hier wird jeder bedient wie er es mag. (gemeint ist natürlich das BS; steht so auch in PullRequest )
nur meine 1/2 Cent
lieben Gruß und bleib gesund
Thorsten
Hallo zusammen,
Ich habe das nicht verstanden:
was heißt denn das genau?
root@server(Humboldt):~# timedatectl status
Local time: Mi 2020-06-10 22:05:33 CEST
Universal time: Mi 2020-06-10 20:05:33 UTC
RTC time: Mi 2020-06-10 20:05:32
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: noDas sagt mir doch: meine Hardware läuft in UTC, nicht in lokaler Zeit.
Also, wenn ich das wörtlich nehme, dann setzt LINBO auf meinem Client erstmal die BIOS-Zeit (RTC) auch auf UTC.
Für die LinuxClients wäre das jetzt bei mir Stand der Dinge perfekt: dem muss man nur beibringen, dass die RTC auf UTC steht, wie üblich und dass die Zeitzone 2h daneben liegt. Übrigens würde ich chrony und ntp auf den clients verbannen und überall die systemd - timesyncd Variante verwenden. Nur der Einheit und des supports hier wegen.
Für die WIndowsCLients gäbe es zwei Möglichkeiten:
oder (so steht es doch alternativ im github issue):
- wenn windows gestartet wird, dann patch LINBO die BIOS-Zeit (RTC) eben auf die localtime.
Vermutlich habe ich jetzt auch nur umformuliert, was @fkretzschmar und @MachtDochNix auch vorgeschlagen haben.
Für diese Alternative wäre ich auch.
Hallo Thomas,
nach dem Linbo-Update stimmt bei meinem virtuellen Client die Zeit von Beginn an. Danke für deine Arbeit.
Viele Grüße
Wilfried
Hi,
ich hab das in einen anderen Thread mit reingepackt … seit dem Einspielen von dem neuen Linbo komme ich auch mit Linux nicht mehr durch SSO ins Netz.
Der Befehl timedatectl status zeigt bei mir auf dem Server 3x die gleiche Zeit an, und die ist um 2 Stunden hinten.
Muss ich da die localtime um 2 vorstellen (siehen Bild Holger)? Wenn ja, wie, wo …
VG
Wolfgang
Hallo Wolfgang,
funktioniert jetzt alles bei mir - kein Trost für dich …
Hast du SSO in der OPENsense getestet?
Ich habe auf dem Linuxclient die Proxy-Einstellungen systemweit unter ‚Einstellungen > Netzwerk > Manuelle Proxy-Einstellungen‘ gemacht. Für realistische Tests muss dann auch der Client, sofern er zuvor eingetragen war, aus der ‚NoProyx-Gruppe‘ raus.
Viele Grüße
Wilfried
Hi,
nö - tröstet nicht 
Ich werde für Montag jetzt das „Notprogramm“ anlaufen lassen und alle Rechner erst mal in die noProxy Gruppe schieben. Da muss ich allerdings erst mal sehen, wo bzw. wann beim Linux-Client die Proxies gesetzt werden. Beim Windows-Client scheint es zu funktionieren - teste ich heute/morgen noch.
Ich bin sicher, dass es mit dem Zeitproblem zusammenhängt. Ich hab da einen Verdacht, muss das aber morgen noch checken …
VG
Wolfgang
Hi,
gibt es belastbare Aussagen über maximal erlaubte Zeitabweichungen?
Kerberos lässt bis zu 5min zu (?)
Mein Problem ist, dass mein Schulträger kein ntp durch die Firewall lässt, und ich das quasi „hintenrum“ irgendwie ins System bringen muss …
VG
Wolfgang
Selbes Problem bei mir. Ich hab das neue Linbo Update installiert. Hat leider nicht geholfen. Windows kommt mit dem Zeitunterschied klar, aber Linux verbindet keine Laufwerke und surfen ist auch nicht möglich.
Montag geht die Schule wieder los, eine schnelle Lösung wäre super, sonst müssen alle Clients in die no Proxy Gruppe.
Danke im vorraus.
Hallo Thomas,
ich bin leider nicht so gut im Code lesen:
Bedeutet
Ok, ist in linuxmuster-linbo7 2.3.63 ungesetzt.
dass linbo beim Starten die lokale BIOS Zeit auf UTC setzt und dann, wie Tobias schreibt, beim Starten von windows die BIOS zeit schnell auf localtime setzt?
Oder bedeutet es Lösung b:
dass linbo die lokale Zeit immer auf die Zeit des Servers setzt (sollte UTC sein) udn wir Windwos mit regpatch behandeln, dass es weiß, dass die RTC Zeit UTC ist nicht localtime?
LG
Holger
Hallo Wolfgang,
Mein Problem ist, dass mein Schulträger kein ntp durch die Firewall
lässt,
… dazu sag ichmal besser nichts…
und ich das quasi „hintenrum“ irgendwie ins System bringen muss …
wichtig ist ja in erster Linie nicht, dass deine Zeit im Netz ganz genau
mit der „draußen“ übereinstimmt, sondern dass deine Zeit im Netz intern
synchron ist.
Deswegen sollte diese Kette eingehalten werden:
-
OPNsense ist der Zeitserver im Netz.
Der Server bezieht von ihm die Zeit. -
der Server gibt die Zeit per linbo und mit seinem ntp weiter an die
Clients im Netz.
Also:
welche Zeit hat die OPNsense? welche der Server?
Welche Zeit ist den am Server eingestellt?
Bei mir:
timedatectl
Local time: Fr 2020-06-12 22:03:21 CEST
Universal time: Fr 2020-06-12 20:03:21 UTC
RTC time: Fr 2020-06-12 20:03:22
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: no
läuft auf dem Server der ntp Dienst?
root@server:~# systemctl status ntp.service
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor
preset: enab
Active: active (running) since Sun 2020-06-07 23:08:23 CEST; 4 days ago
Docs: man:ntpd(8)
Main PID: 7212 (ntpd)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/ntp.service
└─7212 /usr/sbin/ntpd -p /var/run/ntpd.pid -4 -g -u 113:117Ist der ntp auf dem Server korrekt eingestellt?
Bei mir in der /etc/ntp.conf
:
# Specify one or more NTP servers.
# use firewall as primary ntp server
pool 10.16.1.254
server 10.16.1.254
# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
# pool pool.ntp.org
#server 0.de.pool.ntp.org
#server 1.de.pool.ntp.org
#server 2.de.pool.ntp.org
#server 3.de.pool.ntp.org
LG
Holger