wwas mich am ganzen Problem wundert ist, dass ich den
linuxmuster-client-adsso seit Januar im Betrieb habe und nie ein solches
Problem hatte.
Domänenaufnahmen hab ich bestimmt 10 Stück gemacht und die virtuellen
Umgebungen wurden von sehr vielen Leuten verwendet (in Fortbildungen und
im Seminar): nicht einmal kam ein „geht nicht“ dabei raus.
Für mich ist die Frage: ist das einfach empfindlich, oder haut es einen,
je nach Mondphase, aus der Domäne raus.
Zweiteres glaube ich nicht, weil das wäre ja in meinen Umgebungen
bestimmt irgend wann mal passiert: so viel wie die benutzt wurde …
Meine Gedanken sind:
es ist klar, dass es pro Rechnernamen nur eine Domänenaufnahme geben
kann. Das ist derzeit so, weil eine neuaufnahme des selben Rechners in
die Domäne ein anderes workstationpasswort im AD erzeugt, dass dann
nicht mehr zu dem im anderen Image paßt: dabei ist egal obe es sich um
Windows und linux handelt, oder um zwei linuxe auf der selben Maschine.
Das ist, würde ich sagen, Johannes Problem.
Rainer und Dominik haben das Problem, dass ihre Maschinen plötzlich
und unvorhergesehen aus der Domäne fliegen: furchtbarer Zustand: man
weiß nicht, wann es einen trifft.
Aber: beide haben ein ähnliches Vorgehen: sie erstellen ein
bionic-testing auf einem anderen Client und erst, wenn sie damit
zufrieden sind, dann wird das zu bionic.cloop.
Eigentlich sollte das keinen Einfluss haben, aber natürlich brauchen wir
genauere INformationen, wie den aus testing bionic wird.
Wird das image kopiert
cp bionic-testing.cloop bionic.cloop
Welche Dateien werden kopiert?
Oder wird ein bionic Client kurzzeitig in testing aufgenommen, geklont,
dann zurück zu bionic und dann Image erstellen?
Erzählt mal, wie das abläuft.
bleibt Gerd: bei dem die Cleints in der Domäne waren , eine gewisse
Zeit, und dann ums verrecken nicht mehr rein kamen. Aber mitlerweile
gehen auch keine anderen Clients mehr in die Domäne.
Auch du solltest nochmal den Hergang der Dinge schildern, damit wir uns
ein Bild machen können.
mein System.
Ich hab netterweise das Image von Dominik bekommen.
Das war zwar schon in seiner Domäne, aber ich dachte: man kann es ja mal
probieren.
Also hab ich es in meine Schule geladen, hab die postsyncs angepaßt und
bin frech der Domäne beigetreten.
Dann noch ein Blick auf die macct Datei: ja, wurde beim Hochladen neu
erstellt.
Das läuft bei mir seit Dienstag: bisher keine Probleme: und ich habe
bestimmt schon 10 Images erstellt…
Das bringt mich zu folgendem Hinweis: bei mir ging es auch erst, nachdem
ich alle Einträge in der hosts Datei von dominiks postsync angepaßt hatte.
Der postsync bewegt diese Hostdatei auf den Client und fügt 10.16.1.1 an
den richtigen Stellen ein.
Sie sieht so aus:
--- --- --- ---
# Diese Datei wird per postsync gepatcht. Zu bearbeiten ist sie auf dem
Server."
# Pfad: ${linbodir}/${universalpostsyncdir}/${patchclass}/${HOSTS}
# HOSTNAME wird im Postsyncskript mit dem echten Namen gepatcht
127.0.0.1 localhost
127.0.0.1 HOSTNAME.bzpf.lan HOSTNAME
#Die nächste Zeile enthält die Hostnamen so, wie sie auf dem Server
eingetragen sind...
#SERVERIP server.bzpf.lan server
## damit CUPS zufrieden ist, muss noch diese Zeile hier dazu:
##SERVERIP server.lokal server.local
-- -- -- --
Gepatched werden HOSTNAME und #SERVERIP (ja, das # wird auch ersetzt.
Die serverzeile ist also nicht mehr auskommentiert, die cups Zeile schon…)
Gute Nachricht - meine Domänenanmeldung funktioniert wieder.
Ich hatte schon einen ganz langen Text mit den Irrungen und Ideen, die ich verfolgt habe - oder haben die mich verfolgt?
Leider wollte mein Rechner vorher herunterfahren und ich hab ihn nicht davon abgehalten. Also gibt es die Kurzfassung der Lösung:
Wenn ich in /etc/hosts die Zeile „127.0.1.1 RECHNERNAME“ auskommentiere (die 127.0.1.1 ist kein Tippfehler, ist bei Ubuntu 18.04 so), dann kann ich den Rechner erfolgreich in die Domäne bringen und nach Erstellen eines Images funktioniert die Anmeldung.
Nehme ich die Zeile wieder rein, geht die Anmeldung sofort nicht mehr.
Jetzt habe ich Holgers Text gelesen und vielleicht versuche ich es nochmals mit der Zeile „127.0.0.1 RECHNERNAME.DOMÄNE RECHNERNAME“?
zu 1:
-rw------- 1 root root 90 Aug 8 15:21 r224fujitsu.cloop.macct
-rw------- 1 root root 90 Aug 7 17:18 smart_dell.cloop.macct
-rw------- 1 root root 90 Aug 24 17:40 tafel_214_222.cloop.macct
-rw------- 1 root root 90 Aug 10 15:18 tafelpcw7-2019-08-11-1543.cloop.macct
-rw------- 1 root root 90 Aug 11 15:43 tafelpcw7.cloop.macct
-rw------- 1 root root 90 Sep 5 17:04 ubuntu1804basis.cloop.macct
soll das so?
Die Systemzeit stimmt mind. auf die Minute; weit über 500 Windows Clients in dem Standort um den es hier geht. Bisher haben wir an zwei Clients der gleichen HW-Gruppe versucht mit selben ausgang.
Ich guck mir jetzt mal die Hostdatei an, die sieht bei uns auch so aus: 127.0.1.1
Kannst du bitte noch mal kurz beschreiben was du mit dem Satz:
Der postsync bewegt diese Hostdatei auf den Client und fügt 10.16.1.1 an
den richtigen Stellen ein.
meinst? Meinst du damit ein Eintrag für den Schulserver?
Grüße,
gerd
Daran alleine kann es aber nicht liegen, bei unserem Client ist die Zeile drin, und es funktioniert trotzdem (noch, dieser Thread macht mir echt Angst, dass es damit jederzeit vorbei sein könnte).
Der Client, der bei uns funktioniert, ist so entstanden:
ich habe Holger @baumhof 's virtuelle Testumgebung (die echt super ist, nochmal vielen Dank!)
in dieser habe ich dann Holgers Linuxclient geklont und dann in die bestehende Partitionierung hinein ein Kubuntu installiert
das Kubuntu habe ich von sddm auf lightdm umgestellt (mit sddm geht das Linuxmuster-Login nicht)
eine neue Gruppe erstellt (falls das von Bedeutung ist: Ich habe die Gruppe im Webinterface erstellt, ich habe alles selbst abgetippt, nicht die Duplizieren-Funktion verwendet, vielleicht ist da ja auch ein Fehler drin)
den Client auf dem Server eingetragen und importiert
auf dem Client dann linuxmuster-adsso nach Anleitung aufgerufen
Diesen Client habe ich dann so in unser Schulnetz vepflanzt:
auf dem Server eine neue Linbo-Gruppe
den Client in Virtualbox von „Internes Netzwerk“ auf Netzwerkbrücke umgestellt
die MAC des virtuellen Clients auf dem Schulserver eingetragen und importiert
den virtuellen Client per PXE gestartet. Dann wird gleich die IP des richtigen Schulservers erkannt (die eine andere ist als die des Virtuellen in Holgers Testumgebung)
Mit dem grünen Pfeil gestartet
linuxmusterclient-adsso nochmal aufgerufen, der neue Server wird erkannt
nach Neustart die Anmeldung getestet
dann aus der Linbo-Konsole heraus das Image hochgeladen
anderen Rechner per Image installiert, getestet
Was, glaube ich, dringend nötig wäre, sind mehr debug-Messages beim Anmeldevorgang. Vielleicht gibt es die ja auch schon, ich wüsste aber nicht, wo. Wäre das z.B. ein „normales“ Anwenderprogramm, würde man es ja Schritt für Schritt im Debugger laufen lassen, Breakpoints setzen usw usf.
Man könnte es ja auch so machen, dass man eine Variable LINUXMUSTER_DEBUG_LEVEL einführt, und wenn die einen bestimmten WErt hat, werden mehr Infos in die Logdateien geschrieben. So, wie es jetzt ist, habe ich das Gefühl, dass wir uns dem Problem von der anderen Seite her nähern, und es noch völlig unklar ist, ob alle hier überhaupt das gleiche Problem haben und an welcher Stelle es liegt.
Gibt es denn ein Szenario für den sauberen Austritt aus der LMLv7 / Samba4 Domäne, um dann wieder sauber neu testen zu können?
Also welche Schritte / Befehle sind notwendig? Die Samba4 Befehle?
Oder reicht hier ein Löschen der *macct Datei und die linuxmusterclient-adsso nochmal aufzurufen?
Nachdem ich die Einstellungen festig gestellt hatte, wurde sofort ein Image erstellt.
Wenn du vorher eine Anmeldung testest, kommen diese Anmeldedaten ins Image und müssen später wieder gelöscht werden (sssd-cache leeren: „# sss_cache -E“ - dazu Paket sssd-tools notwendig).
Gibt es denn ein Szenario für den sauberen Austritt aus der LMLv7 /
Samba4 Domäne, um dann wieder sauber neu testen zu können?
hab ich mich auch schon gefragt: vor allem, weil ich ja Dominiks Client,
der bei ihm in der Schuldomäne ist, einfach in meine Schuldomäne
genommen habe (obwohl dieser Tread schon angefangen hatte …).
Ich hab nix gemacht, außer: adsso nochmal auf zu rufen … hat geklappt.
Aber wenn du so fragst: ich würde sagen, dass folgendes nachhaltig sein
sollte: nenn den Client um in der devices.csv und tritt dann einfach
noch mal ein.
Ich denke aber, dass bei dir die Probleme daher rühren, dass die Clients
alle gleich heißen, weil du keinen postsync hast, der dir die hosts
Datei richtig macht.
Wenn dein Client
r100pc01 heißt, er im AD aber r20pc13 heißt (in der devices.csv), dann
kannst du der Domäne beitreten so oft du willst: die läßt ihn nicht rein.
Jetzt hatte ich mal Zeit mir das anzuschauen. Ich habe das Basiscloop verwendet. Dabei fiel mir auf, dass das mit torrent- und macct-Dateien ausgeliefert wird. Die würde ich weglassen, da sie sowieso auf dem Zielsystem neu erstellt werden müssen.
Die macct-Datei wird auf dem Server erstellt, wenn ein neues Image hochgeladen wird. Es enthält den Passwordhash des Computeraccounts, von dem das Image erstellt wurde.
Beim Start eines Systems über Linbo triggert der Linboclient einen Prozess auf dem Server, der den Hash aus der macct-Datei des Images in den Account des zu syncenden Computers schreibt, sodass dieser sich mit demselben Passwort (ist ja im Image) beim Domänenserver anmeldet. Das funktioniert seit einiger Zeit sehr stabil mit Windowsclients.
Scheint so, dass wir bei Linuxclients noch mehr Forschungsarbeit brauchen. Da ich zur Zeit Linuxclients an der Schule nicht produktiv nutze, müssen das Andere erledigen.
Was definitiv im Moment ein Problem ist, wenn man auf einem Rechner zwei Linuxsysteme oder ein Linux- und ein Windowssystem mit Domänenanmeldung parallel hat. Der Domänenbeitritt eines Linux-Systems verändert den Computeraccount scheinbar so, dass man sich auf dem anderen System nicht mehr an der Domäne anmelden kann, obwohl der Passworthash auf dem Server geschrieben wird.
Genaueres konnte ich aus Zeitmangel bisher nicht herausfinden.
BTW, dass der Client die macct-Datei wg. der Dateirechte nicht herunterladen kann, ist kein Fehler sondern ein Feature, denn die macct-Datei wird nur auf dem Server benötigt und enthält Accountdaten, die nur root lesen können soll.
Kann es sein, dass dann die Anmeldung unter Linux nach 7 Tagen nicht mehr geht, weil das Ticket 7 Tage läuft und kein neues gezogen werden kann?
Vielleicht ist die Frage unsinnig, dann liegt es daran dass mir der Gesamtzusammenhang mit Gerätepasswort, Domänenbeitritt, kerberos-Ticket und Legitimierung verschiedener Dienste nicht klar ist.
Kann mich jemand erleuchten?
Kann ich mir nicht vorstellen. Das Ticket wird ja nur für den global-admin für den Domänenbeitritt benötigt. Der Benutzer zieht sich bei jeder Anmeldung selbst ein neues Ticket.
Kann ich mir nicht vorstellen. Das Ticket wird ja nur für den
global-admin für den Domänenbeitritt benötigt. Der Benutzer zieht sich
bei jeder Anmeldung selbst ein neues Ticket.
ich glaub das auch nicht: sonst hätten ja meine virtuellen Umgebungen,
die ich seit Januar verwende, alle schon vor Monaten ablaufen müssen:
Fakt ist aber: die sind alle problemlos in ihrer Domäne gelieben: auch
nach Monaten…
Wichtiger Hinweis, und das hatte mich schon ein wenig beunruhigt, ist
dass man „verbrannte“ Clients durch auskomentieren in der devices.csv,
import und wieder rein, import reparieren kann.
Dass man so gleich die Dualbootfähigkeit zurück bekommt ist natürlich
schon ein Knaller.
Da heißt es jetzt wirklich: testen …
Hallo Thomas!
Und für das Ticket genügt das richtige Passwort der Workstation und die Benutzerdaten des Ticketziehers?!
Interessanterweise funktioniert das auch an geclonten Ubuntu-Clients, die nicht in der Domäne sind - „#net ads testjoin“.
Aber auch nicht immer. Vielleicht wenn das Maschinenpasswort nicht stimmt? Aber dieses dann einfach (über die macct-Datei) auf den richtigen Wert zu setzen reicht auch nicht. Da muss es noch etwas anderes geben.
Ich habe unzählige Stunden damit verbracht, aber keine Logik gefunden.
Gtuß - Rainer
Hallo Thomas!
Und für das Ticket genügt das richtige Passwort der Workstation und
die Benutzerdaten des Ticketziehers?!
Interessanterweise funktioniert das auch an geclonten Ubuntu-Clients,
die nicht in der Domäne sind - „#net ads testjoin“.
Aber auch nicht immer. Vielleicht wenn das Maschinenpasswort nicht
stimmt? Aber dieses dann einfach (über die macct-Datei) auf den
richtigen Wert zu setzen reicht auch nicht. Da muss es noch etwas
anderes geben.
Ich habe unzählige Stunden damit verbracht, aber keine Logik gefunden.
samba speichert das beim Domänenbeitritt mit dem Server ausgehandelte
Geheimnis lokal in seinem Schlüsselspeicher. Gleichzeitig landet das
Geheimnis auf dem Server im AD im Computeraccount. Da der
Samba-Schlüsselspeicher über das Linbo-Image an die anderen Clients
ausgerollt und beim BS-Start der Hashwert des Geheimnisses über die
macct-Datei in den jeweiligen Computeraccount gepumpt wird, bleibt das
konsistent. Wenn du jetzt aber auf einem Client nochmal der Domäne
beitrittst, stimmt das Ganze für diesen Client nicht mehr und der Server
lässt keine Domänenauthentifizierung mehr zu. Funktioniert eigentlich
wie bei Windows.
Versuch mal mit den Clients, die nicht mehr gehen den Workaround:
ich stecke ja vor dem gleichen Problem:
und denke dass die drei Schritte nicht reichen.
wir haben die verfügbaren ubuntu1804basis.cloop auf den Server geholt,
Eingetragen in die devices.csv; Aufbau einer start.conf usw. linuxmuster-import-devices per Linbo partitioniert und "new" verteilt. linuxmuster-distupgrade
die IP Adresse in die „noProxy“ Alias Firewall Regel-Liste (davon schreibt hier keiner mehr was?) linuxmuster-adsso
(als linuxadmin)
An dem Standort war zu keinem Zeitpunkt mit diesen Linux PCs ein Domänen-Logon möglich.
(zuvor unter LMLv6 lief hier jahrelang Linux Ubuntu drauf)
In der host Datei gibt es neben den IPv6 Einträgen, folgende beiden Zeile: 127.0.0.1 localhost 127.0.1.1 template
was ist damit zu tun? hostname -f: r207-pc05.bw-wiz.llan
der Stimmt.
Die Fragen sind also:
„Computeraccount löschen“ meint aus der devices.csv löschen und linuxmuster-import-devices
„Computeraccount wieder anlegen“ mit selben namen? dann wieder linuxmuster-import-devices
Muss die /etc/hosts Datei angepasst werden?
Was ist mit der macct-Datei ?
Was ist jetzt mit dem Befehl: linuxmuster-adsso
@Holger:
Habt ihr den universellen postsync eingerichtet?
Gibt es ein Verzeichnis
/srv/linbo/linuxmuster-client bei euch?
nein und nein…
Wir sprechen von LMLv7?
Ich habe dazu was gefunden: Anpassungen mit Postsync-Scripten
Aber wie (und wofür) das Grundeingerichtet wird fand ich bisher noch nicht.
thomas:
Versuch mal mit den Clients, die nicht mehr gehen den Workaround:
* Computeraccount löschen
* Computeraccount wieder anlegen
* synchronisiert starten.
VG, Thomas
Hallo Thomas,
ich stecke ja vor dem gleichen Problem:
und denke dass die drei Schritte nicht reichen.
wir haben die verfügbaren ubuntu1804basis.cloop auf den Server geholt,
linuxmuster-import-devices|
per Linbo partitioniert und „new“| verteilt.
linuxmuster-distupgrade|
die IP Adresse in die „noProxy“ Alias Firewall Regel-Liste (davon
schreibt hier keiner mehr was?)
linuxmuster-adsso|
(als linuxadmin)
An dem Standort war zu keinem Zeitpunkt mit diesen Linux PCs ein
Domänen-Logon möglich.
(zuvor unter LMLv6 lief hier jahrelang Linux Ubuntu drauf)
In der host Datei gibt es die Zeile:
127.0.1.1 template|
was ist damit zu tun?
Das müssen die beantworten, die das cloop gebastelt haben.
hostname -f: r207-pc05.bw-wiz.llan|
der Stimmt.
Die Fragen sind also:
„Computeraccount löschen“ meint aus der devices.csv löschen und
linuxmuster-import-devices
„Computeraccount wieder anlegen“ mit selben namen? dann wieder
linuxmuster-import-devices
das ist nur für den Fall, dass man auf dem selben Rechner mit
verschiedenen Systemen der Domäne beigetreten ist. Dann ist nämlich u.U.
der Computeraccount nicht mehr konform.
Was ist jetzt mit dem Befehl: |linuxmuster-adsso|
linuxmuster-client-adsso-setup braucht man, um den Master initial
einzurichten und um der Domäne beizutreten. Danach erstellt man gleich
ein Image, damit man eine konforme macct-Datei hat.
Wichtig ist, dass man vor dem Domänenbeitritt die macct-Datei löscht,
die evtl. mit dem cloop mitgeliefert wird. Denn sonst wird beim ersten
Neustart des Systems nach dem Setup auf dem Server ein falsches
Computeraccountpasswort gepatcht.
