Fragen zum neuen Anmeldescript für Linuxclients (linuxmuster-linuxclient7)

Clientpflege Linuxclient
67

Also ein logon.sh gibt’s da bei mir gar nicht. Das Einzige, womit ich dienen kann, wäre:
-rwxrwx---+ 1 root BUILTIN\administrators 410 Sep 14 2019 login.script

68

Hallo Frank,

Das scheint mir ein Problem mit deinen sysvol Berechtigungen zu sein …

VG, Dorian

69

So jetzt nochmal ein bisschen ausführlicher:

Kannst du bitte mal probieren, als der betroffene Nutzer das //server/sysvol share manuell einzuhängen? Da sollte eigentlich jeder Lese und Ausführzugriff auf den Scripts Ordner haben.
Was gibt ein

ls /srv/samba/xyzmueller/sysvol/linuxmuster.lan/scripts/default-school/custom/linux/

?
VG, Dorian

70

Hallo zusammen,

Dank der guten Arbeit von @cweikl gibt es jetzt auch eine Dokumentation über den neuen Linuxclient:
https://docs.linuxmuster.net/de/latest/clients/linux-clients/linux-client-current-method.html

Und auch für den Umzug vom alten linuxmuster-client-adsso:
https://docs.linuxmuster.net/de/latest/clients/linux-clients/linux-client-migration.html

Viel Spaß damit :slight_smile:

VG, Dorian

2 „Gefällt mir“
71

Hallo Dorian,
heute haben wir einen kompletten Raum mit dem Ubuntu 20.04 Image und dem neuen linuxmuster-linuxclient7 Anmeldescript ausgestattet. Es läuft – aber es haben sich hier und da Fragen ergeben:

  • Wie reagiert das Script, wenn man versucht, sich an mehreren Clients mit den gleichen Credentials anzumelden? Werden die Shares beim zweiten Client nicht mehr eingebunden?
  • Ich hatte heute Morgen ein paar Mal auch das Problem ohne einen zweiten Client, dass ich als User angemeldet war aber gar keine Shares hatte. Eine erneute Anmeldung hat’s dann behoben – dann waren sie da. Hast du eine gute Idee?

Viele Grüße,
Michael

72

Hi Michael,

Sie werden bei beiden eingebunden. Änderungen auf einem Client sind an jedem anderen sofort, bzw. nach Neuladen mit F5 sichtbar.

Nicht ohne genauere Infos.

VG, Dorian

73

Hi Dorian,
ok, in dem Fall klappt die Anmeldung nicht immer … welche Infos soll ich bereitstellen?

Gesehen habe ich im dmesg-Log zwischendurch CIFS-Error, die ich aber bisher ignoriert habe. Kann ich bei Bedarf aber nochmal nachsehen…

Viele Grüße,
Michael

74

Hallo Michael,

wahrscheinlich sind das logins direkt oder kurz nach dem Booten: dann ist die Systemzeit noch nicht gesynct un dder Login schlägt fehl, oder eben halb fehl: Login geht, aber shares sind nciht da.

Teste mal mit „Kulanzsekunden“ (30 Sekunden) Warten vor dem Login (nach dem Boot).

LG

Holger

75

Hallo Holger,
kann natürlich sein – wäre aber nicht schön. Da fände ich es noch eleganter, wenn man den Anmeldeprompt einfach für 3 Sekunden blockiert oder sowas … denn die Shares müssen imho absolut verlässlich da sein, sonst ist Gemeckere vorprogrammiert.

Übrigens gibt es ein größeres Problem, wenn man es (so wie wir jetzt) mit dem Duaboot von Win10 & Ubuntu versucht und der Systemzeit … dazu mache ich aber gleich einen eigenen Thread auf.

Viele Grüße,
Michael

76

Hallo Michael,

das Problem wurde schon vor einiger Zeit diskutiert.
Die Lösung steht im Forum.
Man bringt Windows bei es so zu machen, wie alle anderen Betriebsysteme.

LG

Holger

77

Hallo Michael,

Bitte verifiziere das. Wenn es tatsächlich daran liegt, gibt es sicherlich eine Lösung.

VG, Dorian

78

Hi.
Wenn man die gleich Situation nochmal über’s Knie brechen will, funktioniert alles – ist das auch Murphys Gesetz? :slight_smile:

Ich könnte mir übrigens vorstellen, dass die fehlenden Shares vor ein paar Tagen evtl. mit der falschen Systemzeit zusammenhängen könnten?!? An den Clients wurde munter Win und Linux abwechselnd gestartet – und das noch bevor der Reg.Key für Win10 verwendet wurde. Zwischendurch stand also immer wieder die falsche Zeit im BIOS. Kann es sein, dass dein Script und die Linux-Shares dann aus dem Tritt kommen? Jetzt ist jedenfalls alles auf UTC eingestellt …

Viele Grüße,
Michael

79

Hallo Michael,

