Keine Ahnung, aber solange du es nicht reproduzieren kannst, kann ich dir jedenfalls leider nicht helfen.
VG, Dorian
Hallo Michael,
bei dem ersten Versuch, war der Start der beiden zeitgleich oder nahe beieinander?
Beste Grüße
Thorsten
Hi Thorsten!
Es war schon nacheinander … aber auch nicht mit 30 Sekunden Wartezeit dazwischen … na ja, wir müssen es einfach weiter beobachten. Aber da es nun definitiv nicht das erste Mal war, dass es aufgetreten ist, denke ich, dass nicht alles 100% i.O. ist.
Viele Grüße,
Michael
Hallo,
hast du dich mit dem gleichen Login am zweiten Client angemeldet mit dem du am ersten schon angemeldet warst? Oder war da ein Abmelden und ein Warten dazwischen? Wie lange wurde gewartet?
LG
Holger
Hallo Holger,
es war so, dass ich mich an Client 1 angemeldet habe, dann das Fenster gewechselt habe und mich mit den gleichen Credentials an Client 2 angemeldet habe. Die Zeit dazwischen war nicht allzu lang … gestoppt habe ich das nicht, aber Client 1 war mit der Anmeldung durch! Auf Client 2 hatte ich dann aber wie schon oben erwähnt zunächst keine Shares – erst wieder, als der fehlerhafte Client 2 mit „Sync & Start“ neu gestartet wurde!
Heute in der Schule gab es übrigens wieder eine Beobachtung, die in die gleiche Richtung weist: Die Anmeldung als User funktionierte nicht – mit meinem Profil allerdings sehr wohl, weil ich an diesem Client gestern schon mal angemeldet war! Und siehe da: Ich hatte keine Shares. Erst nach einem Sync + Start waren sie wieder da und dann konnten sich auch alle anderen anmelden. Vielleicht steckt ja doch wieder ein Kerberos-Problem dahinter??
Viele Grüße,
Michael
Hallo,
das bedeutet es könnte auch an der Doppelanmeldung im Netz gelegen haben.
… und er wurde seit dem nicht gesynct?
Dann könnte das zusätzlich bedeuten, dass der ProfilCache auf dem Client nicht richtig abgeräumt wird beim Logout und dass wenn er das nicht wird das Verbinden der Shares beim nächsten Login fehl schlägt.
Beides kannst du mal testen, dann wissen wir mehr.
LG
Holger
Hallo Michael,
Bitte mache folgendes, wenn es das nächste Mal nicht klappt:
- Als Linuxadmin anmelden
sudo klist -ksudo linuxmusterLinuxclient7 status
Und jeweils die Ausgabe Posten.
VG, Dorian
Wieso sollte das denn zu einem Problem führen?
Hallo Till,
das gab in der Vergangenheit schon Probleme damit.
Beim neuen Linuxclient weiß ich das nciht, deswegen hab ich ja gesagt er solle das testen.
Wenn du sagst, dass das kein Problem ist, dann bin ich beruhigt und habe was gelernt 
LG
Holger
Hi.
Also Dorian hatte in #65 ja schon geklärt, dass es prinzipiell kein Problem sei und dass man sich parallel an mehreren Clients mit den gleichen Credentials anmelden könne. Bisher tauchte das Problem hier vermutlich nur auf unsynchronisierten Clients auf, bei denen ein alter Login aber bereits angelegt war. Der Login klappte – aber die Shares fehlten. Ein neuer „Sync + Start“ hat da bisher immer geholfen. Allerdings starten wir unsere Clients in der Regel aus Zeitgründen unsynchronisiert.
Viele Grüße,
Michael
Hallo Michael,
Bitte teste das
Es sollte nicht nötig sein, synchronisiert zu starten.
VG, Dorian
Ja, ich weiß. Ich kann es aber erst testen, wenn der Fall wieder auftritt. Heute war alles OK.
Hallo.
Jetzt ist der Fall wieder da – ich kann mich zwar anmelden, habe aber mit dem neuen linuxmuster-linuxclient7 keine Netzwerk-Shares. In der Zwischenzeit wurde von einem anderen Client (eine VM, die immer als Master verwendet wird) ein neues Image gezogen. Dieser Client, an dem ich jetzt sitze, wurde aber nicht synchronisiert gestartet. Ist das das Problem?
Du wolltest ja die Ausgabe der beiden Befehle haben – hier kommen sie
sudo klist -k
[sudo] Passwort für <login>:
(pam_mount.c:365): pam_mount 2.16: entering auth stage
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
25 RAUM1-LEHRER-PC$@LINUXMUSTER.MEINE-DOMAIN.DE
25 RAUM1-LEHRER-PC$@LINUXMUSTER.MEINE-DOMAIN.DE
25 RAUM1-LEHRER-PC$@LINUXMUSTER.MEINE-DOMAIN.DE
25 host/RAUM1-LEHRER-PC@LINUXMUSTER.MEINE-DOMAIN.DE
25 host/RAUM1-LEHRER-PC@LINUXMUSTER.MEINE-DOMAIN.DE
25 host/RAUM1-LEHRER-PC@LINUXMUSTER.MEINE-DOMAIN.DE
25 host/raum1-lehrer-pc.linuxmuster.mein-domain.de@LINUXMUSTER.MEINE-DOMAIN.DE
25 host/raum1-lehrer-pc.linuxmuster.mein-domain.de@LINUXMUSTER.MEINE-DOMAIN.DE
25 host/raum1-lehrer-pc.linuxmuster.mein-domain.de@LINUXMUSTER.MEINE-DOMAIN.DE
25 RestrictedKrbHost/RAUM1-LEHRER-PC@LINUXMUSTER.MEINE-DOMAIN.DE
25 RestrictedKrbHost/RAUM1-LEHRER-PC@LINUXMUSTER.MEINE-DOMAIN.DE
25 RestrictedKrbHost/RAUM1-LEHRER-PC@LINUXMUSTER.MEINE-DOMAIN.DE
25 RestrictedKrbHost/raum1-lehrer-pc.linuxmuster.mein-domain.de@LINUXMUSTER.MEINE-DOMAIN.DE
25 RestrictedKrbHost/raum1-lehrer-pc.linuxmuster.mein-domain.de@LINUXMUSTER.MEINE-DOMAIN.DE
25 RestrictedKrbHost/raum1-lehrer-pc.linuxmuster.mein-domain.de@LINUXMUSTER.MEINE-DOMAIN.DE
(pam_mount.c:133): clean system authtok=0x558bfd8dfe70 (1073741824)
und:
sudo linuxmuster-linuxclient7 status
[INFO] #### linuxmuster-linuxclient7 status ####
[INFO] Linuxmuster-linuxclient7 is setup!
[INFO] Testing if domain is joined...
[INFO] Checking joined domains
[INFO] Joined domains:
[INFO] * linuxmuster.mein-domain.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
kinit: Vorauthentifizierung fehlgeschlagen bei Anfängliche Anmeldedaten werden geholt.
[ERROR] Could not get a kerberos ticket for the Computer Account!
[ERROR] Logins of non-cached users WILL NOT WORK!
[ERROR] Please try to re-join the Domain.
================================================================================
This Computer is joined to a domain but it was not possible to authenticate to the domain controller.
There is an error with your domain join!
This happens when you reboot the client without creating an image.
Please try to re-join the domain using 'linuxmuster-linuxclient7 setup'.
================================================================================
Viele Grüße,
Michael
Hallo Michael,
Ich tippe, dass es daran liegt, dass du ein neues Image erstellt, und den Client nicht synchronisiert hast. Das kann dazu führen, dass der Domänenjoin im AD nicht mehr zu dem auf dem lokalen Rechner passt.
Was auch zu Problemen führen kann ist, wenn ein dualboot ausgeführt wird, wenn Linbo keine Verbindung zum Server hat, zum Beispiel bei Laptops.
VG, Dorian
Hallo nochmal.
Etwas ähnliches hatten wir ja neulich auch auf den Windows-Clients beobachtet – daher nochmal ganz konkret nachgefragt: Muss/Sollte man also tatsächlich nach der Erstellung eines neuen .cloops alle Clients synchronisiert starten lassen? (das war unter v6.x nicht so – deshalb frage ich nochmal explizit danach).
Hintergedanke:
Wir haben eine Ausleihstation für Laptops. Diese Geräte starten über grub2 direkt Win10. LINBO wird dort nur gestartet, wenn mit dem Image etwas geschehen soll. Auf all diesen Geräten war ebenfalls heute Morgen keine Domänenanmeldung mehr möglich, weil (?) zwischenzeitlich ein neues Master-Image von einem anderen Rechner erstellt wurde. Das klingt doch sehr nach dem gleichen Phänomen …
Viele Grüße,
Michael
Hallo Michael,
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.
VG, Dorian
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…
Bis später,
Michael
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?
Danke und Grüße
Michael
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?
Viele Grüße
Michael
Hi Michael,
Wie meinst du das? Was passiert nach dem „Kurz“?
Kannst du bitte einmal folgendes machen:
echo "" > /var/log/syslog- als User anmelden
- (ggf. per ssh)
linuxmuster-linuxclient7 print-logs -c← hier von die Ausgabe bitte posten
VG, Dorian