wir haben es auch mal gewagt und sind mit einem Testsystem auf die 7.2 gegangen. Bin meines Wissens genau nach Anleitung vorgegangen.
Dann passierte folgendes:
Client konnte sich nicht anmelden → lag zunächst am DNS (resolv.conf enthielt einen falschen search-Eintrag). Nachdem das korrigiert war (sollte das nicht per DHCP automatisch passen?) funktionierte die Anmeldung dann.
es fehlten dann aber die Tauschverzeichnisse unter Linux (also auch H_auf_Server). Wenn ich in Nautilus auf den Server klicke, fragt er mich nach den Anmeldedaten (akzeptiert diese aber nicht). Das habe ich bisher auch nicht wieder hinbekommen. Gibt es da einen Trick oder eine Stelle, an der ich suchen könnte? Neuerstellen der GPO auf dem Server habe ich schon versucht. Auch die komplette Neuanmeldung in der Domäne mit anschließendem Image-Erstellen hat nichts gebracht.
dann noch die unangenehme Überraschung (ich dachte, das wäre ich los geworden), dass ich mich nach einmaligem Anmelden unter Linux nicht mehr unter Windows anmelden kann („Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung“)
zu guter Letzt: ich habe direkt nach der Image-Erstellung einen zweiten Rechner formatiert und synchronisiert und war ganz froh, dass ich mich dort anmelden konnte. Aber auch war nur möglich, bis ich mich am anderen Rechner angemeldet habe. Danach kam dann: id: »LEHR01$“: Einen solchen Benutzer gibt es nicht [WARNING] Exception when querying groups of user LEHR01$, it probaply does not exist linuxmuster-linuxclient7 status meldet beim Versuch, ein Kerberos-Ticket für den Computeraccount zu bekommen noch: kinit: Vorauthentifizierung fehlgeschlagen bei Anfängliche Anmeldedaten werden geholt.
Ich kann den Rechner problemlos wieder in die Domäne aufnehmen, aber frisch synchronisiert geht es derzeit nicht.
Bei der Aufnahme lese ich noch: ! Failed to update Kerberos configuration, not fatal, please check manually: Setting attribute standard::type not supported
und [WARNING] Uid could not be found! Continuing anyway!
Ob und wie das alles zusammenhängt, ob ich etwas übersehen habe oder tatsächlich irgendwas kaputt ist - das ist erst einmal meine Beobachtung, nachdem ich so Dinge wie DNS überprüft habe.
Ich freue mich über jede Idee, wo ich weiter suchen oder was ich übersehen haben könnte.
… keines der Probleme habe ich bisher beobachten können.
Vorgestern Abend hat Jesko seine Schule upgedatet: auch da (nur
Linuxclients) bisher keine Probleme.
Du hast das dpkg-reconfigure gemacht vor dem Einspielen der neuen
Quellen und dem darauffolgenden update der Pakete?
Ist der linuxmuster-linuxclient7 auf den Clients aktuell?
Stimmen Systemzeiten von Client, server und OPNsense überein?
… das mit dem fehlenden Home (H:) hatte hier schon mal jemand … wenn
ich das richtig erinnere.
Ich schaue jetzt nochmal, ob die ganzen Namen passen oder da evtl. irgendwas nicht gepatcht wird - also Dinge, die auf dem Client komisch sind (wie ja auch diese Sache mit der resolv.conf).
Das Image lief ja unter 7.1 problemlos - darum wundert es mich gerade etwas.
Und da ist jede Idee ist willkommen, wo ich genauer hinschauen könnte, falls das ein oder andere irgendwem bekannt vorkommt.
Ich weiß nicht, ob ich es beruhigend oder beunruhigend finde, dass ich an das alles schon gedacht habe.
Ich nehme Windows nochmal neu in die Domäne auf, mit aktuellen Regpatches und probiere dann mal, ob unter Windows alles läuft.
Dann das ganze nochmal unter Linux - erst einmal alles für einen Client, Hostname überprüfen, DNS, Zeit, etc. - und dann auf einem weiteren.
Aber ist das so - wenn ich die verschiedenen Shares anklicke, sind die unter Windows UND Linux standardmäßig eingebunden? Oder gilt das nur für Windows?
Letzter Stand war unter Linux: gar keine Shares. Was mich nicht wundert, weil ich mich ja beim Klick auf SERVER in Nautilus auch Anmelden soll (da würden ja bei korrekter Anmeldung einfach die passenden Shares gezeigt, oder?).
Gerade noch einmal getestet (linux):
Rechner 1 in die Domäne aufgenommen → klappt
Image erzeugt
Rechner zwei „neu+start“
linuxmuster-linuxclient7 status zeigt:
[INFO] #### linuxmuster-linuxclient7 status ####
[INFO] Linuxmuster-linuxclient7 is setup!
[INFO] Testing if domain is joined...
[INFO] Checking joined domains
[INFO] Joined domains:
[INFO] * corvi.linuxmuster.lan
[INFO] Testing if the domain join actually works
[INFO] * Checking if the group "domain users" exists
[INFO] * Trying to get a kerberos ticket for the Computer Account
kinit: Vorauthentifizierung fehlgeschlagen bei Anfängliche Anmeldedaten werden geholt.
[ERROR] Could not get a kerberos ticket for the Computer Account!
[ERROR] Logins of non-cached users WILL NOT WORK!
[ERROR] Please try to re-join the Domain.
das habe ich ja gemacht - mehrmals (auch schon mit „clean“ ganz raus, Neustart, usw.). Der Join gelingt ja auch - nur wenn ich das Image auf einen zweiten Client synchronisiere, ist dieser dann nicht mehr in der Domäne (bzw. schon in der Domäne, aber Kerberos bekommt kein Ticket, s.o.).
Eine Sache habe ich gerade noch, die mich irritiert. Ich habe im Internet irgendwo gefunden, dass evtl. das Passwort „zu schwach“ ist - das könnte ich ja ändern/testen.
Aber in dem Zusammenhang wurde ein kinit -k erwähnt. Das ergibt bei mir: kinit: Realm für Rechner kann nicht bestimmt werden (Principal host/admin-tarox@)
admin-tarox ist ein völlig anderer Rechner, auf dem das Image der 7.1 lief… Von diesem wurde aber meines Wissens nach kein Image erstellt - nur eben angemeldet. Wie kommt das dahin?
wie bist du den der Domäne beigetreten?
Bist du da erst mal ausgetreten?
Hast du die /etc/kbr5.keytab entfernt und die kbr.conf (… die heißt nur
so ähnlich … aus dem Kopf)?
Beigetreten mit linuxmuster-linuxclient7 setup. Was ja auch funktioniert zumindest erst einmal.
Erledigt das Austreten linuxmuster-linuxclient7 clean die Aufräumarbeiten nicht? Bzw. der Domänen-Join mit setup? Steht ja da, dass erst einmal alles Alte entfernt wird - ist das nicht so? Kann ich natürlich später mal schauen, ob ich noch irgendwelche Reste finde…
Aber der Domänenbeitritt scheitert ja auch nicht. Ich kann mich auf dem Client ja auch anmelden. Nur eben auf keinem anderen Client mit diesem Image (frisches Image direkt nach Domänenbeitritt).
an dem Client, der den Domänenbeitritt gemacht hat, kann man sich nach
einem Reboot auch mit anderen Nutzern erfolgreich anmelden?
Das geht auch nach dem Erstellen des Images an diesem Rechner?
Geht es auch, nachdem man diesen Rechner neu gesynct hat?
Nur an anderen Clients geht es nicht?
wurde die neben dem Image liegende IMAGENAME.qcow2.macct Datei auch beim
Erstellen des Images neu geschrieben?
Ist der Timestamp der Datei also ähnlich zu dem des Images?
Ich habe nach dem erneuten Windows-Domänenbeitritt ein Win-10-Image geschrieben und mit regpatch synchronisiert gestartet. Anmeldung geht, alle Laufwerke sind da. So weit so gut.
Jetzt synchronisiere ich dieses Image auf den zweiten Rechner und schaue mal, ob das da genau so ist. Dann wäre zumindest die Windows-Welt in Ordnung.
Linux werde ich im Anschluss noch einmal genau so Handhaben (und mal genau nach Dateiresten schauen).
Für heute genügt das aber - Danke fürs Mitdenken!
Liebe Grüße
Thomas
PS: wir hatten noch ein Problem bei einem BIOS/SATA-Rechner beim Linbo-Update. Der bootete zunächst (noch altes Linbo), nach dem Aktualisieren von Linbo kam dann aber eine Schleife („<irgendwas/linbo?> is up to date“ und ein paar Zeilen mehr). Sollte sich das auf anderen Clients wiederholen, mache ich mal einen Screenshot.
Wir haben aber insgesamt immer Mal Probleme, wenn wir unbedacht mit Clients die Linbo-Version wechseln. Z.B. bei einem 6.2er-Image muss man aufpassen, das nicht einfach am 7er-Netz zu starten. Dann war es das nämlich: ich kann mich weder mit dem alten noch mit dem neuen Passwort anmelden, damit auch nicht partitionieren. linbo-remote hilft dann (oder wenn ein OS noch bootet das Löschen der Cache-Partition).
Habe ich schon einmal irgendwo gepostet - es wäre gut, wenn beim PXE-Boot von Linbo auch das dazu passende Passwort in jedem Fall funktionieren würde, aber da scheint irgendwas schief zu gehen.
PS: wir hatten noch ein Problem bei einem BIOS/SATA-Rechner beim
Linbo-Update. Der bootete zunächst (noch altes Linbo), nach dem
Aktualisieren von Linbo kam dann aber eine Schleife („<irgendwas/linbo?>
is up to date“ und ein paar Zeilen mehr). Sollte sich das auf anderen
Clients wiederholen, mache ich mal einen Screenshot.
das aktualisieren von linbo während des ersten boots dauert immer mal
ein wenig: dann geht der boot weiter: wenn da aber nach 2 Minuten noch
nichts passiert ist, dann gibt es ein Problem.
Für solche Fälle gibt es den Startparameter
warmstart=no
der dafür sorgt, dass linbo nicht nach dem update versucht das neue
linbo direkt zu laden, sondern dass das linbo dann den Rechner neu startet.
Allerdings wird dann auch beim booten von linux aus linbo heraus wieder
ein reboot gemacht.
Unter Windows war das Problem wohl der Regpatch. Ich habe die Einträge einzeln nachgeschaut und regedit meldete, dass einige Einträge ungültig seien. Dazu habe ich auch etwas hier in einem anderen Beitrag gefunden.
Daher stimmte unter Windows der Hostname nicht - nachdem ich die Dateien nachbearbeitet habe, funktioniert die Anmeldung unter Windows jetzt.
Dazu zwei Anmerkungen:
ist es egal, ob als SAMBADOMAIN in den REG-Dateien der kurze oder volle Name ersetzt wird? In der Anleitung finde ich beides (hier z.B. nur das VOR linuxmuster.lan, bei uns wäre das corvi)
in meiner Beispiel-Reg-Datei hatte ich mehrmals Einträge wie "Hostname"="{$HostName$}"
Das führte bei mir zu zwei Einträgen in der Registry: HostName und Hostname. Ist das noch ein Typo in den Vorlagen oder was davon nimmt Windows?
Bei Linux bin ich noch nicht weiter gekommen - später
in meiner Beispiel-Reg-Datei hatte ich mehrmals Einträge wie
„Hostname“=„{$HostName$}“|
Das führte bei mir zu zwei Einträgen in der Registry: |HostName| und
Hostname>. Ist das noch ein Typo in den Vorlagen oder was davon
nimmt Windows?
mein regpatch unter Windows:
Windows Registry Editor Version 5.00
; linuxmuster.net 7
; patches hostname, to be applied after every image sync
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ActiveComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\]
"Hostname"="{$HostName$}"
"NV Hostname"="{$HostName$}"
noch ein Hinweis: Image und regpatch liegen ja unter
/srv/linbo/images/IMAGENAME/
und heißen
IMAGENAME.qcow2
und
IMAGENAME.reg
also NICHT! IMAGENAME.qcow2.reg
… ich gleich früher hießen die regpatches IMAGENAME.cloop.reg … schau
das mal genau nach.
Bei Linux bin ich noch nicht weiter gekommen - später
auch hier: der postsync heißt inzwischen anders, ähnlich wie der
regpatch, nicht mehr IMAGENAME.cloopp.postsync sondern
IMAGENAME.postsync.
Der Grund ist das differentielle Image: er wird ja nach dem sync beider
Images ausgeführt und nicht nur nach dm qcow2: daher die Namensverschiebung.
Bitte kontrollier bei linux noch die /etc/hostname und die /etc/hosts ob
die den korrekten Inhalt haben.
Du hast in Deinem Regpatch gar keine Infos zur Domäne - offenbar funktioniert es dennoch (oder es ist tatsächlich nur der „präfix“ zu linuxmuster.lan nötig und Du hast keinen?
Die Dateinamen habe ich beachtet - der Patch wurde ja auch angewandt, aber offenbar ging dabei etwas schief - so eine Warnmeldung in regedit hatte ich jedenfalls noch nicht.
Was steht denn bei Dir in hostname/hosts? Und was gibt „domainname“ bei Dir aus? Die Hosts-Datei habe ich nicht angerührt (und es lief ja unter der 7.1). Aber da vergleiche ich auch gern noch einmal.
@dorian Zu allem ja. Die Netzwerkverbindung hatte ich auch anfangs im Verdacht, weil der Domänenbeitritt erst ging, nachdem ich dhclient manuell aufgerufen habe. Und ich beobachte ja immer mal seltsame Timing-Probleme mit Netzwerkverbindungen (z.B. dass ein Rechner offline ist, weil Linbo nicht lange genug wartet - hab ich schon mal gepostet - hat nichts mit dhcpretry zu tun).
Aber die Rechner bekommen IP, haben inzwischen auch den richtigen Hostnamen - funktionieren tut es dennoch (bisher) nicht. Aber morgen probiere ich es noch einmal vor Ort.
