über das letzte Jahr hat Michael andauernd sehr seltsame Probleme: oftmals nur er und sonst niemand.
Schon oft haben wir vermutet, dass das mit dem LE Zertifikat für die AD zusammen hängt.
Für mich war schon vor Monaten der Punkt erreicht wo ich dachte: blos nicht den AD mit einem „echten“ Zertifikat betreiben.
Vor allem auch das wählen einer echten Domain für den AD scheint keine gute Idee zu sein: selbst MS empfiehlt genau das nicht zu tun, sondern dem AD eine subdomain der eigenen zu verpassen.
Das bringt mich nun aber in eine Zwickmühle, da auch ich einen Dienst habe, der einen AD mit echtem Zertifikat benötigt. Bei mir ist das bisher nur die PeerTube. Webuntis habe ich glücklicherweise nicht.
Aber ich muss raus aus dem Dilemma, und da tut sich in meinen Augen bisher nur ein Weg auf: der in den letzten Wochen hier beschriebene Weg des LDAP Proxys: einer Maschine, die die externen LDAP Anfragen annimmt und beim AD fragt, ob das OK ist. So bekommen die externen Dienste zertifizierte Aussagen, ohne dass ich am AD rumschrabbeln muss.
Das wird also mein Weg sein.
dann schreibt das bitte somit, damit wir das in der Doku genauso beschreiben können.
Unformatierter Text reicht eventuell mit Screenshots. Danke allen die das um/einsetzen.
beschreibt es ja schon. Aber einwenig detaillierter dürfte es schon sein. Ich habe den Post in ein Wiki verwandelt. Also kann jeder seine Erfahrungen direkt in den Post einfließen lassen.
Nein, mein ldap-ldaps Post war allgemeiner Natur, gerne als Ergänzung zu diesem hier, aber unabhängig von einem bestimmten Server. Aber passt schon. Wer es sucht, wird es finden. Für mich ist dieses Forum auch die reinste Fundgrube geworden.
Hi Holger
Ja, das sehe ich mittlerweile genauso – leider war mir das aber zum Zeitpunkt der Installation 2019 nicht bekannt oder genauer gesagt war es damals sogar so, dass es genau umgekehrt empfohlen wurde. Sonst wäre ich natürlich gar nicht auf die Idee gekommen, intern den gleichen FQDN zu nehmen wie extern. Jetzt ist es leider zu spät, um nochmal von vorne zu beginnen.
Allerdings ist das Zertifikat auf dem Server seit gestern neu – es wurde mir heute aber berichtet, dass im Computerraum (der zwischendurch immer komplett ausgeschaltet war!) die Anmeldung NUR dann funktionierte, nachdem man JEDES Mal Sync+Start gewählt hat. Ohne ging es weiterhin nicht. Daher schließe ich das neue Zertifikat nun eigentlich doch wieder aus … da muss noch etwas anderes hinterstecken.
Das seltsame ist weiterhin, dass es unter Windows jedes Mal klappt und nur der Fossa-Client das Problem hat. Dual-Boot kann es weiterhin sein; da kann ich nicht sicher sagen, ob es zwischendurch einen Wechsel Linux ↔ Win10 ↔ Linux gab. Doch da wir Linux im Autostart mit 3 Sekunden haben, ist die Warscheinlichkeit, dass die Kollegen Win10 booten eher gering.
Daher müssen wir vermutlich entweder auf „Sync + Start per default“ wechseln oder aber die wirkliche Ursache bald finden …
Das Problem ist, dass du keinen Weg nennen kannst, wie man das reproduzieren kann.
So ist es sehr schwer, das Problem einzugrenzen …
Was ich mir noch vorstellen könnte ist ein Problem mit dem patchen der Keytab Datei. Um das zu prüfen kannst du mal auf einem „kaputten“ client als Linuxadmin klist -k ausführen und die Ausgabe posten.
Hi. Ich würde ja liebend gerne etwas posten, was das Problem eingrenzt … ich finde die Situation auch nicht glücklich…
Die Ausgabe klist hatte ich Dir zwar schon mal geschickt … aber ich poste sofort noch eine per PM.
Bei unserer VM, die eigentlich als Vorlage für die Computerräume dient, tritt das Problem erstmals auch auf, so dass die Anmeldung da zur Zeit zwar funktioniert aber keine Shares liefert.
Nachtrag: Gerade nochmal einen re-join gemacht, dann mit prepare ein neues Image vorbereitet und direkt hochgeladen (so wie es vorgesehen ist). Im Moment läuft die Anmeldung wieder … mal sehen wie lange?!?
Hallo!
Wenn ich ein Image habe (Danke Holger, Deines hat mir viele Stunden erspart), das ich verschlimmbessere und ein neues erstelle, danach aber wieder auf das alte zurück möchte:
früher konnte man einfach alle .cloop-Dateien umbenennen, bittorrent neu starten und gut wars.
Ist das immer noch so? Ich habe aktuell Probleme mit den Mounts, die schlagen alle fehl trotz dass der login klappt, weiß aber nicht, ob es daran liegt.
Danke für Tipps
LG
Max
Hallo Holger,
bevor man das Image erstellt, habe ich das bisher immer mit bleachbit geputzt…im neuen Linuxclient, scheint bleachbit hier etwas zu viel zu löschen - zumindest ging danach die Anmeldung nicht mehr. Gehe ich richtig in der Annahme, dass der Befehl linuxmuster-linuxclient7 prepare-image das im Großen und Ganzen übernimmt?
Gruß
Daniel
ja, das macht ähnliches.
Ich verwende auch schon viele Jahre bleachbit und das mache ich auch aktuell noch.
Bei mir funktioniert es.
Ich lasse es als root und als linuxadmin laufen.
Die Defaulteinstellungen habe ichnicht geändert.
Mit der Hilfe von @dorian und Holger (@baumhof) habe ich es geschafft, den Client soweit zufriedenstellend zum Laufen zu bringen. Danke!
In dem Zsh. möchte ich aber noch auf etwas hinweisen, was mir aufgefallen ist. Wenn ein User mehrfach im Netzwerk angemeldet ist, dann kann es vorkommen, dass die Drucker nicht mehr korrekt angezeigt werden (entweder gar kein Drucker, oder viele Drucker, die nicht zum entsprechenden Raum gehören). Gibt es schon jemanden, der die Unterbindung der Mehrfachanmeldung im neuen Linuxclient unter lml7 erfolgreich einsetzt?
wenn Eure Clientnamen auf Raumnamen und Nummern basieren, machst Du noch ne Schleife drum und lässt das einmal für einen ganzen Raum machen
Vorteil: Du musst nicht am Server was rumfriemeln und vorher synchronsieren und noch daran danken, dass am Server zurückzufriemeln und dann nochmal synchronisieren (wobei das zweite syncen muss sein, weil die Teilnehmer die Kisten ja „verspulen“ durften)
Zweiter Vorteil: wenn lehrer sudoer sind, können das auch die Kollegen mit Ihren Schülern, das passiert bei uns im Netzwerkunterricht ständig.
deshalb ein neuer Post,