… aber genau das hatte ich doch geschrieben…
Hattest du meinen Post nicht gelesen?

Hier ist er nochmal:

LG

Holger

80

Hallo Holger,
doch – habe ich alles gelesen aber zu dem Zeitpunkt war mir noch nicht klar, dass das „gemischte“ Booten hier so einen Einfluss haben könnte. Es ist ja auch so, dass beim LINBO-Start ausdrücklich steht: „Time Sync“ – dieser Vorgang wird aber von Ubuntu scheinbar auch nochmal wiederholt. Wozu, wenn’s doch schon erledigt ist?

(Mir ist auch weiterhin nicht klar, warum Windows nicht auch einfach überall und durchgehend UTC verwendet und gut ist … weshalb mal wieder ein Extra-Süppchen? Sind das nur historische Gründe – als es noch kein Internet gab? :slight_smile: )

Viele Grüße,
Michael

81

Hallo Michael,

über Gruppenrichtlinien oder Registry kann man Windows beim Bootvorgang dazu bringen auf eine aktive Netzwerkverbindung zu warten. Siehe hier:
https://social.technet.microsoft.com/Forums/de-DE/8e0505dd-adf5-4b82-9033-65b1a9f0b6c8/windows-10-nach-anmeldung-ohne-netzwerk?forum=win10itprogeneralDE

gpedit.msc -> Computerkonfiguration -> Administrative Vorlagen -> System -> Anmelden -> "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" -> Aktiviert

Bei uns hat’s geholfen.

Viele Grüße
McTeefax

82

Hi.

Danke für den Tipp, aber in diesem Fall geht’s um Linux-Clients, die die Shares nicht zuverlässig angezeigt hatten … ich hoffe aber, dass das mit deinem anderen Tipp bzgl Windows ↔ UTC nun gegessen ist.

Viele Grüße,
Michael

83

Hier ein Querverweis zu einem Problem mit dem Leoclient2:

84

Hallo Dorian.
ok – jetzt habe ich das Problem wieder. Dieses Mal habe ich zwei VMs gestartet. Auf beiden habe ich mich mit meinem Login angemeldet. Auf dem einen Client habe ich alle Shares aber auf dem anderen keins.

Ein Blick in dmesg liefert zunächst mal dies:

[   25.102091] CIFS: Attempting to mount //server.linuxmuster.meine-domain.de/sysvol
[   25.137466] CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE
[   25.137482] CIFS: VFS: \\server.linuxmuster.meine-domain.de Send error in SessSetup = -13
[   25.137526] CIFS: VFS: cifs_mount failed w/return code = -13


und etwas später dann:
[  529.832515] CIFS: Attempting to mount //server.linuxmuster.meine-domain.de/sysvol
[  529.910908] FS-Cache: Duplicate cookie detected
[  529.910923] FS-Cache: O-cookie c=000000009c541536 [p=00000000592569dd fl=222 nc=0 na=1]
[  529.910926] FS-Cache: O-cookie d=00000000fb612616 n=000000000a31b24e
[  529.910934] FS-Cache: O-key=[6] '737973766f6c'
[  529.910940] FS-Cache: N-cookie c=0000000080fbbbc8 [p=00000000592569dd fl=2 nc=0 na=1]
[  529.910942] FS-Cache: N-cookie d=00000000fb612616 n=00000000f13ff668
[  529.910944] FS-Cache: N-key=[6] '737973766f6c'

Die zweite Meldung erschien dabei auf dem Client, wo die Shares richtig eingebunden wurden – dagegen erschien die erste Meldung auf beiden Clients.
Auch ein Ab- und erneutes Anmelden löst das Problem nicht: Auf dem zweiten Client sind keine Shares eingebunden!

Hilft das weiter oder soll ich tiefer graben?

P.S.: Könnte mir einer von Euch bitte die Ausgaben von cat /etc/security/pam_mount.conf.xml schicken?

Michael

85

Hallo Michael,

Die zweite Meldung zeigt keinen Fehler.
Auch die Erste ist je nach Kontext ganz normal.

Wie sieht es mit der Uhrzeit aus? Hat die auf dem problematischen Client gepasst? Hat es auf dem problematischen Client mit einem anderen Nutzer funktioniert?

Hier ist das Template dafür. Die Date wird beim Setup und bei jedem Update vom Client automatisch geschrieben.
https://github.com/linuxmuster/linuxmuster-linuxclient7/blob/master/usr/share/linuxmuster-linuxclient7/templates/pam_mount.conf.xml

VG, Dorian

86

Hi. Die Uhrzeiten waren identisch – hatte ich geprüft.
Gerade habe ich den nicht-funktionierenden Client nochmal mit „Sync + Start“ hochgefahren. Angemeldet → Shares sind da.

Danach den anderen (vorher schon funktionierenden) Cient wieder gestart ebenfalls angemeldet → Shares sind da.
Fehlalarm?!? :thinking:
Michael