Ups, wieso geht der jetzt auf DIE Version? XWiki-Admin am Abgrund!

XWiki-Admin am Abgrund!

XWiki unter Debian: kontrolliertes LTS-Versionsmanagement mit APT Pinning

XWiki bietet mit seinen LTS-Versionen eine sehr stabile Grundlage für produktive Installationen. Unter Debian lässt sich das sehr elegant mit APT Pinning lösen. Damit kann man exakt festlegen, welche Version installiert werden darf und wann ein Upgrade erfolgt. Allerdings gibt es dabei einen wichtigen Fallstrick, der insbesondere beim Wechsel zwischen zwei LTS-Generationen auftreten kann.

Dieser Artikel zeigt eine in der Praxis bewährte Vorgehensweise.

Problemstellung: Ungewollte automatische Updates vermeiden

Standardmäßig verhält sich APT relativ einfach:

  • Neue Version im Repository verfügbar → Upgrade wird angeboten
  • Bei apt upgrade wird sie installiert
    Für viele Server ist das in Ordnung. Bei geschäftskritischen Anwendungen wie XWiki möchte man jedoch meist:
  • Bugfix-Versionen erst nach Tests installieren
  • Updates zeitlich kontrollieren
  • Major-Upgrades bewusst planen

Typisches Beispiel:

17.10.3 -> 17.10.4

Das ist ein normales LTS-Bugfix-Update. Trotzdem möchte man möglicherweise erst upgraden, wenn interne Tests abgeschlossen sind.

Lösung: APT Pinning

APT Pinning erlaubt es, eine konkrete Version festzulegen, die installiert werden darf.

Beispiel für ein Pinning auf XWiki 17.10.4:
/etc/apt/preferences.d/00-local-xwiki.pref:

Package: xwiki*
Pin: version 17.10.4
Pin-Priority: 1200

Die hohe Priorität sorgt dafür, dass genau diese Version installiert wird, selbst wenn neuere Versionen im Repository vorhanden sind.
Damit lässt sich das Upgrade exakt steuern:

  1. Neue Version erscheint (z. B. 17.10.5)
  2. Administrator testet Upgrade
  3. Pin wird angepasst
  4. Upgrade erfolgt gezielt

Wichtiger Fallstrick: Das falsche Repository

Viele Administratoren verwenden für LTS-Systeme das XWiki LTS Repository.
Das klingt zunächst logisch, kann aber beim Wechsel zwischen zwei LTS-Generationen problematisch werden.

Beispiel:

16.10.x -> 17.10.x

Wenn eine neue LTS erscheint, kann es passieren, dass es zwar noch weitere Updates für die ältere LTS-Version gibt, diese aber nie in das LTS-Repository aufgenommen werden.

In diesem Fall passiert Folgendes:

  1. System verwendet noch z.B. 16.10.15
  2. Version 17.10.3 wurde zur neuen LTS-Version erklärt
  3. ein Bugfix- oder Sicherheits-Update 16.10.16 wird veröffentlicht und soll installiert werden
  4. Pinning wird dazu auf 16.10.16 gesetzt
  5. Aber: Diese Version existiert nicht im LTS-Repo, da 17.10.x das aktuelle LTS ist!
  6. Folge: APT ignoriert das Pinning
  7. APT installiert automatisch die aktuelle 17.10.3

Damit passiert ungeplant ein Major-Upgrade.
Gerade bei produktiven Wikis ist das natürlich unerwünscht.

Die bessere Lösung: Stable Repository verwenden

Statt des LTS-Repositories empfiehlt es sich, das Stable Repository zu verwenden.

Beispiel:
/etc/apt/sources.list.d/local-xwiki.list:

deb [signed-by=/usr/share/keyrings/xwiki-keyring.gpg] http://maven.xwiki.org stable/

Der Vorteil:
Das Stable-Repository enthält alle stabilen Versionen, auch von früheren LTS-Versionen.
Damit bleibt das Pinning funktionsfähig, selbst wenn bereits eine neue LTS-Version erschienen ist.

Das bedeutet:

  • keine unerwarteten Major-Upgrades
  • volle Kontrolle über den Update-Zeitpunkt
  • reproduzierbares Upgrade-Verhalten

Empfohlener Workflow für LTS-Systeme

Ein bewährtes Vorgehen sieht so aus:

1. Stable Repository verwenden

deb [signed-by=/usr/share/keyrings/xwiki-keyring.gpg] http://maven.xwiki.org stable/

2. Version pinnen

Package: xwiki*
Pin: version 17.10.4
Pin-Priority: 1200

3. Neue Version testen
Beispielsweise auf einem Staging-System.

4. Pin anpassen

Pin: version 17.10.5

5. Paketlisten aktualisieren
Damit APT die aktuell verfügbaren Versionen kennt:

apt update

6. Gegencheck mit apt-cache policy
Vor dem Upgrade sollte überprüft werden, welche Version APT tatsächlich installieren würde:

apt-cache policy xwiki-common

Beispielausgabe:

xwiki-common:
   Installed: 17.10.4
   Candidate: 17.10.5
   Version table:
  *** 17.10.4 100
      17.10.5 1200
        500 http://maven.xwiki.org stable/ Packages

Wichtig ist dabei:

  • Installed zeigt die aktuell installierte Version
  • Candidate zeigt die Version, die APT installieren würde
  • Die Pin-Priority bestätigt, dass das Pinning aktiv ist
    Wenn hier die erwartete Version als Candidate angezeigt wird, greift das Pinning korrekt.

7. Upgrade durchführen

apt upgrade

Damit erfolgt das Update bewusst und kontrolliert.

Unsere Empfehlungen in Kürze:

APT Pinning ist ein sehr effektives Werkzeug für das Versionsmanagement von XWiki unter Debian. Es ermöglicht:

  • kontrollierte Updates
  • reproduzierbare Systemzustände
  • planbare Wartungsfenster
    Wichtig ist jedoch, das richtige Repository zu wählen. Mit dem Stable Repository bleibt das Pinning auch dann zuverlässig wirksam, wenn bereits eine neue LTS-Generation veröffentlicht wurde. Gerade bei produktiven Wissenssystemen verhindert das unangenehme Überraschungen.

Vielen Dank fürs Lesen und bleib dran für weitere Tipps und Artikel!

Das könnte Sie ebenfalls interessieren

XWiki-17.10-LTS-Upgrade - was kann da schon schiefgehen?
Der Wechsel von XWiki 16.10.x auf 17.10.x ist im Allgemeinen ein gut unterstützter Upgrade-Pfad, doch in der Praxis sind wir auf einige Schwierigkeiten …
XWiki- und Softwareentwicklungs-Projekte
In den vergangenen Monaten konnten wir spannende XWiki-Projekte umsetzen – von individuellen Macros bis hin zu komplexen Fachanwendungen.
Bei Fragen stehe ich Ihnen gerne zur Verfügung.
Gunter Ohrner

Inhaber/Geschäftsführender Gesellschafter

+49 7031 – 20 29 29 0 +49 7031 – 20 29 29 99 info@ohrner-it.com

Ohrner IT GmbH
Otto-Lilienthal-Straße 36 71034 Böblingen

Kontakt

Sie wollen eine Software entwickeln lassen? Dann sind Sie bei uns richtig! Wir freuen uns auf Ihre Anfrage.

Profitieren Sie von unseren individuellen Leistungen und füllen Sie unser Kontaktformular aus.

* Pflichtfelder