Linuxmuster-linuxclient7 mit LAN und WLAN

Clientpflege Linuxclient
1

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?

Viele Grüße, Helge

2

Hi Helge,

funktioniert der dns im wlan?

VG,
Dorian

3

Ja, DNS im WLAN funktioniert. in der entsprechenden Datei unter NetworkManager/systemconnections steht:

[ipv4]
dns=10.0.0.1;
dns-search=merian.lan;
method=auto

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).

4

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.

Hat jemand Vorschläge was ich testen kann…

Viele Grüße, Helge

5

Ja. So funktioniert ActiveDirevtory nunmal … der Computeraccount ist an den Hostnamen gebunden, deshalb muss der immer gleich sein.

6

Ja, das ist mir irgendwie klar :wink: Aber …

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Viele Grüße, Helge

7

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.

VG,
Dorian

1 „Gefällt mir“
8

Hallo Dorian,

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 :slight_smile:

Viele Grüße, Helge

9

Hallo Dorian,

verstehen ist nicht gleich verstehen :wink:

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)

Viele Grüße, Helge

10

Nein, linbo macht das immer, auch beim Grünstart.

Nur im Code:

Im Prinzip funktioniert es so:

  • Linbo lädt die image.macct datei runter
  • Dadurch wird das pre-download script ausgeführt
  • 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.

VG,
Dorian

1 „Gefällt mir“
11

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.

Viele Grüße, Helge

12

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.

VG,
Dorian

13

Wenn ich weiter fragen darf:

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.

Danke schonmal und viele Grüße, Helge

14

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…

VG,
Dorian

15

Hallo Dorian,
vielen Dank für die Ausführungen hier. Ich lerne gerade viel Wichtiges dazu freu
Auch Danke für Euer Engagement.
Viele Grüße
Max

16

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:

  1. linuxmuster-linuxclient7 ändert keine Dateien auf dem Server, oder? Erst durch das Image erzeugen kommen die Daten auf den Server?
  2. 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 :wink: )?
  3. 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 …

Viele Grüße, Helge

17

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?

18

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…

2 „Gefällt mir“
19

@dorian vielen Dank für deine geduldigen Erklärungen! Ich habe dabei viel gelernt.

Wir haben über die Zeit jetzt ein für uns funktionierendes Vorgehen gefunden. Ich habe mal versucht alles zusammen zu schreiben und so vielleicht das gesammelte Wissen kompakt weiterzugeben. Ich füge den Text der Einfachheit halber in der nächsten Antwort ein.

20

lmn7 linbo-grub-kerberos

Angelegt Donnerstag 29 Dezember 2022

Ich will keine neue Installationsanleitung für einen Linuxclient schreiben, da es ja schon eine Ausgezeichnete gibt.
Es geht vielmehr um die Darstellung der Verbindungen zwischen den einzelnen Komponenten und der sich daraus ergebenden Möglichkeiten und Fallstricke. Dabei sind die Anwendungsfälle der Merian-Schule die Richtschnur:

  • PCs mit Debian und Win10, starten mit Linbo in Dualboot
  • Notebooks mit Debian, starten mit grub ohne linbo
  • angepasster Lernstick mit Benutzeranmeldung

PC mit kerberos verbinden

linuxadmin@r001-pc01:~$ sudo linuxmuster-linuxclient7 setup

stellt die Verbindung zum Dömanencontroller her und legt einen Maschinenaccount an. Dabei wird ein Passwort für den PC r001-pc01 erzeugt und im ActiveDirectory des Domänencontrollers abgelegt. Zu dem Passwort bzw. dem Key wurde auf dem Domänenkontroller eine Versionsnummer (KVNO) erstellt. Der Dömanencontroller hat also von dem PC diese Informationen:

  • PC-Name
  • Domänennamen
  • Passwort bzw. Key
  • KVNO

Diese vier Eckdaten müssen stimmen, damit diesem PC vom Domänenkontroller vertraut wird. Es können sich dann alle in Linuxmuster hinterlegten Benutzer anmelden.
Diese Informationen werden vom Setup in der Datei /etc/krb5.keytab auf dem PC gespeichert.

PC neustarten

Jetzt hängt das weitere Verhalten des Systems von den verschiedenen Startvarianten ab.

Grub

alles funktioniert auf diesem PC, da sich auf diesem PC nichts ändert. Die vier Eckdaten stimmen.

Linbo

Beim Erzeugen eines Image von einem in die Domäne aufgenommen PCs wird im Image-Verzeichnis auf dem Server eine macct-Datei angelegt. In dieser Datei liegt das Maschinenpasswort desjenigen PCs. Beim Hochladen des Images wird diese Datei auf dem Server abgelegt.
Wenn Linbo auf einem PC startet wird es versuchen, diese macct-Datei vom Server herunterzuladen und das enthaltene Password ins ActiveDirectory (AD) auf dem Server zu schreiben und zwar in den Maschinenaccount des aktuellen PCs. Nun müssen wir unterscheiden:

Die macct- Datei existiert noch nicht

Dies ist der Fall, wenn noch nie ein Image von einem in die Domäne aufgenommen PCs gemacht worden ist. Linbo kann die Datei also nicht herunterladen und Linbo ändert dann auch nichts an der Konfiguration des ADs auf dem Server. Beim obigen PC r001-pc01 wird also alles funktionieren, Benutzer können sich anmelden, etc. .

Die macct-Datei existiert

Linbo lädt die Datei und überschreibt im Domänencontroller/AD das oben für r001-pc01 erzeugte Passwort. Das Passwort in /etc/krb5.keytab auf dem PC stimmt nun nicht mehr mit dem Passwort im Domänencontroller überein, es gibt kein Vertrauensverhältnis mehr zwischen Domänencontroller und r001-pc01 und die Anmeldungen der Benutzer schlagen fehl.

