Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste Überarbeitung Beide Seiten der Revision | ||
invis_server_wiki:upgrade:sernetsamba2ownsamba [2017/06/16 06:17] flacco |
invis_server_wiki:upgrade:sernetsamba2ownsamba [2017/06/30 08:54] flacco [Reparatur der AD-Strukturen und Funktionstest] |
||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Sernet Samba Pakete ersetzen ====== | ====== Sernet Samba Pakete ersetzen ====== | ||
+ | //**Warnung:** Wir haben dieses Upgrade bereits mehrere Male erfolgreich durchgeführt. In einem der Fälle ist das Upgrade fehlgeschlagen. Die genaue Ursache konnten wir noch nicht ermitteln. Was nicht mehr funktionierte war das IDMapping zwischen UNIX UIDs/GIDs und den Windows SIDs. Der Fehler war so schwer, dass wir (da der Server virtualisiert war) auf einen vor dem Upgrade angelegten Snapshot der VM zurück springen mussten. \\ | ||
+ | Der wesentliche Unterschied dieses Falles zu allen anderen Fällen war die Tatsache, dass das betroffene AD mittels "classic-upgrade" aus einer klassischen Samba-Domäne aufgebaut wurde. Vermutlich ist dies auch die Ursache für den Fehlschlag. **Sichern Sie Sich vor dem Upgrade also auf jeden Fall einen Weg zurück!**// | ||
+ | |||
+ | //**Hinweis:** Die nachfolgend beschriebene Migration macht nur Sinn, wenn Ihr invis-Server mindestens unter openSUSE Leap 42.1 betrieben wird. Für ältere Installationen unter openSUSE 13.1, lesen Sie bitte die Upgrade-Beschreibung **[[https://wiki.invis-server.org/doku.php/invis_server_wiki:upgrade:10.x-to-12.x|hier]]**.// | ||
Mit der Entscheidung seitens der Sernet GmbH für deren Samba Pakete nur noch kostenpflichtige Maintenance anzubieten wurde es für uns als Open-Source-Projekt unmöglich dem zu folgen. Da die von openSUSE gelieferten Samba Pakete noch immer ohne Active-Directory geliefert werden, mussten wir eigene Pakete bauen. Es stehen zwei Repositories zur Verfügung: | Mit der Entscheidung seitens der Sernet GmbH für deren Samba Pakete nur noch kostenpflichtige Maintenance anzubieten wurde es für uns als Open-Source-Projekt unmöglich dem zu folgen. Da die von openSUSE gelieferten Samba Pakete noch immer ohne Active-Directory geliefert werden, mussten wir eigene Pakete bauen. Es stehen zwei Repositories zur Verfügung: | ||
Zeile 16: | Zeile 20: | ||
Die entsprechende Repository-Datei finden Sie im Download-Bereich des Repositories. | Die entsprechende Repository-Datei finden Sie im Download-Bereich des Repositories. | ||
- | ===== Sichern des Active-Directories und entfernen der Sernet-Pakete ===== | + | Während des gesamten Upgrade-Vorgangs sollten alle Client-PCs im Netzwerk herunter gefahren sein. Starten Sie die Clients frühestens nach Abschluss der Tests wieder. |
+ | |||
+ | ===== Sichern des Active-Directories ===== | ||
invis-Server verfügen über ein kleines Script um das gesamte Active-Direktory zu sichern. Führen Sie dies zunächst vorsichtshalber aus: | invis-Server verfügen über ein kleines Script um das gesamte Active-Direktory zu sichern. Führen Sie dies zunächst vorsichtshalber aus: | ||
Zeile 24: | Zeile 30: | ||
</code> | </code> | ||
- | Die Sicherung in Form eine tar.gz Archivs finden Sie unter: <file>/srv/shars/archiv/sicherungen/vollsicherungen/ad</file> | + | Die Sicherung in Form eine tar.gz Archivs finden Sie unter: <file>/srv/shares/archiv/sicherungen/vollsicherungen/ad</file> |
+ | |||
+ | Es kann auch nicht schaden die Keytab des Systems, sowie die Samba-Konfiguration zu sichern. Zwingend für das Upgrade ist dies jedoch nicht. | ||
+ | |||
+ | Legen sie sich einfach Sicherungskopien von <file>/etc/krb5.keytab</file> und <file>/etc/samba</file> an. | ||
+ | |||
+ | ===== Entfernen der Sernet-Pakete ===== | ||
+ | |||
+ | Bevor Sie starten, sollten Sie sich im Klaren sein, dass es keinen Weg zurück gibt. Die "noch" auf Ihrem Server installierten Pakete sind nicht mehr erhältlich, einmal deinstalliert muss das Upgrade erfolgen! | ||
+ | |||
+ | Stoppen Sie zunächst den Samba-Dienst und den SSSD: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # rcsernet-samba-ad stop | ||
+ | invis:~ # systemctl stop sssd stop | ||
+ | </code> | ||
+ | |||
+ | Öffnen Sie YaST und suchen Sie in der Software-Verwaltung nach Paketen die den Begriff "sernet" im Namen tragen und markieren Sie diese mit der Minus-Taste zum Löschen. YaST wird daraufhin eine Reihe von Samba-Paketen aus der openSUSE Distribution automatisch zur Installation auswählen. Dies können Sie zunächst akzeptieren. | ||
+ | |||
+ | Hier die Liste der zu entfernenden Pakete: | ||
+ | |||
+ | * sernet-samba | ||
+ | * sernet-samba-client | ||
+ | * sernet-samba-common | ||
+ | * sernet-samba-libs | ||
+ | * sernet-samba-libsmbclient0 | ||
+ | * sernet-samba-ad | ||
+ | |||
+ | ===== Installation der neuen Pakete ===== | ||
+ | |||
+ | Die Installation der invis-Samba-Pakete erfordert den Anbieterwechsel einiger jetzt auf dem System präsenter Pakete. Um alles zu installieren und aufzulösen sind zwei Schritte notwendig. | ||
+ | |||
+ | Zunächst muss die Installation der Samba-AD Pakete erfolgen. | ||
+ | |||
+ | Hier die erforderlichen Pakete: | ||
+ | |||
+ | * samba | ||
+ | * samba-ad | ||
+ | * samba-client | ||
+ | * samba-winbind | ||
+ | * samba-doc | ||
+ | * samba-libs | ||
+ | |||
+ | Die Installation mit zypper sieht dann so aus: | ||
+ | |||
+ | <code> | ||
+ | inivs:~ # zypper -n install --force-resolution samba samba-ad samba-client samba-winbind samba-doc samba-libs | ||
+ | </code> | ||
+ | |||
+ | Diese Installation hinterlässt leider einen Mix aus Samba-Paketen, die teils aus der openSUSE Distribution stammen und teils aus unserem Repository. Um dies zu bereinigen muss ein Distribution-Upgrade aus unserem Samba-Repository heraus erfolgen: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # zypper -n dup --from spins_invis_stable_samba --allow-vendor-change | ||
+ | </code> | ||
+ | |||
+ | Damit ist der Austausch der Pakete abgeschlossen. Es muss noch dafür gesorgt werden, dass der Samba-Dienst zukünftig beim Reboot des Servers automatisch gestartet wird: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # systemctl enable samba.service | ||
+ | </code> | ||
+ | |||
+ | ===== Reparatur der AD-Strukturen und Funktionstest ===== | ||
+ | |||
+ | Innherhalb des Active Directory hat sich durch die Aktualisierung der Version strukturell einiges geändert. Diese Teile werden jetzt von Samba als fehlerhaft angesehen und müssen repariert werden: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # samba-tool dbcheck --fix --yes | ||
+ | </code> | ||
+ | |||
+ | Sollte der obige Reparaturlauf Probleme offen lassen und ggf. auch die Logon-Scripts nicht mehr korrekt funktionieren, gehen Sie nach folgender Anleitung im Samba-Wiki vor: | ||
+ | |||
+ | **[[https://wiki.samba.org/index.php/Updating_Samba#Fixing_Incorrect_Sysvol_and_Directory_ACLs | Sysvol und AD ACLs zurücksetzen]]** | ||
+ | |||
+ | Starten Sie jetzt Samba und den SSSD neu: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # systemctl start samba.service | ||
+ | invis:~ # systemctl start sssd.service | ||
+ | </code> | ||
+ | |||
+ | Prüfen Sie jetzt, ob Ihr System alle Benutzer und Gruppen korrekt anzeigt: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # getent passwd | ||
+ | invis:~ # getent group | ||
+ | </code> | ||
+ | |||
+ | Ist dies nicht der Fall, kann es hilfreich sein den Cache des sssd zu löschen. Hierfür hat der invis-Server ein eigenes Script im Gepäck: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # delssscache | ||
+ | </code> | ||
+ | |||
+ | Überprüfen Sie die Benutzer und Gruppen erneut wie oben gezeigt. Bleiben die Listen leer, kann das daran liegen, dass der SSSD seinen Cache noch nicht wieder aufgebaut hat. Versuchen sie testweise die Identität eines Benutzers anzunehmen: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # su - benutzername | ||
+ | </code> | ||
+ | |||
+ | Gelingt dies nicht, wird es Zeit die Logfiles des Samba Dienstes zu kontrollieren. Sie finden sie unter: <file>/var/log/samba</file> | ||
+ | Sollte alles wie erwartet funktionieren, ist es jetzt Zeit einen ersten Client wieder zu starten und die Domänenanmeldung zu testen. |