Hallo,
wir haben ein Debian als funktionierenden Client. Nun habe ich das Image auf Notebooks gespielt und da will es nicht wirklich.
Zuerst mal habe ich das hostname-Problem dadurch gelöst, dass ich /etc/hostname gelöscht habe. Dann wird der hostname mittels den Informationen vom DHCP durch den NetworkManager gesetzt. D.h. mal mit -w und mal ohne. (Wir haben beide MAC in der devices.csv)
Also das passiert:
Mit LAN-Kabel geht die Anmeldung.
Neustart und Kabel ziehen, also Start mit WLAN.
Anmeldung geht nicht (kinit schlägt wohl fehl).
Dann linuxmuster-linuxclient7 setup ausgeführt.
Starten mit WLAN geht die Anmeldung.
Nun wieder Start mit Lan-Kabel → Anmeldung geht nicht
Hier in den Foren habe ich gelesen, dass der Parallelbetrieb mit LAN und WLAN kein Problem wäre. Hat jemand einen Tipp, was ich wohl falsch/anders mache? Oder wo weitersuchen kann?
Wenn ich mit dem WLAN verbunden bin und das setup neu ausführe, wird die Anbindung an die Domäne hergestellt. Und ab jetzt funktioniert es auch über Neustarts hinweg. Allerdings geht es dann nicht mehr mit dem LAN-Kabel (natürlich mit ausschalten, Kabel anstecken und wieder starten).
ich habe wohl der Verwendung des hostnames durch linuxmuster-linuxclient7 noch nicht verstanden.
An unserem Debian-Image habe ich, wie oben besschrieben, die /etc/hostname gelöscht. Funktioniert wunderbar. Der über mit DCHP mitgeteilte hostname wird im System verwendet. Und mit der Domäne klappt auch alles (Die krb5.keytab wird entsprechend mit dem hostname gepacht und die Tickets werden geholt)
Nach meinen letzten Tests klappen die Client-Funktionen bei den Notebooks mit LAN und WLAN nur, wenn ich einen Eintrag in /etc/hostname vornehme. Dann wird über beide Verbindungen der gleiche hostname verwendet. Das ist natürlich nicht schön, wenn unter WLAN der LAN-Name angezeigt wird. Aber bisher klappt es nur so.
Ist das normal?
Falls nicht, frage ich mich, ob ich vielleicht doch das DNS über WLAN fehlerhaft ist? Aber eigentlich funktioniert alles mit den Namensauflösungen.
Warum wird dann die krb5.keytab bei jedem Start mit neuem Hostnamen gepatched. Also es wird ein eventuell neuer Hostname eingetragen. Wenn der Hostname sich nicht ändern darf, sehe ich noch nicht den Sinn, dass das bei jedem Start ausgeführt wird.
Warum funktioniert es dann mit den PCs?
Ich synce einen PC. Beim nächsten Start verbindet er sich mit der Domäne und Benutzer melden sich an. Es wird also von „einem“ Hostnamen (der im Image ist) zum aktuellen Hostnamen gewechselt.
Wenn ich vom LAN zum WLAN wechsle, müsste das doch auch gehen.
Wenn ich meine Geräte nur im WLAN betreiben würde, könnten dann eigentlich alle WLAN-Geräte die gleiche /etc/hostname Datei haben. Also den gleichen Namen im „internen“ Gebrauch. Von außen haben Sie natürlich jeweils unterschiedliche IPs und Namen - für die AD wird ja nur der „interne“ hostname genommen.
Wenn für den Wechsel von LAN zu WLAN gleiche Hostnames nötig sind, ist die Aufnahme der WLAN-Geräte mit „-w“ am Ende irgendwie deprecated, oder?
Entschuldige bitte meine vielleicht naive Fragen. Ich habe viel dazu gelesen und ausprobiert, aber manches macht für mich einfach noch nicht soviel Sinn.
Weil der Hostname sich nach dem Sync eventuell ändert.
Weil da der Hostname mit dem in LINBO übereinstimmt.
Nein. LINBO sorgt bei Start dafür, dass die Anmeldung mit dem Hostnamen funktioniert. Das geht aber im WLAN nicht, da LINBO dann keine Netzwerkverbindung hat.
Das hat viele Probleme. Ich würde dir empfehlen, einfach immer den LAN Hostnamen zu verwenden.
Die Aufnahme in der WebUI kannst du trotzdem machen. Solange in der hostname datei trotzdem der LAN Hostname steht.
vielen, vielen Dank für die Erklärungen und natürlich für die ganze Programmierarbeit, die du da reingesteckt hast.
Jetzt ist mir klar was ich vergessen hatte bzw. nicht wusste: Dass Linbo soviel vorbereitet und damit die „Startparameter“ setzt. Der Groschen ist gefallen
LINBO sorgt bei Start dafür, dass die
Anmeldung mit dem Hostnamen funktioniert.
Das geht aber im WLAN nicht, da LINBO dann
keine Netzwerkverbindung hat.
Das kann linbo eigentlich nur beim sycronisieren machen, oder?
Was macht linbo dabei eigentlich konkret? Kann ich das irgendwo nachlesen? (Habe bisher bichts gefunden)
Dieses Script schreibt das Maschinenpasswort aus der .macct datei in den Computeraccount von dem Rechner mit dem Hostnamen, der die Anfrage gestellt hat
Also: Wenn der hostname von dem Rechner, der die Anfrage stellt (der LAN hostname), anders ist als der hostname, der später im System verwendet wird, funktioniert die Anmeldung nicht.
Unsere Dienstnotebooks haben keinen LAN-Anschluss. Da hatte ich ein paar USB-Netzadapter besorgt. Aber nicht für jedes eines. D.h. Mehrere Notebooks werden gleiche static hostnames haben, nämlich den der mit dem Adapter verknüpft ist.
Welche Probleme kann ich da konkret erwarten?
Die NBs werden später nur im WLAN betrieben, der externe Hostname ist damit natürlich verschieden.
Hmm … direkte Auswirkungen hat es wahrscheinlich nich, aber die Rechner haben dann eben den selben Hostname. Es muss auf jeden Fall der Hostname sein, der in Linbo hinterlegt ist, sonst kann es nicht funktionieren.
Am Ende von linuxmuster-linuxclient7 setup heißt es, dass man sofort ein image machen soll. Also direkt neustarten zu linbo und ein image erzeugen - ohne das etwas verändert wurde.
Jetzt stellt sich mir die Frage, ob ich vor jedem image erzeugen, wieder das setup ausführen muss? Sonst macht die Anweisung „sofort“ ja eigentlich keinen Sinn. (Es wurde ja seit setup mehrfach neugestartet und der PC genutzt und z.B. Dinge nachinstalliert.)
Ich habe auch keine Probleme festgestellt, wenn ich nicht „sofort“ ein image mache. Oder habe ich etwas übersehen?
Falls es eine Rolle spielt, wir haben einen transparent proxy.
Sofort ein Image zu erstellen ist nicht immer notwendig, aber manchmal schon.
Wenn der Domain join im selben image neu ausgeführt wird (= es gibt schon eine macct datei für das Image), dann ändert sich das lokale Passwort des Domänenusers, aber beim nächsen Neustart setzt Linbo das Passwort auf dem Server wieder zurück. Dadruch geht der Login dann kaputt.
Deshalb sollte man das image immer sofort erstellen, ohne nochmal neu zu starten, wenn man nicht genau weiß, was man tut.
Und nein, man muss nicht jedes mal ein Setup ausführen…
Hallo Dorian,
nur damit ich es richtig verstehe, meinst du eher dies:
aber beim nächsen Neustart setzt Linbo das lokale Passwort mit der Version vom Server wieder zurück. Dadruch geht der Login dann kaputt.
…und wenn ich gerade dabei bin:
linuxmuster-linuxclient7 ändert keine Dateien auf dem Server, oder? Erst durch das Image erzeugen kommen die Daten auf den Server?
Die macct-Datei wird von linbo beim ersten Image erzeugen angelegt. Gibt es irgendeinen Befehl/Prozess, der die macct-Datei später nochmal ändert (gewollt oder nicht gewollt )?
Nach dem Durchführen des linuxmuster-linuxclient7 setup auf einem bestehenden/integrierten PC und folgendem image erzeugen wird bei allen anderen Clients der Login nicht mehr funktionieren (wegen neuem Passwort des Domänenusers) und man muss/sollte sofort alle clients syncen, oder?
Falls ich es dann hoffentlich jetzt verstanden habe, werde ich dies linbo-linuxmuster-kerberos Zusammenspiel
mal mit meinen Worten als Aufzählung zusammenschreiben und hier posten …
Ich habe nochmal nachgeschaut: die macct-Datei wird anscheinend doch bei linuxmuster-linuxclient7 setup neu gemacht. Da steht ja auch dann das neue Maschinenpasswort (unicodePwd) drin, nich?
Ich hatte allerdings den sourcecode von linuxmuster-liunxclient7 nach „macct“ durchsucht und nichts gefunden. Welche Aktion genau legt die macct neu an?
Doch! Beim setup wird das Passwort des Computeraccounts im AD gesetzt. Dieses Passwort wird dann auf dem Client in die /etc/krb5.keytab Datei geschrieben, damit er sich später damit im AD anmelden kann.
Dabei wird nur das Passwort aus dem AD in die .macct-Datei geschrieben.
Genau deshalb ist es auch so wichtig, nicht neu zu starten bevor das Image erstellt wird, weil beim Neustart das Passwort im AD ja eventuell überschrieben wird.
Bei jedem Image
Nein.
Genau. Denn dann wird beim Neustart das neue Passwort aus der .macct Datei in den Computeraccount des Rechners im AD geschrieben. Das stimmt dann nicht mehr mit der /etc/krb5.keytab auf dem Client überein und der Login schlägt fehl.
Nein, siehe oben.
Das Erstellen eines Images. Siehe oben.
Wichtig ist, zwischen der .macct-Datei und dem AD zu unterscheiden!! Das sind zwei völlig andere Dinge.
Ist das jetzt halbwegs klar? Es ist leider ein komplizierter und etwas „hacky“ Prozess und nicht so leicht zu erklären, tut mir leid…
Aber …