Synchronisieren muss man eigentlich nur, wenn sich etwas am Domänenjoin im Image geändert hat. Also zum Beispiel, wenn die Domäne neu gejoint wurde. (Bei Linuxclient als, nachdem der Befehl linuxmuster-linucxlient7 setup ausgeführt wurde)
Außerdem MUSS eine Kabelverbindung zum LAN bestehen, wenn man bei einem Dual boot Rechner das System wechselt. Beispiel:
Windows läuft → Anmeldung geht
Rechner wird neu gestartet
Rechner ist in LINBO → hier MUSS eine Verbindung zum Server bestehen
Ubuntu wird gestartet → Anmeldung / Netzlaufwerke geht NUR wenn bei 3. eine Verbindung zum Server bestand.
Hallo Ok. Der Dualboot könnte also tatsächlich weiterhin Probleme machen.
Bei uns war heute Alarm in beiden Computerräumen. Da läuft Ubuntu & Win10 parallel – die Rechner sind natürlich fest über LAN verkabelt. Falls da zwischendurch Win10 gestartet wurde (was ich nicht sicher sagen kann), könnte es zu Problemen gekommen sein.
Da es fast zeitgleich ein Problem im Netzwerk gab, war Punkt 3 vielleicht zu dem Zeitpunkt nicht überall stabil vorhanden… ich kann es leider im Moment nicht genauer eingrenzen…
Hej,
ich hänge mich mal an der Thread dran, wobei es bei mir vermutlich um ein konkretes Troubleshooting geht. Wir haben heute versucht nach Anleitung den adsso-client auf den neuen linuxclient7 zu migrieren.
Der Domänenbeitritt scheint auch zu klappen. linuxmuster-linuxclient7 status sieht gut aus:
[sudo] Passwort für linuxadmin:
(pam_mount.c:365): pam_mount 2.16: entering auth stage
[INFO] #### linuxmuster-linuxclient7 status ####
[INFO] Linuxmuster-linuxclient7 is setup!
[INFO] Testing if domain is joined...
[INFO] Checking joined domains
[INFO] Joined domains:
[INFO] * csg-tuebingen.de
[INFO] Testing if the domain join actually works
[INFO] * Checking if the group "domain users" exists
[INFO] * Trying to get a kerberos ticket for the Computer Account
[INFO] The domain join is working!
[INFO] #### linuxmuster-linuxclient7 is fully setup and working! ####
(pam_mount.c:133): clean system authtok=0x557f47350630 (1073741824)
Trotzdem bleibt die Anmeldung mit einem AD-user kurz mit einem ubuntu-lila-Bildschirm hängen.
Im Log (linuxmuster-linuxclient7 status) finde ich die folgenden Schnipsel vom Anmeldeversuch des Lehrer lem…
linuxmuster-linuxclient7: [DEBUG] Calculating mountpoint of //server/default-school/teachers/lem
systemd[1]: Starting SSSD PAM Service responder private socket.
systemd[1]: Starting SSSD PAM Service responder socket.
systemd[1]: Starting SSSD Sudo Service responder...
sssd_check_socket_activated_responders[3907]: (Tue Jun 1 19:46:16:443769 2021) [sssd] [main] (0x0010): Misconfiguration found for the pam responder.
sssd_check_socket_activated_responders[3907]: The pam responder has been configured to be socket-activated but it's still mentioned in the services' line in /etc/sssd/sssd.conf.
sssd_check_socket_activated_responders[3907]: Please, consider either adjusting your services' line in /etc/sssd/sssd.conf or disabling the pam's socket by calling:
sssd_check_socket_activated_responders[3907]: "systemctl disable sssd-pam.socket"
systemd[1]: sssd-pam-priv.socket: Control process exited, code=exited, status=17/n/a
systemd[1]: sssd-pam-priv.socket: Failed with result 'exit-code'.
chown[3909]: /bin/chown: Zugriff auf '/var/log/sssd/sssd_sudo.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
sssd_check_socket_activated_responders[3908]: (Tue Jun 1 19:46:16:445429 2021) [sssd] [main] (0x0010): Misconfiguration found for the pam responder.
sssd_check_socket_activated_responders[3908]: The pam responder has been configured to be socket-activated but it's still mentioned in the services' line in /etc/sssd/sssd.conf.
sssd_check_socket_activated_responders[3908]: Please, consider either adjusting your services' line in /etc/sssd/sssd.conf or disabling the pam's socket by calling:
systemd[1]: Failed to listen on SSSD PAM Service responder private socket.
sssd_check_socket_activated_responders[3908]: "systemctl disable sssd-pam.socket"
systemd[1]: Dependency failed for SSSD PAM Service responder socket.
systemd[1]: sssd-pam.socket: Job sssd-pam.socket/start failed with result 'dependency'.
systemd[1]: sssd-pam.socket: Control process exited, code=exited, status=17/n/a
systemd[1]: sssd-pam.socket: Failed with result 'exit-code'.
systemd[1]: Closed SSSD PAM Service responder socket.
systemd[1]: Started SSSD Sudo Service responder.
sssd_sudo[3910]: Starting up
kernel: [ 41.516677] audit: type=1400 audit(1622569576.540:343): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/3906/cmdline" pid=1647 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
x11vnc[722]: --- x11vnc loop: 15 ---
dbus-daemon[3592]: [session uid=314401167 pid=3592] Activating via systemd: service name='org.a11y.Bus' unit='at-spi-dbus-bus.service' requested by ':1.19' (uid=314401167 pid=3912 comm="/usr/bin/veyon-worker {8e997d84-ebb9-430f-8f72-d45" label="unconfined")
systemd[3581]: Starting Accessibility services bus...
dbus-daemon[3592]: [session uid=314401167 pid=3592] Successfully activated service 'org.a11y.Bus'
systemd[3581]: Started Accessibility services bus.
kernel: [ 42.745392] audit: type=1400 audit(1622569577.764:344): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/3925/cmdline" pid=1647 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=314401167
at-spi-bus-launcher[3925]: dbus-daemon[3925]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=314401167 pid=3912 comm="/usr/bin/veyon-worker {8e997d84-ebb9-430f-8f72-d45" label="unconfined")
at-spi-bus-launcher[3925]: dbus-daemon[3925]: Successfully activated service 'org.a11y.atspi.Registry'
at-spi-bus-launcher[3930]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
x11vnc[722]: --- x11vnc loop: waiting for: 3933
x11vnc[722]: --- x11vnc loop: sleeping 2000 ms ---
pulseaudio[3587]: GetManagedObjects() failed: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
x11vnc[722]: --- x11vnc loop: 16 ---
x11vnc[722]: --- x11vnc loop: waiting for: 4105
x11vnc[722]: --- x11vnc loop: sleeping 2000 ms ---
x11vnc[722]: --- x11vnc loop: 17 ---
x11vnc[722]: --- x11vnc loop: waiting for: 4277
x11vnc[722]: --- x11vnc loop: sleeping 2000 ms ---
x11vnc[722]: --- x11vnc loop: 18 ---
Das scheinen mit die relevanten Zeilen zu sein (danach geht es noch mit viel waiting und pause weiter) . Aber: Ich weiß nicht, was ich daraus ableiten kann…
Sieht jemand, der sich besser auskennt, was da falsch ist?
Hi, die letzten Meldungen kommen von veyon, wie es aussieht?! Die habe ich auch. Vielleicht ist es also gar kein Problem mit dem Anmeldescript sondern mit veyon? Läuft bei dir der veyon-server, wenn du dich als User anmeldest?
Oh! Danke für die konkrete Nachfrage - die ein Missverständnis aufdeckt: Da ist mir gestern Abend wohl ein halber Satz untergegangen.
Eigentlich sollte da stehen:
„Trotzdem bleibt die Anmeldung mit einem AD-user kurz nach der Passworteingabe mit einem ubuntu-lila-Bildschirm hängen.“ Die Anmeldung wird also gar nicht beendet - Wir saßen ein paar Minuten (~5) vor dem Rechner und haben nur lila gesehen.
Wildes Durchklicken per STRG+ALT+Fx ließ dann irgendwann den Anmeldebildschirm wieder erscheinen und ich habe mich als linuxadmin angemeldet.
Ein log von gestern Abend habe ich schon (wobei ich das Syslog nicht geleert habe) - Die Zeilen oben sind ein Auszug davon. Habe es auch nochmal in Gänze gezippt und angehängt: lc7-log.zip (7,9 KB)
Der Anmeldevorgang beginnt ja so in Z. 130 (AD-user: bau).
Ich grüble darüber, ob @Michael mit seiner Vermutung Recht hat. Immerhin scheint ja der x11vnc einen Großteil der Wartezeiten zu verursachen. Veyon war schon im Basisimage installiert, aber nicht konfiguriert. Kann das die Probleme verursachen?
Ja, es scheint in der Tat etwas anderes (nicht der linuxmuster-linuxclient7) den Login zu blockieren. Probier doch mal, den ganzen Veyon Kram zu deinstallieren.
Ansonsten logge ich mich bei solchen Probleme auch gerne mal auf einer Textkonsole ein, da sieht man die logs live, dann ist es ein bisschen einfacher zu erkennen, was das Problem sein könnte.
Hallo.
Ich melde mich nochmal in Sachen linuxmuster-linuxclient7-Anmeldescript, weil es hier leider weiterhin so ist, dass es an einzelnen Clients Probleme mit der Anmeldung gibt.
Das Problem ist leider nicht gut reproduzierbar bzw ist es sogar so, dass sich
Schüler A an Client A nicht anmelden kann, während sich
Schüler B an Client A problemlos anmelden kann. Nach einem Wechsel der Schüler kann sich
Schüler A auch an Client B anmelden. Und manchmal klappt es nach etwas Wartezeit dann auch wieder, dass sich
Schüler A dann doch an Client A anmelden kann.
Es liegt also offensichtlich nicht an den Logins… daher die Frage, ob das evtl auch ein I/O-Problem auf dem Server sein kann? Wir haben dem v7-Server (VM unter Proxmox) wirklich sehr großzügig Hardware und Ressourcen gegeben. Ich bin nicht sicher, welche Datenmengen bei der gleichzeitigen Anmeldung einer ganzen Klasse über die Leitung geschaufelt werden muss – aber eine andere gute Erklärung habe ich im Moment nicht.
Wie schätzt ihr das ein?
Viele Grüße,
Michael
Das ist viel zu waage, um irgendwelche Schlussfolgerungen ziehen zu können.
Helfen würde es, wenn du nach einer fehlgeschlagenen Anmeldung sofort als Linuxadmin die logs auslesen und hier posten würdest.
Hallo Dorian,
ich kann es versuchen … allerdings höre ich von diesem Problem meistens erst später (wenn alles bereits gelaufen ist). Daher muss ich meinem Kollegen die entsprechenden Kommandos mitgeben. Geht es weiterhin um klist -k und linuxumuster-linuxclient status oder meinst du noch andere Log-Einträge?
Danke und viele Grüße,
Michael
Kannst du das Problem jetzt irgendwie eingrenzen?
Heute waren wieder 7 Clients betroffen …
Wie gesagt: Sobald ich einen „Sync + Start“ mache, geht es wieder aber wir starten in aller Regel unsynchronisiert, damit es schneller geht!
Direkt über Grub gebootet oder über Linbo? → LINBO bootet zuerst, immer PXE
Am Lan gebootet? → Ja, es sind fest installierte Rechner im Computerraum
Ist Linbo OFFLINE? → Bei diesen Stationen eigentlich nie! DHCP dauert allerdings seltsamerweise ein paar Sekunden, aber dann klappt es.
Es könnte tatsächlich am Dualboot liegen … das hatten wir doch irgendwann schon mal? Das würde evtl auch erklären, warum immer mal wieder andere Clients betroffen sind?!? Aber erklärt das auch, warum ein Sync+Start das Problem wieder behebt?
Übrigens: Vielleicht noch ein Anhaltspunkt: Unter Win10 gibt es zwar nie Anmeldeprobleme aber die angezeigte Uhrzeit ist dort immer falsch (2 Stunden zurück) – und das, obwohl ich den Reg.Key eingestellt habe wie hier beschrieben: https://www.windowspage.de/tipps/022085.html
Alle Win10-Clients sollten also immer UTC Zeit haben – egal welches OS.
Hallo Dorian, habe eben erst gemerkt, dass ich im April gar nicht auf Deinen Tipp geantwortet habe. Sorry!
Leider habe ich auch seitdem keine Zeit mehr gefunden, mich darum zu kümmern, wir IT-Leute werden hier in Berlin ständig mit Verwaltungskram genervt und müssen darum kämpfen, linuxmuster weiter nutzen zu dürfen.
Kurzum: Ich würde jetzt lieber den vorbereiteten neuen cloop mit Ubuntu20.04 ausprobieren, aber wo finde ich den, die client-servertools sind ja obsolet?
Liebe Grüße,
Frank
Das ist der neue offizielle Weg! Die client-servertools werden nicht mehr benötigt. Cloops online zu teilen ist obsolet, da der Weg des neu Aufsetzens jetzt sehr gut dokumentiert ist. Es ist zwar etwas aufwändiger, aber dann lernt man auch gleich ein bisschen was über den Prozess.
Bei Windows ist es genauso und da funktioniert es auch problemlos.
