Das ist wirklich merkwürdig … irgendein Service kann doch da nicht richtig laufen??
Wenn Du Rechner über die Konsole aufnehmen willst, kannst Du das natürlich auch direkt machen. Dazu man devices.csv -> cd /etc/linuxmuster/sophomorix/default-school/
Datei devices.csv
entsprechend anpassen und dann den Befehl linuxmuster-import-devices
verwenden.
Danach sind die Clients registriert und erhalten die angegebene IP-Adresse.
für einzelne User geht das schon … sophomorix-user -iu <dein-login>
Ansonsten: sophomorix-print ausprobieren und dann unter cd /var/lib/sophomorix/print-data/nachschauen…
Super Tipp! ich habe so langsam kapiert, dass man nach passenden linbo*, sophomorix* und linuxmuster* Befehlen suchen muss, um etwas zu erreichen. Scheint ja alles ohne GUI zu gehen.
Aber: GUI geht wieder. Es wird an mehreren Stellen gesagt, dass die SYSTEMZEIT wichtig ist, ich habe allerdings nicht bemerkt, dass vom Server - als ich den an einen anderen Standort verlegt habe (von Zuhause in die Schule) - die CMOS Batterie leer war und die Zeit verloren hat.
Von Holger hatte ich hier die Tipps bekommen, einmal nach service samba-ad-dc status
und nach service linuxmuster-webui status
zu schauen. Hier war im Samba - glaube ich - zu sehen, dass hier irgendwelche Timestamps in der Zukunft sind, das mochte der wohl gar nicht.
Krass … daran hätte ich als letztes gedacht, obwohl das tatsächlich schon öfter ein Problem war. Die Systemzeit ist tatsächlich kritisch und muss überall passen …
Aber gut, dass das jetzt gelöst ist
Danke für die Rückmeldung, das ist sehr interessant. Meiste Problem bei Samba liegen entweder an Zeitsync oder am DNS.
In diesem Fall, sehe ich keine einfache Lösung, was wir bauen könnten um es zu checken.
Kann man nicht einen Zeitvergleich einbauen, der beim Setup die Uhrzeit mit der Atomuhr in Braunschweig https://uhr.ptb.de/ abgleicht und zumindest eine dicke Warnung ausspuckt, wenn die Differenz zu groß ist?
Ja natürlich kann man es machen, oder per ntp synchronisieren. Aber dass sehe ich nicht als Teil der Entwickler, eher von dem Admin.
In diesem Fall war es wahrscheinlich das Problem, dass Peter auf einem Snapshot zurückgegangen ist. Alle meine Testsserver laufen mit Snapshots, und jedes mal wenn ich auf einen Snapshot zurückgehe, synchronisiere ich zuerst die Zeit per NTP (z.B. ntpdate pool.ntp.org), ansonstens läuft gar nichts, selbst apt.
Da es einen Einzelfall ist, würde ich mich lieber auf etwas wichtiger konzentrieren.
Das war bei mir das Problem mit der CMOS Batterie - die war dann leer, Server woanders aufgebaut, Zeit zurückgesetzt, zumindest ein paar Wochen. Das ging dann nicht mehr. Ich kämpfe tatsächlich immer noch mit Zeitproblemen (das mit den Mountpoints für die User ist auch etwas kritisch, da müssen offensichtlich auch die Uhren aufeinander gesynct sein.)
Das ist aber ein Kampf, der wirklich individuell ist. Und liegt wirklich am Admin.
Allerdings finde ich auch, dass ein „Internal Server Error“ irgendwie abgefangen werden könnte, woanders in der WebGUI gibt es ja auch so hübsche Dialogfenster mit einer Fehlermeldung drin. Irgendeine Exception muss ja zum Internal Server Error geführt haben. Vielleicht lohnt es sich doch nochmal reinzuschauen. Ich wüsste allerdings auch nicht, wo ich schauen sollte. Das ist ja direkt bei Zugriff auf https://server passiert. Ohne Einloggen. Ob da etwas Sambamässiges geprüft wird?
Es liegt wahrscheinlich am Zertifikat der laut Datum noch nicht gültig war.
Das ist leider nicht einfach alle mögliche Fehlermeldungen zu fangen, da die Webui von externen Bibliotheken abhängig ist, die auch externe Bibliotheken verwenden. Und da der Weg von einer Error endet oft nur mit „ERROR“ ohne, dass wir genau wissen, warum. D.h., dass wir dann die einzelne Fällen prüfen müssen. Wir haben schon echt viele solche Probleme gelöst, aber es bleibt leider noch versteckte Stellen