Linuxclient7 auf Ubuntu 22.04 - Anmeldung sehr langsam und mit wenigen Benutzern gleichzeitig möglich

Hallo!
Ich bereite aktuelle den Linuxclient mit Ubuntu 22.04 als Ablösung von Ubuntu 18.04 (mit linuxmuster-client-adsso) vor.
Nach und nach funktioniert alles (inclusive leoclient2 mit VMs für XP, 7 und 10), allerdings habe ich ein großes Problem bei der Anmeldung.
Jede erste Anmeldung eines Benutzers auf einem Client dauert über 80 Sekunden und erzeugt währenddessen auf dem Server einen samba-Prozess mit ca. 80%-CPU-Auslastung, was die load entsprechend ansteigen lässt (top: waiting praktisch 0).
Melden sich mehrere Benutzer gleichzeitig an, klappt das bei maximal 6. Alle Weiteren erhalten ein Fehlermeldung.
Ist die Anmeldung der Ersten abgeschlossen, können sich die Nächsten anmelden.
Ähnlich sieht es aus, wenn an einem Rechner schon einmal jemand angemeldet war (Anmeldezeit ca. 50 Sek.), sich aber eine andere Person das erste Mal anmeldet.
Meldet sich dagegen eine Person zum wiederholten Mal an einem Rechner an (Anmeldezeit ca. 15 Sek.), scheint es keine Probleme zu geben.
Da sich bei uns zu Unterrichtsbeginn jeweils über 100 Benutzer anmelden, kann das so nicht funktionieren.
In den log-Dateinen auf dem Server und dem Client habe ich keine Anhaltspunkte gefunden, vielleicht auch an der falschen Stelle gesucht.
Wo kann ich suchen und optimieren? Wer hat mir einen Tipp?
Vielen Dank für eure Unterstützung.
Gruß - Rainer

Hallo Rainer,

Sind die Profile (Firefox, Libreoffice, usw … ) auf dem Server bei Useranmeldung synchronisiert ? Vielleicht liegt es daran.
In die Logs kann man schon sehen, was lang dauert. Aber in diesem Fall hast du auch genug Zeit um einen top aus einer Root-Konsole durchzuführen um zu sehen, was gerade bei der Anmeldung läuft.

Gruß

Arnaud

Hallo Arnuad!

Danke für deine schnelle Unterstützung.
Die serverbasierten Profile sind über symbolische Links nach ~/Home_auf_Server/Einstellungen_2204 umgesetzt (wobei ~/Home_auf_Server ein symbolischer Link auf ~/media/BENUTZER (H:) ist).
Da die Scripte für die Links bei jedem Anmelden abgearbeitet werden, kann es daran aus meiner Sicht nicht liegen.

Ein top auf dem Client zeigt in der Anmeldezeit v.a. 3 Prozesse:
sssd_be mit ständig 15-30% CPU
gnome-shell mit ständig 10% CPU
sssd_nss mit ständig 0-3% CPU
Alles weitere scheint vernachlässigbar.

In der log-Datei /var/log/sssd/sssd_bszleo.de.log befinden sich ca. 350 Zeilen der Form
„Adding ghost member for group [BENUTZER@bszleo.de]“ (von 1646 Zeilen) - da werden 350 DomänenBENUTZER hinzugefügt - Was soll das?
Ansonsten starten die Einträge in der log-Datei um 15:28:23 und enden um 15:30:46, ohne Einträge zwischen 15:28:33 und 15:30:45 (da beginnen die ghost member Einträge).
Hier die ganze log-Datei:
sssd_bszleo.de.log.odt (73,5 KB)

Meldet man sich mit einem anderen Benutzer an kommen zu den 1647 nur diese paar Zeilen hinzu:

