added information on how to perform a downgrade

Author: sebkir

images/update_downgrade_ce_se.png

@@ -19,7 +19,7 @@ Das Update von {CMK} auf eine neue Version läuft etwas anders als bei anderer S
 Warum?
 
 Grund ist, dass {CMK} nicht nur mehrere unabhängige *Instanzen* (_sites_) auf einem Server erlaubt,
-sondern auch mehrere gleichzeitig installierte xref:cmk_versions#[Software-Versionen.] 
+sondern auch mehrere gleichzeitig installierte xref:cmk_versions#[Software-Versionen.]
 Dabei ist jede Instanz einer installierten Version zugeordnet.
 Nehmen Sie als Beispiel folgende Situation auf einem fiktiven Server:
 
@@ -87,17 +87,17 @@ Daher raten wir von diesem Vorgehen dringend ab – und können auch bei einem U
 [#incompatible_mkps]
 === Inkompatible und obsolete MKPs
 
-Über die xref:glossar#mkp[{CMK}-Erweiterungspakete (MKPs)] lässt sich Ihr Monitoring-System recht einfach und bequem erweitern. 
-Auf der einen Seite kommt es dabei vor, dass solche MKPs nicht weiter gepflegt werden und dann ggf. mit neuen Versionen von {CMK} nicht mehr kompatibel sind. 
-Auf der anderen Seite nehmen wir immer wieder neue Plugins und Funktionserweiterungen in {CMK} auf, weshalb MKPs mitunter obsolet werden. 
+Über die xref:glossar#mkp[{CMK}-Erweiterungspakete (MKPs)] lässt sich Ihr Monitoring-System recht einfach und bequem erweitern.
+Auf der einen Seite kommt es dabei vor, dass solche MKPs nicht weiter gepflegt werden und dann ggf. mit neuen Versionen von {CMK} nicht mehr kompatibel sind.
+Auf der anderen Seite nehmen wir immer wieder neue Plugins und Funktionserweiterungen in {CMK} auf, weshalb MKPs mitunter obsolet werden.
 Ihre Funktionalität wird schlicht von {CMK} selbst sichergestellt.
 
-Falls Sie MKPs installiert haben, ist aus diesem Grund eine Prüfung dieser MKPs dringend geboten. 
+Falls Sie MKPs installiert haben, ist aus diesem Grund eine Prüfung dieser MKPs dringend geboten.
 So verhindern Sie, dass inkompatible Pakete das Update behindern oder im Anschluss an das Update doppelte oder zumindest sehr ähnliche Services entstehen.
 
-Prüfen Sie hierzu Ihre installierten MKPs gegen unseren link:https://checkmk.com/de/integrations[Katalog der Check-Plugins^] und entfernen Sie Pakete, welche inzwischen nativ von {CMK} bereitgestellt werden. 
-Bei dieser Gelegenheit können Sie auch MKPs entfernen, die eventuell nur mal für einen Probelauf installiert worden sind. 
-Eine Auflistung finden Sie im [.guihint]#Setup#-Menü unter [.guihint]#Maintenance > Extension packages#. 
+Prüfen Sie hierzu Ihre installierten MKPs gegen unseren link:https://checkmk.com/de/integrations[Katalog der Check-Plugins^] und entfernen Sie Pakete, welche inzwischen nativ von {CMK} bereitgestellt werden.
+Bei dieser Gelegenheit können Sie auch MKPs entfernen, die eventuell nur mal für einen Probelauf installiert worden sind.
+Eine Auflistung finden Sie im [.guihint]#Setup#-Menü unter [.guihint]#Maintenance > Extension packages#.
 Auf der Kommandozeile können Sie sich installierte Erweiterungen mit dem Befehl `mkp list` anzeigen lassen.
 Überprüfen Sie die Ausgabe dieses Befehls auf Erweiterungen, die nicht mehr benötigt werden oder die Sie gar nicht mehr zuordnen können.
 
@@ -107,16 +107,16 @@ Details erklärt der xref:mkps#[Artikel zur Verwendung von MKPs].
 
 *Achtung:*
 Wenn Sie an Dateien, die ursprünglich MKPs entstammen, lokal Änderungen vorgenommen haben, packen Sie das MKP nach Erhöhung der Versionsnummer neu.
-Während des Updates werden sonst geänderte Dateien durch die im MKP enthaltenen überschrieben. 
+Während des Updates werden sonst geänderte Dateien durch die im MKP enthaltenen überschrieben.
 
 // MFS: Sollte hier nicht besser der Verweis auf mkp find und die Empfehlung, vor dem Update MKPs zu erstellen, hin?
 //SP: Nein, das wird ja im folgenden Abschnitt aufgeführt.
 
 [#local_files]
 === Lokale Dateien
 
-Mit lokalen Dateien können Sie die von {CMK} bereitgestellte Funktionalität anpassen und erweitern. 
-Diese Dateien befinden sich im lokalen Teil der Instanzverzeichnisstruktur, d. h. in `~/local`. 
+Mit lokalen Dateien können Sie die von {CMK} bereitgestellte Funktionalität anpassen und erweitern.
+Diese Dateien befinden sich im lokalen Teil der Instanzverzeichnisstruktur, d. h. in `~/local`.
 Lokale Dateien können bei einem Update Probleme bereiten, da sie eventuell nicht mehr zur neuen {CMK}-Version passen.
 
 Da es für {CMK} bei einem Update nicht möglich ist, die lokalen Anpassungen und jede von einem Drittanbieter hergestellte Erweiterung abzufangen und zu behandeln, sollten Sie Ihre {CMK}-Instanz vor einem Update daraufhin überprüfen, ob lokale Dateien bei Ihnen verwendet werden und gegebenenfalls welche.
@@ -135,11 +135,11 @@ Im Idealfall sind lokale Dateien bereits vollständig in xref:#incompatible_mkps
 Verwenden Sie `mkp find` um unpaketierte Dateien zu identifizieren.
 Die weitere Vorgehensweise der Erstellung von Paketen zeigt unser xref:mkps#developers[Artikel zu {CMK}-Erweiterungspaketen.]
 Einmal zu einem Paket zusammengefasst, kann eine Erweiterung als ganzes deaktiviert oder erneut aktiviert werden.
- 
+
 [#backup]
 === Backup und Probelauf
 
-Die Selbstverständlichkeit, ein Backup unmittelbar vor dem Update zu erstellen, um im Falle eines Fehlschlags nicht allzu viel Ihrer Monitoring-Historie zu verlieren, müssen wir Ihnen nicht erklären. 
+Die Selbstverständlichkeit, ein Backup unmittelbar vor dem Update zu erstellen, um im Falle eines Fehlschlags nicht allzu viel Ihrer Monitoring-Historie zu verlieren, müssen wir Ihnen nicht erklären.
 An dieser Stelle relevant ist, dass ein reguläres Backup auch gute Dienste für den Probelauf eines Updates leisten kann.
 So können Sie das Backup unter einem anderen Namen wiederherstellen – und anschließend mit der Instanz `newsite` das Update testen:
 
@@ -497,7 +497,7 @@ omd -f -V $VERSION update --conflict=install $SITE  && omd start $SITE
 
 Es gibt zwei unterschiedliche Vorgehensweisen, um das Update aller in einem xref:distributed_monitoring#[verteilten Monitoring] beteiligten Instanzen –  d.h. der Zentralinstanz und der Remote-Instanzen – durchzuführen.
 
-*Wichtig:* 
+*Wichtig:*
 Für welches Vorgehen Sie sich auch entscheiden:
 Sie sollten auch in diesem Szenario vorher xref:backup#[Backups] aller Instanzen anlegen.
 
@@ -511,7 +511,7 @@ Ist dies nicht möglich – beispielsweise, weil die Umgebung auf Instanzen in v
 Der Versionsunterschied darf bei Major-Updates exakt eine Version betragen und setzt immer ein bestimmtes Patchlevel der Ausgangsversion voraus.
 
 Diese Reihenfolge muss dafür unbedingt eingehalten werden: Zunächst nehmen Sie die Aktualisierung aller Remote-Instanzen vor, erst als letztes führen Sie das Update der Zentralinstanz durch.
-So ist sichergestellt, dass zu keinem Zeitpunkt eine von einer neueren {CMK}-Version erzeugte Konfiguration bei einer älteren {CMK}-Version landet. 
+So ist sichergestellt, dass zu keinem Zeitpunkt eine von einer neueren {CMK}-Version erzeugte Konfiguration bei einer älteren {CMK}-Version landet.
 
 Die folgende Tabelle zeigt die möglichen Kombinationen beim Update von {v21} zur {v22}:
 
@@ -719,17 +719,26 @@ Daraus resultiert folgende Reihenfolge für das Upgrade:
 . Hinterlegen Sie in der Zentralinstanz noch unter der {SE} die Subskriptionsdaten für die {CE}
 . Führen Sie als letztes das Upgrade der Zentralinstanz auf {CE} durch.
 
-Soll ein Upgrade direkt von der {RE} auf {CE} erfolgen, müssen Sie auf der Zentralinstanz als Zwischenschritt auf die {SE} hieven: Zuerst führen Sie das Upgrade der 
-Zentralinstanz von {RE} nach {SE} durch, es folgt das Upgrade der Remote-Instanzen direkt von {RE} nach {CE}. Zuletzt führen Sie noch das Upgrader der Zentralinstanz von {SE} nach {CE} durch.
+Soll ein Upgrade direkt von der {RE} auf {CE} erfolgen, müssen Sie auf der Zentralinstanz als Zwischenschritt auf die {SE} hieven: Zuerst führen Sie das Upgrade der
+Zentralinstanz von {RE} nach {SE} durch, es folgt das Upgrade der Remote-Instanzen direkt von {RE} nach {CE}. Zuletzt führen Sie noch das Upgrade der Zentralinstanz von {SE} nach {CE} durch.
 
 [#down2cee]
-== Downgrades 
+== Downgrades
 
 === Einleitung
 
 Auch Downgrades zwischen den Editionen sind vorgesehen.
-Ein Downgrade ist eine komplexere und damit zeitaufwändigere Aktion, da einige Funktionen in der Zielversion möglicherweise nicht funktionieren
-und manuell deaktiviert und durch eine möglicherweise weniger effiziente oder weniger komfortable Alternative ersetzt werden müssen.
+Ein Downgrade ist eine komplexere und damit zeitaufwändigere Aktion, da einige Funktionen in der Zielversion möglicherweise nicht funktionieren und manuell deaktiviert und durch eine möglicherweise weniger effiziente oder weniger komfortable Alternative ersetzt werden müssen.
+
+Das eigentliche Downgrade *muss* - genau wie beim Update oder Upgrade - mit dem Befehl `omd update` durchgeführt werden.
+Die Details dazu finden Sie im im Abschnitt xref:update#execute[Durchführen des Updates.]
+
+Wenn Sie nun beispielsweise von der {CE} auf die {SE} downgraden wollen, überzeugt sich {CMK}, ob das tatsächlich Ihre Intention ist:
+
+image::update_downgrade_ce_se.png[width=30%]
+
+Sobald Sie diese Abfrage mit [.guihint]#yes# bestätigen, geht das Downgrade unmittelbar los.
+Informieren Sie sich im Folgenden unbedingt, was *vor* diesem Downgrade zu erledigen ist.
 
 
 [#cce2cee]

src/common/de/update.asciidoc

@@ -18,7 +18,7 @@ xref:cmc_migration#[Migration to the CMC]
 Updating {CMK} is a bit different than most other software packages that you may be familiar with.
 Why is that?
 
-The reason is that {CMK} not only allows multiple independent *sites* to run on a single server, 
+The reason is that {CMK} not only allows multiple independent *sites* to run on a single server,
 but it also allows multiple xref:cmk_versions#[software versions] to be installed simultaneously.
 With this system each site is assigned to an installed version of the software.
 To illustrate, we can take the following situation on a fictional server:
@@ -73,17 +73,17 @@ We therefore strongly advise against such a procedure -- and will also no longer
 [#incompatible_mkps]
 === Incompatible and obsolete MKPs
 
-Your monitoring system can be extended quite easily and conveniently using the xref:glossar#mkp[{CMK} extension packages (MKPs)]. 
-On the one hand, it is possible that some older MKPs are no longer being maintained and thus may no longer be compatible with newer versions of {CMK}. 
-On the other hand, we keep adding new plug-ins and functional extensions to {CMK}, which is why MKPs sometimes become obsolete. 
+Your monitoring system can be extended quite easily and conveniently using the xref:glossar#mkp[{CMK} extension packages (MKPs)].
+On the one hand, it is possible that some older MKPs are no longer being maintained and thus may no longer be compatible with newer versions of {CMK}.
+On the other hand, we keep adding new plug-ins and functional extensions to {CMK}, which is why MKPs sometimes become obsolete.
 The functionality of those plug-ins and extensions is simply provided by {CMK} itself as standard.
 
-If you have any MKPs installed, a check of these MKPs is strongly recommended for this reason. 
+If you have any MKPs installed, a check of these MKPs is strongly recommended for this reason.
 This will prevent incompatible packages from interfering with the update, or resulting in duplicate or at least very similar services following the update.
 
-To do this, check your installed MKPs against our link:https://checkmk.com/integrations[Catalog of Check Plug-ins^] and remove any packages containing functions that are now provided natively by {CMK}. 
-You can also use this opportunity to remove MKPs that may have only been installed for a test run. 
-A list can be found in the [.guihint]#Setup# menu under [.guihint]#Maintenance > Extension packages#. 
+To do this, check your installed MKPs against our link:https://checkmk.com/integrations[Catalog of Check Plug-ins^] and remove any packages containing functions that are now provided natively by {CMK}.
+You can also use this opportunity to remove MKPs that may have only been installed for a test run.
+A list can be found in the [.guihint]#Setup# menu under [.guihint]#Maintenance > Extension packages#.
 On the command line, you can display the installed extensions with the `mkp list` command.
 Check the output of this command for extensions that are no longer needed or that you cannot even identify.
 
@@ -99,8 +99,8 @@ During the update, otherwise modified files will be overwritten by those contain
 [#local_files]
 === Local files
 
-Local files allow you to customize and extend the functionality provided by {CMK}. 
-These files are located in the local part of the site directory structure, i.e. in `~/local`. 
+Local files allow you to customize and extend the functionality provided by {CMK}.
+These files are located in the local part of the site directory structure, i.e. in `~/local`.
 Local files can cause problems when updating, as they may no longer match the new {CMK} version.
 
 Since it is not possible for {CMK} to intercept and handle local customizations and any third-party extension during an update, you should check your {CMK} site before an update to see if and which local files you are using.
@@ -124,7 +124,7 @@ Once packaged, each extension can be deactivated or reactivated as a complete el
 [#backup]
 === Backup and test run
 
-We don't need to remind you of the importance of creating a backup immediately before any update, so that you don't risk losing too much of your monitoring history in the event of a failure. 
+We don't need to remind you of the importance of creating a backup immediately before any update, so that you don't risk losing too much of your monitoring history in the event of a failure.
 What is relevant at this point is that a regular backup can also serve you well for test runs of a pending update.
 This practice enables you to restore the backup under an alternative name -- and then use the `newsite` site to test the update before it goes live:
 
@@ -477,7 +477,7 @@ omd -f -V $VERSION update --conflict=install $SITE  && omd start $SITE
 
 There are two different procedures for performing the update of all sites included in a xref:distributed_monitoring#[distributed monitoring] -- i.e. the central site and any remote sites controlled by it.
 
-*Important:* 
+*Important:*
 Whichever approach you choose, as the very first step you should create xref:backup#[backups] of all sites in the environment.
 
 The preferred, safest procedure is to _update in one go_, in which you perform the following steps:
@@ -697,14 +697,24 @@ If you want to upgrade directly from {RE} to {CE}, you must upgrade the central
 
 
 [#down2cee]
-== Downgrades 
+== Downgrades
 
 === Introduction
 
 Downgrades between editions are also possible.
 A downgrade is a more complex and thus time-consuming action, since some features may not work in the target edition,
 and will need to be manually deactivated and replaced by a possibly less efficient or less convenient alternative.
 
+The actual downgrade *must* be carried out with the command `omd update` - just like an update or upgrade.
+The details can be found in the section xref:update#execute[Performing the update].
+
+If you try to downgrade from {CE} to {SE}, for example, {CMK} will verify whether this is actually your intention:
+
+image::update_downgrade_ce_se.png[width=30%]
+
+As soon as you confirm this dialog with [.guihint]#yes#, the downgrade starts immediately.
+Please find out below what you need to do *before* this downgrade.
+
 
 [#cce2cee]
 === Downgrading from the {CE} to the {SE}
@@ -834,7 +844,7 @@ As always, paths that do not begin with `/` apply after the site's home director
 
 [cols="25,~"]
 |===
-|File path |Function 
+|File path |Function
 
 |`~/version` |Symbolic link to the installation of the {CMK} version used by this site.
 |`/omd/versions` |In this directory a subdirectory exists for every installed {CMK} version. The files belonging to `root` and are never changed.