PCs vervielfachen

Prinzipiell könnte man jeden PC einzeln in die Domäne aufnehmen und startet die PCs immer mit grub, nie mit Linbo. Dann hätte jeder PC ein eigenes Maschinenpasswort. Dafür ist Kerberos eigentlich gedacht, aber es ist für unsere Zwecke unpraktisch.

Klonen

Ein anderer Weg ist die Festplatte von r011-pc01 zu klonen und auf die anderen PCs aufzuspielen ohne dabei etwas zu ändern. Auch hier muss grub und nicht Linbo verwendet werden. Im Netz starten dann lauter identische PCs, die intern alle den Hostname r001-pc01 haben. Nur vom Netz aus gesehen haben die PCs die über die MAC-Adresse zugeteilten Namen. Damit hat man dann lauter identische, funktionsfähige PCs. Dies verwenden wir für die Lernsticks.

Imagen mit Linbo

Von r001-pc01 wird ein Image erzeugt und das Maschinenpasswort in der macct-Datei gespeichert. Mit diesem Image wird der PC r001-pc02 gesynct und Linbo gestartet. Nun klickt man in Linbo auf den Button für den Start des Betriebssystems. Bevor Linbo sich beendet und in das Betriebssystem bootet, legt Linbo das Maschinenpasspwort für diesen PC r001-pc02 in der Domäne an. Beim Startvorgang von Linux patched linuxmuster-linxclient7 die Datei /etc/krb5.keytab mit dem Namen r001-pc02 . Die Datei /etc/hostname muss auch den Namen r001-pc02 enthalten - dies kann z.B. über den Postsync erfolgen. Nun stimmen die vier Eckdaten, der PC r001-pc02 ist funktionsfähig und kann über Linbo oder grub gestartet werden.

Notebooks oder PCs, die auch mit WLAN verwendet werden, sollten in der /etc/hostname immer den LAN-Namen haben.

Fallstricke

Bei einem neuen Image

Man hatte schon ein Image mit Domänenanmeldung erzeugt und ausgerollt. Wenn man nun auf r001-pc01 linuxmuster-linuxclient7 setup ausführt und wieder ein Image erzeugt, hängt das weitere Verhalten von den Startvarianten ab:

Grub

Die noch ungesyncten PCs werden weiterfunktionieren, da Grub nichts am PC ändert und im ActivDirectory für die einzelnen PCs noch das alte PC-Passwort steht.

Linbo

Man wird sich an keinem PC im Netzwerk anmelden können, da Linbo beim Betriebsystemstart jeweils das neue Passwort im ActivDirectory hinterlegt und im ungesyncten Linux noch das alte steht. D.h. nach dem Erzeugen eines Image müssen alle PCs gleich synchronisiert werden.

Beim Image ausrollen

Auch beim Image ausrollen muss man die Startvarianten berücksichtigen. Machen wir einen PC neu mit dem Befehl linbo-remote -i r001-pc02 -c partition,format,sync:1,halt . Der PC wird also gleich nach dem Sync runtergefahren.

Grub

Die Anmeldung wird nicht gehen. Dafür müsste erst das Maschinenpasswort von r001-pc02 ins ActiveDirectory geschrieben werden. Das macht aber Linbo und Linbo wurde nach dem Sync nicht gestartet.

Linbo

Alles funktioniert, da beim Start von Linbo alles so angepasst wird, dass die vier Eckdaten stimmen.

Wenn man also grub verwenden möchte, muss man den obigen Befehl mit start:1 statt mit halt abschliessen. Dann wird das Betriebssystem das erste Mal von Linbo gestartet. Danach kann weiter grub verwendet werden.

Bei späterem, wiederholtem Ausrollen eines Image reicht dann für beide Startmethoden auch linbo-remote -i r001-pc02 -c sync:1,halt . Wird aber nochmal partition,format verwendet, sollte wieder start:1 genommen werden, da die Informationen von der cache-Partition gelöscht wurden.

Dualboot

Für die Images von Linux und Windows werden zwei verschiedene Maschinenpasswörter angelegt. Wenn über Linbo eines der beiden Betriebssysteme gestartet wird, wird das entsprechende Passwort ins ActiveDirectory geschrieben. Daher: Dualboot schließt die Verwendung von Grub aus!

Notebooks mit Grub

Wir starten unsere Nootbooks über das Grubmenu direkt zu Linux ohne über Linbo zu gehen. Das Einzurichten ist mit dem neuen linuxmuster-linuxclient7 schwierig geworden.
Damit das Grubmenu verwendet wird, muss dies auf dem Server in der entsprechenden Datei unter linbo/boot/grub/....cfg eingetragen sein. Wird der PC mit angeschlossenen Netzwerkkabel gestartet, wird automatisch diese Grub-Konfiguration geladen und verwendet. Also für Stand-PCs funktioniert das direkt.
Wird der PC bzw. das Notebook ohne Netzwerkkabel gestartet, wird aus der cache-Partition die Datei boot/custom.cfg verwendet. Diese Datei wird nur dann in der cache-Partition angelegt bzw. aktualisiert, wenn auf dem PC Linbo bei angeschlossenen Netzwerkkabel gestartet wird - was hier aber gerade nicht passiert.
Wir haben das so gelöst, dass vor dem neu syncen der Notebooks set default=0 in linbo/boot/grub/....cfg geschrieben wird, also Linbo gestartet wird. Wenn dann die Notebooks bespielt wurden und linux über Linbo gestartet wurde (s.o.), wird über ssh in der boot/custom.cfg auf der cache-Partition und auf dem Server wieder set default=1 gesetzt. Ab nun startet das Notebook nur noch mit grub.

4 „Gefällt mir“