(2022-11-02 16:08:18): [be[bszleo.de]] [ad_gpo_get_som_attrs_done] (0x0040): [RID#89] no attrs found for SOM; try next SOM

  • … skipping repetitive backtrace …
    (2022-11-02 16:08:18): [be[bszleo.de]] [ad_gpo_get_som_attrs_done] (0x0040): [RID#89] no attrs found for SOM; try next SOM
  • … skipping repetitive backtrace …
    (2022-11-02 16:08:18): [be[bszleo.de]] [ad_gpo_get_som_attrs_done] (0x0040): [RID#89] no attrs found for SOM; try next SOM
  • … skipping repetitive backtrace …
    (2022-11-02 16:08:18): [be[bszleo.de]] [ad_gpo_get_som_attrs_done] (0x0040): [RID#89] no attrs found for SOM; try next SOM
  • … skipping repetitive backtrace …
    (2022-11-02 16:08:19): [be[bszleo.de]] [ad_gpo_store_policy_settings] (0x0020): [RID#89] ini_config_file_open failed [2][Datei oder Verzeichnis nicht gefunden]
  • … skipping repetitive backtrace …
    (2022-11-02 16:08:19): [be[bszleo.de]] [ad_gpo_store_policy_settings] (0x0020): [RID#89] Error encountered: 2.
  • … skipping repetitive backtrace …

    Leider verstehe ich von der Anmeldung zu wenig, um hier schlau zu werden.
    Hat jemand einen Ansatz?

Gruß - Rainer

Hallo Rainer,
ich habe meinen Client auf die 22.04 upgedatet.
Läuft wie vorher (20.04) auch recht flüssig uns stabil.
Unser Server läuft auf 7.1
Wie ist das bei dir?
Grüße Ralf

Hallo Ralf!
Wir sind auf dem aktuellen Stand.
linuxmuster.net packages:
Base…: 7.1.20-0
Linbo…: 4.0.41-0
WebUI…: 7.1.38
Sophomorix…: 3.90.7-1
opnsense…: 2.7.6
Wie lange dauert bei euch eine Anmeldung auf einem frisch synchronisierten Ubuntu 22.04?
Gruß - Rainer

Hallo Rainer,

Bei der erstmaligen Anmeldung, bei der noch keine Remoteverknüpfungen (Firefox, etc.) angelegt sind und erst mal die Profile vom Linuxadmin kopiert und ins Home auf dem Server verknüpft werden dauert das bei mir mit aktueller Hardware (Mittelklasse Ryzen 5/Intel i5; nvme ssd’s) maximal 20-25s. Jede weitere Anmeldung liegt dann bei ca. 10s. Die Anmeldezeit hast sich bei mir von 20.04 zu 22.04 fast halbiert!

Ich hatte aber ein ähnlich gelagertes Problem nach dem Upgrade von 20.04 auf 22.04…allerdings ging da die Anmeldung gar nicht und lief in einen Tiemeout. Die seltsamen Meldungen vom sssd Service von dir kommen mir aber bekannt vor…ist schon lange her…

Kann es sein, dass ihr gnome-shell exensions benutzt? Die waren bei mir für das Problem verantwortlich. Wenn man die einfach installiert liegen die beim linuxadmin unter ~/.local/share/gnome-shell/extensions/. Nach dem kopieren des Profils des Vorlagenbenutzers beim Anmeldevorgang eines AD-users geht da irgendwas kaputt…habe damals nicht genauer weitergesucht. Ich habe das Problem so gelöst, dass ich alle lokalen extensions ins globale Verzeichnis /usr/share/gnome-shell/extensions/ kopiert und die Rechte angepasst habe (root:root und 644 für alle Dateien). Vielleicht hilft es euch?

LG Dominik

Hallo Dominik!
Danke für den Tipp.
Bei uns ist aber in /home/linuxadmin/.local/share/gnome-shell/ nur

  • application_state
  • gnome-overrides-migrated
    also keine extensions.
    Gruß - Rainer

Hallo!
Ich habe jetzt mal ein ganz frisches Ubuntu 22.04 aufgesetzt und nur die Domänenanmeldung eingerichtet.
Damit erhalte ich auch die von Dominik angegebenen Zeiten:

  • Erste Anmeldung eines Benutzers ca. 20-25 Sek.
  • Weitere Anmeldungen des Benutzers ca. 10 Sek.

Irgend etwas an meiner Installation scheint kaputt zu sein. Ich kann mir das aber nicht erklären.
Ich fange jetzt also ganz von vorne an (macht mehrere Tage Arbeit) und an irgend einer Stelle wird das Problem (vielleicht) wieder auftauchen. FRUST! ;-(
Gruß - Rainer

Hi RAiner,

sorry, dass ich nicht weiterhelfen kann.
Random insights:

  • Kann nur berichten, dass unser hochgewachsenes Ubuntu Mate mit lightdm sicher keine 20-25 Sek. braucht, eher immer nur 10 Sekunden, auch für den ersten Benutzer.
  • systemd-accounts (oder hieß ähnlich) war früher mal zuständig für unnötige wartezeit
  • heute habe ich deinen Post gesehen, weil ich selbst Anmeldeprobleme hatte, bis hin zu gar keiner Domänenanmeldung (mehr)… Grund war, dass mein Server nur noch 1 CPU hatte… warum auch immer (proxmox). Seit er mit 6 VCPUs läuft, ist alles wieder ok.

Vielleicht hilft das ein oder andere.
VG, Tobias

Hallo.
Vielleicht hilft auch einer der Tipps von dieser Seite?

Viele Grüße,
Michael

Hallo!

Ich habe mittlerweile eine zentrale Ursache gefunden.
Für das Durchreichen von USB-Geräten in VirtualBox muss der Benutzer in der Gruppe „vboxusers“ sein. Da ich keine andere Lösung gefunden hatte, habe ich ein Anmeldescript geschrieben, das den Anmeldenden der Gruppe vboxusers hinzufügt (addgroup $USER vboxusers).
Das hatte aus einem mir nicht ersichtlichen Grund zur Folge, dass die Anmeldung fast eine Minute länger dauerte und in dieser Zeit eine CPU auf dem Server nahezu vollständig in Beschlag genommen wurde.
Ich habe das nun so gelöst, dass der Benutzer beim Anmelden in die Datei /etc/group eingetragen wird. VirtualBox ist damit zufrieden und die Anmeldezeit ist bei den von anderen beschriebenen ca. 25 Sekunden.

Trotzdem ist die Last auf dem Server (16 CPU, 48 GB RAM) in der Zeit sehr hoch und es können sich nur ca. 6 Benutzer gleichzeitig anmelden, wenn diese an diesen Rechnern noch nicht angemeldet waren. Nach ca. 30 Sekunden geht es dann mit den nächsten Benutzern weiter. Für einen Raum (16 SuS) macht das knapp eine Minute.
Das ist natürlich bei >100 Anmeldungen nach einer großen Pause ein Problem für das ich noch keine gute Lösung habe.

Mit der Anmeldezeit von 10 Sekunden von Tobias, würde sich das Problem mehr als halbieren, aber wie komme ich dort hin?

Gruß - Rainer

Hallo!
Ich bin etwas weiter gekommen, habe dabei aber mehr Fragen als Antworten gefunden.
Beim Start von Ubuntu 22.04 können drei Services nicht gestartet werden (failed):

  • sssd-nss.socket
  • sssd-pam-priv.socket
  • sssd-pam.socket
    (siehe unten # systemctl status sssd…)

Diese stehen in Konflikt mit dem Eintrag „services = nss, pam“ in /etc/sssd/sssd.conf (Ergebnis aus # systemctl restart sssd-pam-priv.socket ).
Wenn ich nss und pam in sssd.conf entferne, funktioniert die Anmeldung nicht mehr.
Es hat nach meinen Test aber keine negativen Auswirkungen auf die Anmeldung, wenn ich die Services disable:

# systemctl disable sssd-pam-priv.socket 
# systemctl disable sssd-nss.socket 
# systemctl disable sssd-pam.socket 

Das macht auch Sinn, da die Services bei mir ja eh nicht funktionieren.
Warum wurden diese dann aber enabled?
Wie ist das bei euch, habt ihr die gleiche Situation mit den Services?

Gruß - Rainer

# systemctl status sssd*
× sssd-nss.socket - SSSD NSS Service responder socket
     Loaded: loaded (/lib/systemd/system/sssd-nss.socket; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sat 2022-11-12 11:49:50 CET; 7min ago
   Triggers: ● sssd-nss.service
       Docs: man:sssd.conf(5)
     Listen: /var/lib/sss/pipes/nss (Stream)
    Process: 1471 ExecStartPre=/usr/libexec/sssd/sssd_check_socket_activated_responders -r nss (code>
        CPU: 2ms

Nov 12 11:49:50 l0020p01 systemd[1]: Starting SSSD NSS Service responder socket...
Nov 12 11:49:50 l0020p01 sssd_check_socket_activated_responders[1471]: [sssd] [main] (0x0070): Misco>
Nov 12 11:49:50 l0020p01 sssd_check_socket_activated_responders[1471]: The nss responder has been co>
Nov 12 11:49:50 l0020p01 sssd_check_socket_activated_responders[1471]: Please, consider either adjus>
Nov 12 11:49:50 l0020p01 sssd_check_socket_activated_responders[1471]: "systemctl disable sssd-nss.s>
Nov 12 11:49:50 l0020p01 systemd[1]: sssd-nss.socket: Control process exited, code=exited, status=17>
Nov 12 11:49:50 l0020p01 systemd[1]: sssd-nss.socket: Failed with result 'exit-code'.
Nov 12 11:49:50 l0020p01 systemd[1]: Failed to listen on SSSD NSS Service responder socket.

× sssd-pam-priv.socket - SSSD PAM Service responder private socket
     Loaded: loaded (/lib/systemd/system/sssd-pam-priv.socket; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sat 2022-11-12 11:49:50 CET; 7min ago
   Triggers: ● sssd-pam.service
       Docs: man:sssd.conf(5)
     Listen: /var/lib/sss/pipes/private/pam (Stream)
    Process: 1473 ExecStartPre=/usr/libexec/sssd/sssd_check_socket_activated_responders -r pam (code>
        CPU: 1ms

Nov 12 11:49:50 l0020p01 systemd[1]: Starting SSSD PAM Service responder private socket...
Nov 12 11:49:50 l0020p01 sssd_check_socket_activated_responders[1473]: [sssd] [main] (0x0070): Misco>
Nov 12 11:49:50 l0020p01 sssd_check_socket_activated_responders[1473]: The pam responder has been co>
Nov 12 11:49:50 l0020p01 sssd_check_socket_activated_responders[1473]: Please, consider either adjus>
Nov 12 11:49:50 l0020p01 sssd_check_socket_activated_responders[1473]: "systemctl disable sssd-pam.s>
Nov 12 11:49:50 l0020p01 systemd[1]: sssd-pam-priv.socket: Control process exited, code=exited, stat>
Nov 12 11:49:50 l0020p01 systemd[1]: sssd-pam-priv.socket: Failed with result 'exit-code'.
Nov 12 11:49:50 l0020p01 systemd[1]: Failed to listen on SSSD PAM Service responder private socket.

× sssd-pam.socket - SSSD PAM Service responder socket
     Loaded: loaded (/lib/systemd/system/sssd-pam.socket; disabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sat 2022-11-12 12:03:18 CET; 15min ago
   Triggers: ● sssd-pam.service
       Docs: man:sssd.conf(5)
     Listen: /var/lib/sss/pipes/pam (Stream)
        CPU: 1ms

Nov 12 12:03:18 l0020p01 systemd[1]: Starting SSSD PAM Service responder socket...
Nov 12 12:03:18 l0020p01 sssd_check_socket_activated_responders[2429]: [sssd] [main] (0x0070): Misco>
Nov 12 12:03:18 l0020p01 sssd_check_socket_activated_responders[2429]: The pam responder has been co>
Nov 12 12:03:18 l0020p01 sssd_check_socket_activated_responders[2429]: Please, consider either adjus>
Nov 12 12:03:18 l0020p01 systemd[1]: Dependency failed for SSSD PAM Service responder socket.
Nov 12 12:03:18 l0020p01 sssd_check_socket_activated_responders[2429]: "systemctl disable sssd-pam.s>
Nov 12 12:03:18 l0020p01 systemd[1]: sssd-pam.socket: Job sssd-pam.socket/start failed with result '>
Nov 12 12:03:18 l0020p01 systemd[1]: sssd-pam.socket: Control process exited, code=exited, status=17>
Nov 12 12:03:18 l0020p01 systemd[1]: sssd-pam.socket: Failed with result 'exit-code'.
Nov 12 12:03:18 l0020p01 systemd[1]: Closed SSSD PAM Service responder socket

Hallo Rainer,

Nur um sicher zu sein : du sprichst da von linuxmuster-client-adsso, und nicht von linuxmuster-linuxclient7, oder ?

Ja, das muss man auf keinen Fall machen : sssd kümmert sich um account mapping und authentifizierung.

Ich würde an deiner Stelle den Inhalt von /etc/nsswitch.conf überprüfen.

Gruß

Arnaud

Hallo Arnaud!
Es ist linuxmuster-linuxclient7.
Gruß - Rainer

Hallo Rainer,

Damit kommen dann einige Tools. Was sagt z.B. linuxmuster-linuxclient7 status ?

Gruß

Arnaud

Hallo Arnaud!
Danke für den Tipp.
Auch ohne die Dienste sssd-pam-priv.socket, sssd-nss.socket und sssd-pam.socket scheint alles OK (siehe unten).
Sind bei dir diese Dienste auch enabled und funktionieren die?
Guß - Rainer

# 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] * bszleo.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! ####

Hallo Rainer,

Bei mir sind sie alle drei in Failed Status und enabled.

Gruß

Arnaud

Hallo Arnaud!
Dann wäre noch die Frage, warum die Dienste aktiviert sind - ich hatte noch keine Zeit das zu recherchieren.
Aber ich kann mir vorstellen, das ist etwas Unnötiges, was alle betrifft.
Gruß - Rainer