Hallo – ich versuche es nochmal hier im Forum.
Unser bionic-Client (kommt hier aus der Liste) verlinkt auf dem Desktop der User die Shares nicht mehr. Es taucht kein Icon mehr auf…
Wenn ich mich da als Lehrer anmelde, sind zwar meine Server-Shares unter /srv/samba/schools/default-school sowie unter /var/lib/samba/sysvol vorhanden und eingehängt aber auf dem Desktop gibt es keine Symbole/Links mehr zu den entsprechenden Verzeichnissen. Das funktionierte irgendwann schon mal und ich weiß nicht, warum es jetzt nicht mehr geht.
Kann es sein,
dass die Links für den Vorlagen-User „linuxadmin“ auch vorhanden sein müssen, damit sie wieder übernommen werden? Wer kann für mich ggf. nachsehen, wie diese Links im linuxadmin-Profil aussehen bzw wohin sie zeigen müssen (denn der linuxadmn selbst erhält ja keine Shares)
oder
dass meine # /etc/linuxmuster-client/adsso.conf vom 20181127 mittlerweile überarbeitet wurde und ich da die ganze Zeit eine veraltete Version habe??
Ich hatte auf dem gleichen Client die Icons zu meinen Shares jedenfalls schon mal – vorhin habe ich /home/cache geleert und mich neu angemeldet. Da erschien nichts mehr. Ein turnkey habe ich auch schon neu losgelassen. Ist zwar erfolgreich durchgelaufen – hat aber leider nichts geändert …
Gerade erst in der Orga-Übersicht gesehen: dieser Beitrag hätte vielleicht direkt an @Tobias gehen sollen!?? Kannst du hier dazu etwas sagen? Oder soll ich das unter github als issue anlegen?
Könnte jemand, bei dem die Verlinkung funktioniert, mir den Gefallen tun und bei sich nachsehen, wie die Rechte der Scripte unter /etc/linuxmuster-client/login.d aussehen müssen? Die Scripte sind hier alle nicht executable – vielleicht liegt es ja daran??
Danke, Holger.
Mir ist gerade noch etwas anderes aufgefallen:
Laut Doku sollen beim Login alle möglichen Scripte ablaufen – unter anderem zunächst das Script /etc/linuxmuster-client/login.d/00_userinfo.sh das dafür sorgt, dass ein paar Umgebungsvariablen unter /tmp/$USER gespeichert werden.
Das ist hier nicht der Fall. Es gibt dort aber eine Datei namens -rw------- 1 meinlogin domain users 0 Dez 28 18:08 config-err-6E7uXd, die evtl stattdessen angelegt wurde?
Daher vermute ich mal sehr stark, dass alle weiteren Scripte schon deshalb nicht ausgeführt werden. Ich habe übrigens allen Scripten das +x Bit gegeben, um zu schauen, ob es daran liegt. Das hat bisher aber nichts geändert.
Wenn ich das richtig sehe, ist @Tobias für das adsso unter Bionic zuständig. Der ist aber leider AFK, wie es scheint??
… und wieder etwas schlauer:
Beim Login eines Users wird das Script /etc/linuxmuster-client/scripts/login.sh aufgerufen.
Das wiederrum ruft die anderen, oben genannten Scripte auf. Daher müssen die auch kein +x Bit besitzen!!!
Wenn ich das Script aber als User aufrufe, erhalte ich hier:
Executing /etc/linuxmuster-client/login.d/00_userinfo.sh ...
Failed to connect to ldap URL 'ldaps://server.linuxmuster.meine-domain.de' - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldaps://server.linuxmuster.meine-domain.de' with backend 'ldaps': LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to ldaps://server.linuxmuster.meine-domain.de - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
[...]
Es scheitert also an dem Befehl in Zeile 22 (ad_query): ldbsearch -k yes -H ldaps://$servername.$ad_domain "(&(samaccountname=$USER))"
bzw ohne Variablen: ldbsearch -k yes -H ldaps://server.linuxmuster.meine-domain.de "(&(samaccountname=meinlogin))"
Vielleicht kann ich meine Bitte von oben also abändern? Holger (oder gerne auch andere), könntest Du diesen Befehl bei Dir als User testen?
Funktioniert das bei Dir?
Die Option -k yes versucht die Abfrage über ein Kerberos-Ticket. Mit klist kann man sich (als User!) den Ticketzwischenspeicher ansehen.
Ok, jetzt weiß ich (wieder), was da faul ist (unter Punkt 2):
Es ist so: Wenn man eine ldap-Abfrage via Kerberos macht, MUSS man ldap und nicht ldaps verwenden. Das ist in dem Script 00_userinfo.sh also ein Bug! Da steht es falsch, da die Abfrage zusammen mit -k yes UND ldaps durchgeführt wird. Wenn man das s entfernt, laufen die Scripte durch und die Links zu den Shares werden auch wieder richtig angzeigt!
Also: In Zeile 22 in dem Script muss das s bei ldaps entfernt werden!!
Ergänzung: Gut möglich, dass dieser Fehler nur dann auftaucht, wenn man dem v7-Server einen FQDN und ein gültiges Zertifikat gegeben hat!
ldb-tools nach Badlock | Stefan Kania
<https://www.kania-online.de/ldb-tools-nach-badlock/amp/>
Es ist so: Wenn man eine ldap-Abfrage via Kerberos macht, MUSS man ldap
und nicht ldaps verwenden. Das ist in dem Script |00_userinfo.sh| also
ein Bug! Da steht es falsch, da die Abfrage zusammen mit |-k yes| UND
ldaps durchgeführt wird. Wenn man das s entfernt, laufen die Scripte
durch und die Links zu den Shares werden auch wieder richtig angzeigt!
Also: In Zeile 22 in dem Script muss das s bei ldaps entfernt werden!!
OK: krass.
Dann muss ich das also nicht mehr ausprobieren?
Ich hab jetzt einen Client in der Schule laufen und schau nach, wie das
in meiner Datei drin steht.
Bei mir steht die Zeile in Zeile 23 und enthält ein „s“ hinter dem http.
Ich hab jetzt also diese Zeile als „ich“ (Usernamen geändert) am Cleint
angemeldet in einem Terminal abgesetzt:
Kann es auch sein, dass es bei dir klappt, da du intern keine „echte Domain“ verwendest, während ich auch intern unseren FQDN durchgereicht habe?! Jedenfalls funktioniert der Befehl bei mir mit ldaps:// nicht – während er mit ldap:// durchläuft und die gewünschte Ausgabe liefert.
Guck mal hier – da steht das auch nochmal. Über diese Seite bin ich irgendwann schon mal gestolpert und hatte es zwischenzeitlich wieder aus dem Kurzzeitgedächtnis gelöscht:
Dass es mit ldaps nicht klappt riecht für mich irgendwie nach einem Zwertifikatsproblem …
Kann es sein, dass dein Client dem (selbstsigierten?) Serverzertifikat nicht vertraut?
Nur so ein Gedanke …
Hi Dorian … ich glaube, dass eher das Gegenteil der Fall sein könnte?? Ich habe auf unserem v7 Server auch intern unseren FQDN benutzt. Zudem hat der v7-Server ein gültiges LE-Cert, was vom Client auch bestätigt wird:
@MachtDochNix: Warum? Es ist ja noch nicht abschließend geklärt, warum das bei mir ohne s sein muss, während es woanders auch mit funktioniert
Ich würde das hier zusammen lassen…
Kann es sein, dass standardmäßig nur dem selbstsignierten Zertifikat, das vom Linuxmuster setup generiert wird, vertraut wird?
Ich kenn mich damit ehrlich gesagt nicht gut genug aus, aber es gab mal irgendwo einen Wiki Eintrag (oder einen Forenbeitrag?) in dem es um den Zertifikatskram ging, vielleicht steht da ja mehr.
@MachtDochNix: Warum? Es ist ja noch nicht abschließend geklärt, warum das bei mir ohne s sein muss, während es woanders auch mit funktioniert
Ich würde das hier zusammen lassen…
Weil du die Überschrift schon als gelöst markiert hast, vielleicht?! siehe post #6
Ein Problem --> ein neuer Thread und bei dem eine möglich treffende Überschrift! Erleichtert auch das wiederfinden.
Wenn ich es stattdessen mit SSL-Verschlüsselung und ohne die Option -Z über ldaps:// versuche, klappt es sowohl vom Server als auch vom Client aus! Das könnte ein Anhaltspunkt sein!?
Mir ist aber nicht klar, welche Verschlüsselung denn nun gewählt wird!?
Bisher war ich von SSL ausgegangen, da in o.g. Script ldbsearch -k yes -H ldaps:// stand, was dann über Port 636 bzw 3269 läuft…!?
