{"id":2921,"date":"2021-09-20T07:00:00","date_gmt":"2021-09-20T05:00:00","guid":{"rendered":"https:\/\/www.my-it-brain.de\/wordpress\/?p=2921"},"modified":"2021-09-06T10:11:50","modified_gmt":"2021-09-06T08:11:50","slug":"in-place-upgrade-fuer-red-hat-enterprise-linux-rhel","status":"publish","type":"post","link":"https:\/\/www.my-it-brain.de\/wordpress\/in-place-upgrade-fuer-red-hat-enterprise-linux-rhel\/","title":{"rendered":"In-Place-Upgrade f\u00fcr Red Hat Enterprise Linux (RHEL)"},"content":{"rendered":"\n<p>In diesem Beitrag beschreibe ich exemplarisch, wie ein In-Place-Upgrade von RHEL 7 auf RHEL 8 durchgef\u00fchrt werden kann. Dabei beschreibe ich zuerst, was ein In-Place-Upgrade ist und in welchen F\u00e4llen es sinnvoll sein kann, bevor ich im Hauptteil anhand einer Test-VM die Durchf\u00fchrung demonstriere.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Was ist ein In-Place-Upgrade?<\/h2>\n\n\n\n<p>Als In-Place-Upgrade wird der Vorgang bezeichnet, bei dem ein Betriebssystem auf ein neues Major-Release aktualisiert wird, ohne das System dabei neuinstallieren zu m\u00fcssen. Statt dessen werden alle zum Betriebssystem geh\u00f6renden Dateien gegen die entsprechende Version des neuen Release ausgetauscht.<\/p>\n\n\n\n<p>Nutzer von Debian und Ubuntu kennen dieses Verfahren unter dem Begriff Distributions-Upgrade.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"https:\/\/wiki.ubuntuusers.de\/Upgrade\/\">https:\/\/wiki.ubuntuusers.de\/Upgrade\/<\/a><\/li><li><a href=\"https:\/\/www.debian.org\/releases\/bullseye\/i386\/release-notes\/ch-upgrading.de.html\">https:\/\/www.debian.org\/releases\/bullseye\/i386\/release-notes\/ch-upgrading.de.html<\/a><\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">In-Place-Upgrade vs. Neuinstallation<\/h2>\n\n\n\n<p>Grunds\u00e4tzlich bevorzuge ich die Neuinstallation eines Systems. Da man sich \u00fcblicherweise mit Backups und Deployment-Skripten darauf vorbereitet hat, einen Dienst bzw. eine Anwendung nach einem Verlust des laufenden Systems wiederherstellen zu k\u00f6nnen, kann man sich dies auch zu Nutze machen und den Dienst bzw. die Anwendung auf einem frisch installierten System wiederherzustellen. Auf diese Weise werden keine Altlasten \u00fcber mehrere Betriebssystemversionen mitgeschleppt.<\/p>\n\n\n\n<p>Gleichzeitig kann man die Downtime verk\u00fcrzen, indem das neue System parallel zum alten aufgebaut wird und man nach dem Abschluss aller Arbeiten und Tests umschaltet. Das Altsystem kann im Nachgang in Ruhe abgebaut werden.<\/p>\n\n\n\n<p>Es gibt jedoch auch Gr\u00fcnde, die f\u00fcr ein In-Place-Upgrade sprechen. Verf\u00fcgt man nur \u00fcber einen einzigen Host und kann kein Parallelsystem aufbauen, kann ein In-Place-Upgrade die L\u00f6sung sein.<\/p>\n\n\n\n<p>Evtl. verf\u00fcgt man selbst zwar  \u00fcber ausreichend Berechtigungen, um das vorhandene System zu aktualisieren, f\u00fcr die Provisionierung neuer Systeme ist man jedoch auf die Unterst\u00fctzung weiterer Stellen angewiesen. Die Abh\u00e4ngigkeitskette l\u00e4sst sich hier zum Teil deutlich reduzieren.<\/p>\n\n\n\n<p>Dabei muss stets bedacht  werden, dass bei einem In-Place-Upgrade auch ein katastrophaler Fehler eintreten kann, welcher zum Verlust des Systems f\u00fchrt. Es ist daher dringend angeraten, eine Datensicherung zu haben, aus welcher das System wiederhergestellt werden kann. Besitzt man ein Backup, auf das man sich verlassen kann, kann es auch schon losgehen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Das Upgrade von RHEL 7 auf RHEL 8<\/h2>\n\n\n\n<p>Laut Kapitel 1 der unter <a href=\"#upgrade-rhel\">[0]<\/a> verlinkten Dokumentation stellt das In-Place-Upgrade den von Red Hat unterst\u00fctzten und empfohlenen Weg dar, um auf das n\u00e4chste Major-Release zu aktualisieren. Dabei kann man stets nur von der letzten Verf\u00fcgbaren RHEL 7 Version auf das jeweils letzte gerade RHEL 8 Release (z.B. 8.4) aktualisieren. Details hierzu k\u00f6nnen im Artikel unter <a href=\"#upgrade-paths\">[1]<\/a> nachgelesen werden.<\/p>\n\n\n\n<p>Die folgenden Abschnitte k\u00f6nnen die Dokumentation unter <a href=\"#upgrade-rhel\">[0]<\/a> nicht ersetzen. Sie sollen lediglich einen kompakten \u00dcberblick \u00fcber den Prozess geben.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Limitierungen<\/h3>\n\n\n\n<p>Zum Zeitpunkt der Artikelerstellung , kann das In-Place-Upgrade nicht auf Systemen mit verschl\u00fcsselten Dateisystemen durchgef\u00fchrt werden.<\/p>\n\n\n\n<p>Netzwerkspeicher, wie z.B. iSCSI oder NAS, werden nicht unterst\u00fctzt und m\u00fcssen w\u00e4hrend des Upgrades ausgeh\u00e4ngt werden. Die dazugeh\u00f6rigen Dienste, wie z.B. <code>autofs<\/code> m\u00fcssen vor\u00fcbergehend deaktiviert werden.<\/p>\n\n\n\n<p>Weitere bekannte Probleme sind Kapitel 8 in <a href=\"#upgrade-rhel\">[0]<\/a> zu entnehmen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Vorbereitung<\/h3>\n\n\n\n<p>Bevor man mit dem Upgrade beginnen kann, sind folgende Voraussetzungen zu schaffen:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Das System erf\u00fcllt die minimalen Systemvoraussetzungen f\u00fcr RHEL 8 (siehe <a href=\"#rhel-limits\">[2]<\/a>).<\/li><li>Zugriff auf Repos mit aktuellen Paketen f\u00fcr RHEL 7.9 und RHEL 8.4.<\/li><li>Korrekte Registrierung des Systems am Red Hat Content Delivery Network (CDN) oder den Red Hat Satellite Server mittels Red Hat Subscription Manager (RHSM).<\/li><\/ul>\n\n\n\n<p><strong>Wichtig:<\/strong> Ich empfehle ausdr\u00fccklich, vor Beginn der Arbeiten ein aktuelles Backup bzw. einen Snapshot zu erstellen, um auf den Ausgangszustand vor der Upgrade-Prozedur zur\u00fcckkehren zu k\u00f6nnen.<\/p>\n\n\n\n<p>Kapitel 2 in <a href=\"#upgrade-rhel\">[0]<\/a> bietet eine ausf\u00fchrliche Schritt-f\u00fcr-Schritt-Anleitung zur Vorbereitung des Upgrades. Der folgende Codeblock bietet eine kompakte \u00dcbersicht der einzelnen Schritte. Als Zielsystem dient eine aktuelle RHEL 7.9 Minimal-Installation.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;tronde@rhel7-t1 ~]$ # \u00dcberpr\u00fcfung, ob eine RHEL-Subskription abonniert wurde\n&#91;tronde@rhel7-t1 ~]$ sudo subscription-manager list --installed\n&#91;sudo] password for tronde: \n+-------------------------------------------+\n    Installed Product Status\n+-------------------------------------------+\nProduct Name:   Red Hat Enterprise Linux Server\nProduct ID:     69\nVersion:        7.9\nArch:           x86_64\nStatus:         Subscribed\nStatus Details: \nStarts:         06.10.2020\nEnds:           06.10.2021\n\n&#91;tronde@rhel7-t1 ~]$ # Aktivierung des RHEL 7 Basis- und Extras-Repo\n&#91;tronde@rhel7-t1 ~]$ sudo subscription-manager repos --enable rhel-7-server-rpms\nRepository 'rhel-7-server-rpms' is enabled for this system.\n&#91;tronde@rhel7-t1 ~]$ sudo subscription-manager repos --enable rhel-7-server-extras-rpms\nRepository 'rhel-7-server-extras-rpms' is enabled for this system.\n\n&#91;tronde@rhel7-t1 ~]$ # Ist locale auf en_US.UTF-8 gesetzt?\n&#91;tronde@rhel7-t1 ~]$ cat \/etc\/locale.conf\nLANG=\"en_US.UTF-8\"\n\n&#91;tronde@rhel7-t1 ~]$ sudo yum install leapp leapp-repository\n# Ausgabe gek\u00fcrtzt\nTransaction Summary\n================================================================================\nInstall  2 Packages (+24 Dependent packages)\n\nTotal download size: 5.3 M\nInstalled size: 19 M\nIs this ok &#91;y\/d\/N]: y\n# Ausgabe gek\u00fcrtzt<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Pre-Upgrade-Bericht erstellen<\/h3>\n\n\n\n<p>Bevor das eigentliche Upgrade durchgef\u00fchrt wird, f\u00fchre ich auf meinem Testsystem das Kommando <code>leapp preupgrade<\/code> aus. Dieses sammelt Informationen \u00fcber das System, um die Upgradef\u00e4higkeit zu bewerten und erstellt einen detaillierten Bericht, welcher im Pfad <code>\/var\/log\/leapp\/leapp-report.txt<\/code> abgelegt wird.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;tronde@rhel7-t1 ~]$ sudo leapp preupgrade\n# Ausgabe gek\u00fcrzt\n============================================================\n                           ERRORS                           \n============================================================\n\n2021-08-31 06:33:26.035495 &#91;ERROR] Actor: repository_mapping\nMessage: Data file \/etc\/leapp\/files\/repomap.csv is invalid or could not be retrieved.\nSummary:\n    Details: Could not fetch repomap.csv from https:\/\/cert.cloud.redhat.com\/api\/pes\/repomap.csv (unreachable address).\n    Hint: Read documentation at: https:\/\/access.redhat.com\/articles\/3664871 for more information about how to retrieve the file.\n2021-08-31 06:35:22.415297 &#91;ERROR] Actor: restricted_pcis_scanner\nMessage: Data file \/etc\/leapp\/files\/unsupported_driver_names.json is invalid or could not be retrieved.\nSummary:\n    Details: Could not fetch unsupported_driver_names.json from https:\/\/cert.cloud.redhat.com\/api\/pes\/unsupported_driver_names.json (unreachable address).\n    Hint: Read documentation at: https:\/\/access.redhat.com\/articles\/3664871 for more information about how to retrieve the file.\n2021-08-31 06:35:47.800140 &#91;ERROR] Actor: pes_events_scanner\nMessage: Data file \/etc\/leapp\/files\/pes-events.json is invalid or could not be retrieved.\nSummary:\n    Details: Could not fetch pes-events.json from https:\/\/cert.cloud.redhat.com\/api\/pes\/pes-events.json (unreachable address).\n    Hint: Read documentation at: https:\/\/access.redhat.com\/articles\/3664871 for more information about how to retrieve the file.\n\n============================================================\n                       END OF ERRORS                        \n============================================================\n\n\nDebug output written to \/var\/log\/leapp\/leapp-preupgrade.log\n\n============================================================\n                           REPORT                           \n============================================================\n\nA report has been generated at \/var\/log\/leapp\/leapp-report.json\nA report has been generated at \/var\/log\/leapp\/leapp-report.txt\n\n============================================================\n                       END OF REPORT                        \n============================================================\n\nAnswerfile has been generated at \/var\/log\/leapp\/answerfile\n&#91;tronde@rhel7-t1 ~]$<\/code><\/pre>\n\n\n\n<p>Dem obigen Codeblock ist zu entnehmen, dass der Pre-Upgrade-Check Fehler festgestellt hat, die behoben werden m\u00fcssen, bevor ein In-Place-Upgrade durchgef\u00fchrt werden kann. Dankenswerter Weise ist sowohl in der Ausgabe auf STDOUT als auch in <code>\/var\/log\/leapp\/leapp-report.txt<\/code> der Knowledge-Base-Artikel <a href=\"#data-required\">[3]<\/a> verlinkt, welcher die L\u00f6sung parat h\u00e4lt.<\/p>\n\n\n\n<p>Ist dieser Fehler behoben, l\u00e4sst man <code>leapp preupgrade<\/code> ein weiteres Mal laufen und pr\u00fcft die Ausgabe erneut. Auf meinem Testsystem erhalte ich nun folgende Ausgabe:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel7-t1 ~]# leapp preupgrade\n# Ausgabe gek\u00fcrzt\n============================================================\n                     UPGRADE INHIBITED                      \n============================================================\n\nUpgrade has been inhibited due to the following problems:\n    1. Inhibitor: Missing required answers in the answer file\nConsult the pre-upgrade report for details and possible remediation.\n\n============================================================\n                     UPGRADE INHIBITED                      \n============================================================\n\n\nDebug output written to \/var\/log\/leapp\/leapp-preupgrade.log\n\n============================================================\n                           REPORT                           \n============================================================\n\nA report has been generated at \/var\/log\/leapp\/leapp-report.json\nA report has been generated at \/var\/log\/leapp\/leapp-report.txt\n\n============================================================\n                       END OF REPORT                        \n============================================================\n\nAnswerfile has been generated at \/var\/log\/leapp\/answerfile<\/code><\/pre>\n\n\n\n<p>Diesmal weist die Ausgabe darauf hin, dass ein Upgrade durch fehlende Antworten in <code>\/var\/log\/leapp\/answerfile<\/code> verhindert wird. Die genannte Datei kann mit einem Editor ge\u00f6ffnet und entsprechend bearbeitet werden:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;remove_pam_pkcs11_module_check]\n# Title:              None\n# Reason:             Confirmation\n# =================== remove_pam_pkcs11_module_check.confirm ==================\n# Label:              Disable pam_pkcs11 module in PAM configuration? If no, the upgrade process will be interrupted.\n# Description:        PAM module pam_pkcs11 is no longer available in RHEL-8 since it was replaced by SSSD.\n# Type:               bool\n# Default:            None\n# Available choices: True\/False\n# Unanswered question. Uncomment the following line with your answer\nconfirm = True<\/code><\/pre>\n\n\n\n<p>Die Datei enth\u00e4lt direkt eine Erkl\u00e4rung, warum das erw\u00e4hnte Modul zu entfernen ist und wie dies zu geschehen hat.<\/p>\n\n\n\n<p>Anschlie\u00dfend empfiehlt sich ein Blick in den Bericht unter <code>\/var\/log\/leapp\/leapp-report.txt<\/code>, um zu pr\u00fcfen, ob einem Upgrade evtl. weitere Gr\u00fcnde entgegen stehen. Auf die Ausgabe des Berichts in diesem Artikel wird aus Platzgr\u00fcnden verzichtet. Da der Inhalt auf jedem System unterschiedlich ausfallen kann, ist sein Nutzen an dieser Stelle ohnehin stark begrenzt.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Durchf\u00fchrung des In-Place-Upgrade<\/h3>\n\n\n\n<p>An dieser Stelle wird es ernst. Man sollte sich noch einmal vergewissern, dass man einen Snapshot bzw. ein geeignetes Backup des Systems hat. Dann wird das Upgrade mit folgendem Befehl gestartet:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># leapp upgrade\n# Ausgabe gek\u00fcrzt\n============================================================\n                           REPORT                           \n============================================================\n\nA report has been generated at \/var\/log\/leapp\/leapp-report.json\nA report has been generated at \/var\/log\/leapp\/leapp-report.txt\n\n============================================================\n                       END OF REPORT                        \n============================================================\n\nAnswerfile has been generated at \/var\/log\/leapp\/answerfile<\/code><\/pre>\n\n\n\n<p>Dieser Vorgang kann mehrere Minuten dauern. <code>Leapp<\/code> l\u00e4dt notwendige Daten herunter und bereitet die RPM-Transaktionen f\u00fcr das Upgrade vor. Dabei wird erneut gepr\u00fcft, ob Gr\u00fcnde vorliegen, die ein Upgrade verhindern k\u00f6nnen. Sollte dies der Fall sein, bricht <code>leapp<\/code> den Vorgang ab und erzeugt einen neuen Bericht.<\/p>\n\n\n\n<p>Ist das Upgrade erfolgreich durchgelaufen, muss das System manuell neugestartet werden. Das System startet anschlie\u00dfend in eine RAM-Disk und aktualisiert alle Pakete des Systems. Anschlie\u00dfend wird automatisch ein Neustart ausgef\u00fchrt. Dieser Vorgang l\u00e4sst sich am besten an einer (virtuellen) Konsole beobachten.<\/p>\n\n\n\n<p>Nachdem das Upgrade abgeschlossen ist, kann man sich wieder am System anmelden und mit folgenden Kommandos pr\u00fcfen, ob das System den gew\u00fcnschten Status hat (vgl. Kapitel 5 in <a href=\"#upgrade-rhel\">[0]<\/a>):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel7-t1 ~]# cat \/etc\/redhat-release \nRed Hat Enterprise Linux release 8.4 (Ootpa)\n\n&#91;root@rhel7-t1 ~]# uname -r\n4.18.0-305.12.1.el8_4.x86_64\n\n&#91;root@rhel7-t1 ~]# subscription-manager list --installed\n+-------------------------------------------+\n    Installed Product Status\n+-------------------------------------------+\nProduct Name:   Red Hat Enterprise Linux for x86_64\nProduct ID:     479\nVersion:        8.4\nArch:           x86_64\nStatus:         Subscribed\nStatus Details: \nStarts:         06.10.2020\nEnds:           06.10.2021\n\n&#91;root@rhel7-t1 ~]# subscription-manager release\nRelease: 8.4<\/code><\/pre>\n\n\n\n<p>Hier sieht alles gut aus.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Post-Upgrade-Tasks<\/h3>\n\n\n\n<p>Kapitel 6 in <a href=\"#upgrade-rhel\">[0]<\/a> beschreibt detailliert, welche Aufgaben nach einem erfolgreichen In-Place-Upgrade noch auszuf\u00fchren sind, um ein m\u00f6glichst sauberes System zu erhalten.<\/p>\n\n\n\n<p>Auf meinem Testsystem sind einige RHEL 7 Pakete zur\u00fcckgeblieben, welche ich mit folgendem Kommando entferne:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># dnf remove `rpm -qa | grep -e '\\.el&#91;67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort`\nUpdating Subscription Management repositories.\nDependencies resolved.\n===============================================================================\n Package              Arch       Version                     Repository   Size\n===============================================================================\nRemoving:\n doxygen              x86_64     1:1.8.5-4.el7               @System      15 M\n kernel               x86_64     3.10.0-1160.31.1.el7        @System      64 M\n kernel               x86_64     3.10.0-1160.36.2.el7        @System      64 M\n leapp                noarch     0.12.1-1.el7_9              @System      93 k\n leapp-repository     noarch     0.14.0-4.el7_9              @System     1.7 M\n python2-leapp        noarch     0.12.1-1.el7_9              @System     618 k\n ustr                 x86_64     1.0.4-16.el7                @System     279 k\n\nTransaction Summary\n===============================================================================\nRemove  7 Packages\n\nFreed space: 146 M\nIs this ok &#91;y\/N]:\n\n# cd \/lib\/modules &amp;&amp; ls -d *.el7*\n3.10.0-1160.25.1.el7.x86_64  3.10.0-1160.36.2.el7.x86_64\n3.10.0-1160.31.1.el7.x86_64\n\n# \/bin\/kernel-install remove 3.10.0-1160.36.2.el7.x86_64 \/lib\/modules\/3.10.0-1160.36.2.el7.x86_64\/vmlinuz\n# \/bin\/kernel-install remove 3.10.0-1160.25.1.el7.x86_64 \/lib\/modules\/3.10.0-1160.25.1.el7.x86_64\/vmlinuz\n# \/bin\/kernel-install remove 3.10.0-1160.31.1.el7.x86_64 \/lib\/modules\/3.10.0-1160.31.1.el7.x86_64\/vmlinuz<\/code><\/pre>\n\n\n\n<p>Damit ist es geschafft. Das System wurde erfolgreich auf RHEL 8 aktualisiert.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Fazit<\/h2>\n\n\n\n<p>Dieser Artikel stellt das RHEL-In-Place-Upgrade vor und nennt kurz einige Gr\u00fcnde, wann dies gegen\u00fcber einer Neuinstallation Vorteile bietet. Anschlie\u00dfend wurde das Upgrade an einem Testsystem demonstriert mit dem Ziel, einen \u00dcberblick \u00fcber den Upgrade-Prozess zu geben.<\/p>\n\n\n\n<p>F\u00fcr In-Place-Upgrades von Produktionssystemen ist ein Blick in die Hersteller-Dokumentation, Backups und sorgf\u00e4ltige Planung unerl\u00e4sslich.<\/p>\n\n\n\n<p>Das f\u00fcr diesen Artikel verwendete Testsystem besteht lediglich aus einer Minimal-Installation ohne Anwendungen von Dritten. Ob ein In-Place-Upgrade auch mit installierten Anwendungen Dritter funktioniert, h\u00e4ngt vom Einzelfall ab und ist sorgf\u00e4ltig zu pr\u00fcfen und zu testen.<\/p>\n\n\n\n<p>Erste Versuche mit Web- und Anwendungsservern aus unserer Umgebung konnten mit positivem Ergebnis abgeschlossen worden.<\/p>\n\n\n\n<p>Es gibt Anwendungsf\u00e4lle, wo ein In-Place-Upgrade vorteilhaft ist. Ich pers\u00f6nlich bevorzuge, wenn m\u00f6glich und vom Aufwand vertretbar, jedoch die Neuinstallation inkl. Migration der Daten auf einem neuen System. So kann sichergestellt werden, dass keine unentdeckten Altlasten mitgeschleppt werden.<\/p>\n\n\n\n<p id=\"upgrade-rhel\">[0] <a href=\"https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_enterprise_linux\/8\/html\/upgrading_from_rhel_7_to_rhel_8\/index\">Upgrading from RHEL 7 to RHEL 8. Instructions for an in-place upgrade from Red&nbsp;Hat Enterprise Linux&nbsp;7 to Red&nbsp;Hat Enterprise&nbsp;Linux&nbsp;8. Red&nbsp;Hat Enterprise&nbsp;Linux 8. Red&nbsp;Hat Customer Content Services.<\/a><\/p>\n\n\n\n<p id=\"upgrade-paths\">[1] <a href=\"https:\/\/access.redhat.com\/articles\/4263361\">Supported in-place upgrade paths for Red Hat Enterprise Linux<\/a> (Login required)<\/p>\n\n\n\n<p id=\"rhel-limits\">[2] <a href=\"https:\/\/access.redhat.com\/articles\/rhel-limits\">Red Hat Enterprise Linux technology capabilities and limits<\/a><\/p>\n\n\n\n<p id=\"data-required\">[3] <a href=\"https:\/\/access.redhat.com\/articles\/3664871\">Data required by the Leapp utility for an in-place upgrade from RHEL 7 to RHEL 8<\/a> (Login required)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In diesem Beitrag beschreibe ich exemplarisch, wie ein In-Place-Upgrade von RHEL 7 auf RHEL 8 durchgef\u00fchrt werden kann. Dabei beschreibe ich zuerst, was ein In-Place-Upgrade ist und in welchen F\u00e4llen es sinnvoll sein kann, bevor ich im Hauptteil anhand einer Test-VM die Durchf\u00fchrung demonstriere. Was ist ein In-Place-Upgrade? Als In-Place-Upgrade wird der Vorgang bezeichnet, bei<span class=\"continue-reading\"> <a href=\"https:\/\/www.my-it-brain.de\/wordpress\/in-place-upgrade-fuer-red-hat-enterprise-linux-rhel\/\">[Weiterlesen&#8230;]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_metis_text_type":"","_metis_text_length":0,"_post_count":0,"footnotes":""},"categories":[3],"tags":[640,641,430,305,389,446,639,350],"class_list":["post-2921","post","type-post","status-publish","format-standard","hentry","category-tutorials","tag-in-place-ugrade","tag-leapp","tag-osbn","tag-planet","tag-rhel","tag-rhel7","tag-rhel8","tag-upgrade"],"_links":{"self":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/2921","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/comments?post=2921"}],"version-history":[{"count":10,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/2921\/revisions"}],"predecessor-version":[{"id":2949,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/2921\/revisions\/2949"}],"wp:attachment":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/media?parent=2921"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/categories?post=2921"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/tags?post=2921"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}