ich wollte das Problem bestimmt nicht herunterspielen: wir sind uns
einig, dass das ein Mist ist.
Dass man den Zusammenhang nicht sieht hab ich ja auch als ein großes
Problem benannt.
… deswegen ist es ja so wichtig, dass wir das Forum haben und ein paar
Leute die als „Gedächtnis“ fungieren … „da war doch mal was …“.
Also: ich nehme an, dass es daran liegt, dass der Rechnernamen des
Vorlagenclients in der /etc/krb5.keytab drin steht.
Nun müßte man zwei Dinge machen:
funktioniert die Anmeldung, wenn da der eigene Rechnernamen drin steht?
wenn dem so ist, dann muss in den postsync ein „suchen und ersetzen“
für den Rechnernamen in der krb5.keytab rein
Und das wird tricky, weil wir keinen Marker haben … Man müßte also
eine ganze Zeile erkennen und diese ersetzen … da muss halt jemand mal
hinschauen.
Und zu Stefans Anmerkung, dass man als Wechsler von der lmn6.2 sowas
nicht kommen sieht: in der lmn6.2 gab es keien Domänenaufnahme für
linuxclients: das war einfach sau einfach und mega robust.
Wir haben viel versucht um diese Situation bei zu behalten: ging aber nciht.
Bei samba 4 geht das so nicht mehr … glaub mir: ich hab da lange
rumgenörgelt, aber irgendwann eingesehen: es geht nicht mehr.
Und jetzt müssen wir die Kröte der gestiegenen Komplexität schlucken:
und sie zwickt uns in den Hintern… bei Dualboot und jetzt auch hier,
bei der krb5.keytab …
Hej,
zu dem Komplexitätszuwachs von 6.2 auf 7 und der Notwendigkeit sag ich jetzt mal nichts.
Ich würde aber gerne das Problem in Gänze verstehen.
Ok. das verstehe ich.
Das verstehe ich noch nicht. Wenn man den Rechner, mit der man der Domäne beigetreten ist, synct, steht doch weiterhin der richtige Name in der keytab-Datei?
Unter welchen Umständen tritt das Problem auf? Bitte um genauere Erklärung.
Das ist schon eine Falle, in die ich nicht treten möchte.
Grüße
Michael
Mein Fehler heute vormittag: Ich habe den Rechner, auf dem ich
ursprünglich das linuxmuster-cloop-turnkey gemacht habe, gesynct
(hatte inzwischen ein paar lokale Versuche gemacht und wollte ihn
wieder sauber haben). Auch das führt offenbar dazu, dass alle
Rechner mit diesem Image rausfliegen und ein neues Image brauchen.
Das verstehe ich noch nicht. Wenn man den Rechner, mit der man der
Domäne beigetreten ist, synct, steht doch weiterhin der richtige Name in
der keytab-Datei?
ja: beim syncen des Vorlagenclients passiert sowas nicht: das habe ich
schon sehr oft gemacht.
Ich kann also den ersten „Domänenverlußt“ von Stefan nciht erklären: nur
den zweiten.
Umbenennung Musterclient → Verlust Vertrauensstellung AD
OK, verstanden, das habe ich mittags gemacht und das war ein Fehler.
Syncen Musterclient → Verlust Vertrauensstellung AD
Das versteh ich nicht. Ich hab gerade nochmal nachgeschaut, die devices.csv wurde am Mittwoch abend geändert (neuen Drucker hinzugefügt, nichts am Musterclient) und am Donnerstag mittag (s.o.), dazwischen nicht. Am Donnerstag morgen bis ca. 8:30 Uhr haben die Rechner aber noch funktioniert…
Wie gesagt, am Donnerstag morgen habe ich noch etwas an der CUPS-Konfiguration rumgemacht, dabei auch CUPS neu gestartet, und parallel den Musterclient gesynct. Beides ca. um 8:30 Uhr.
Aber nochmal zum Verständnis des Ablaufs der Domänenaufnahme:
Wenn man linuxmuster-cloop-turnkey macht, wird der Musterclient sofort in die Domäne aufgenommen oder erst beim Neustart?
Wenn nicht sofort, erhält er dann einen Schlüssel „123XY“, mit dem er sich beim nächsten Neustart bei der Domäne melden kann? Wird dieser Schlüssel in der keytab zusammen mit dem Musterclientnamen gespeichert?
Können sich dann andere Clients mit dem Image des Musterclients ebenfalls mit dem Schlüssel „123XY“ und dem Namen des Musterclients bei der Domäne anmelden?
Das würde erklären, warum alle aus dem AD rausfallen, wenn der Musterclient rausfällt.
Könnten sich diese Clients auch mit dem Schlüssel „123XY“ und einem anderen Namen (logischerweise ihrem richtigen) anmelden?
In diesem Fall könnten wir ja die keytab postsyncen, indem wir nach dem Namen des Musterclients suchen (der müsste ja z.B. in der /etc/hosts drinstehen, bevor diese gepatcht wird) und in der keytab durch den Namen des zu patchenden Clients ersetzen, oder?
Aber ich fürchte, der Mechanismus funktioniert nicht so einfach, wie ich mir das gerade ausgemalt habe…
mein (Haupt)Musterclient ist an und für sich ein virtueller, mit dem ich auch den Domänenbeitritt gemacht habe.
Ich habe nicht vor den umzubenennen, aber auf ihm entstehen auch häufig die neuen Images. Ist das auch gefährlich? Sollte ich mir dafür einen zweiten Musterclient zulegen?
Die festverkabelten Cients mit einem neuen Image zu versorgen ist ja mit überschaubarer Arbeit verbunden. Aufwendig wird’s mit den immer mehr werdenden mobilen Geräten: Meistens mache ich das im Technikraum, weil es da genügend Steckdosen über den Tischen gibt. Aber alle an einen Switch anschließen und sicherheitshalber auch ans Netzteil, das dauert und ist ärgerlich, wenn es nur dem kaputten Domänenbeitritt geschuldet ist.
Ich denke die krb5.keytab kann man nicht einfach editieren.
Wir haben in einem anderen Thema auch das Problem mit Windows- und Linuxclients auf einem PC und dem Verlust der Vertrauensstellung. In diesem Thread das Problem, wenn der PC, welcher in der krb5.keytab steht, umbenannt wird, oder wegkommt. Hier ist das auch verständlich, weil der sssd des Linuxclients mit dem Namen des nicht mehr vorhanden PCs beim AD anfrägt. Ich denke man müsste nur den PC Namen in der devices.csv stehen lassen, evtl. mit einer Dummy-MAC Adresse und das Problem wäre erledigt.
Nicht erledigt ist dann das Dual-Boot Problem, wo das Image für Linux und Windows auf ein und demselben PC erstellt wird. Es gibt ja den Workaround diese Images auf separaten PCs zu machen.
Generell stelle ich mir aber die Frage, wieso man für den Linux Client überhaupt einen Domänen Beitritt und Kerberos benötigt. Den SSSD kann man auch für LDAP statt AD konfigurieren. Mit pam_mount werden dann auch die Samba Shares eingebunden.
Leider komme ich mit meinen Tests im Moment nicht zu Ende, weil sich sssd auf Mint 20 mit einem Coredump verabschiedet, wenn ich diesem mit LDAP konfiguriere. Sonst könnte ich ein Beispiel liefern.
Wenn es mit SSSD nicht klappt, so sollte es in jedem Fall mit winbind klappen. Die Konfiguration dazu liegt ja auch schon auf dem Server.
PCs beim AD anfrägt. Ich denke man müsste nur den PC Namen in der
devices.csv stehen lassen, evtl. mit einer Dummy-MAC Adresse und das
Problem wäre erledigt.
das ist doch mal eine Feine Idee
… blöd ist halt, dass so ziemlich jeder einmal in diese Falle tappen
wird … wir können das nur schlecht Dokumentieren (so dass es
verstanden und befolgt wird) und im Vorhinein so ausliefern … geht auch
schwer…
Generell stelle ich mir aber die Frage, wieso man für den Linux Client
überhaupt einen Domänen Beitritt und Kerberos benötigt.
das wollten wir nicht: wir haben aber keinen anderen Weg gefunden.
Den SSSD kann
man auch für LDAP statt AD konfigurieren. Mit pam_mount werden dann auch
die Samba Shares eingebunden.
Leider komme ich mit meinen Tests im Moment nicht zu Ende, weil sich
sssd auf Mint 20 mit einem Coredump verabschiedet, wenn ich diesem mit
LDAP konfiguriere. Sonst könnte ich ein Beispiel liefern.
Wenn es mit SSSD nicht klappt, so sollte es in jedem Fall mit winbind
klappen. Die Konfiguration dazu liegt ja auch schon auf dem Server.
Das nur als Anregung für andere Tester
wenn du einen Weg findest, dann wäre ich dir sehr, sehr, sehr Dankbar!
Ich würde das auch durchtesten
Ich habe nicht vor den umzubenennen, aber auf ihm entstehen auch häufig
die neuen Images. Ist das auch gefährlich? Sollte ich mir dafür einen
zweiten Musterclient zulegen?
Hallo Holger,
nur das ich das richtig verstehe: braucht man den Client, mit dem man den Domänenbeitritt gemacht hat später noch für irgendwas ? Sonst schiene ja folgendes sinnvoll
ein absolut wichtiges und heißes Thema hier. Jetzt kommt eine Steigerung:
Bei uns sind die PCs über mehrere Gebäude verteilt und die Images werden von mehreren Personen gewartet. Dabei bekommen die allererste Grundversion von mir.
Wenn nun ein anderer an einem anderen PC das Image aktualisiert, neu erstellt und hochlädt …?
Welcher PC darf dann nicht mehr angefasst werden?
Bisher sind wir so vorgegangen, dass ein geklonter PC vor dem aktualisieren neu gesynct wird. Nach der Aktualisierung wird das Image neu erstellt, hochgeladen und an die restlichen PCs im Raum verteilt.
Immer wieder kommt es aber vor, dass danach die Vertrauensstellung fehlt. - Zumal manche Images in mehreren Räumen (aber gleiche Linbo-Gruppe) verwendet werden
Könnte hier eine Fehlerquelle sein?
er kann als ganz normaler Client verwendet werden:
… nur nochmal, um ganz sicher zu gehen: man darf ihn auch synchronisiert
neu starten?
(für den Fall interessant, dass man am Master etwas installiert &
ausprobiert hat und ihn dadurch zerschossen hat und dann neu aufsetzen
muss…)
ich kann nur sagen, dass ich das Produktiv seit einem Jahr.
Mein Vorlagenclient ist ein virtueller.
Den habe ich inzwischen wahrscheinlich schon 10 mal neu bespielt …
Images habe ich aber auch von anderen Clients aus erstellt: nur die
Domänenaufnahme war damals von dem virtuellen Client aus.
heißt das, dass ich vor Erstellen eines überarbeiteten cloops gar kein erneutes turnkey machen muss? Das mache ich nämlich immer. Könnte das der Grund für einige Probleme sein? (mein „Donnerstagvormittagproblem“ sehe ich aber noch nicht als gelöst…)
