Probleme & Fixes¶

Diese Seite sammelt die häufigsten Betriebsprobleme und wie du sie selbst löst. Jeder Eintrag folgt dem Muster Symptom → Ursache → Lösung. Die Lösungsschritte führst du per SSH als root (bzw. mit sudo) direkt auf dem betroffenen Server aus.

Updates laufen normalerweise von selbst

Der Server aktualisiert Panel + Agent eigenständig aus seinem Release-Kanal (unattended-upgrades, meist nachts). Die Fixes hier brauchst du nur, wenn ein Update klemmt oder du es sofort erzwingen willst.

Panel-Update bleibt auf der alten Version hängen¶

Symptom: Unter System → Update wird ein Update gestartet, aber nach dem Neuladen steht weiterhin die alte Version. Der „Update"-Knopf tut scheinbar nichts, ein Fehler wird nicht angezeigt.

Ursache: Ein Drittanbieter-Repository (typisch: der MariaDB-Paketspiegel) macht Probleme — auf zwei Arten, beide mit demselben Symptom:

Variante A — geänderte Metadaten: Das Repo hat seinen Origin- oder Label-Wert geändert:

E: Repository '.../mariadb/... trixie InRelease' changed its 'Origin' value from 'MariaDB' to 'debian trixie'

Variante B — Repo komplett nicht erreichbar: Der Mirror liefert für seine eigene Release-Datei einen echten 404 (z. B. bei einer MariaDB-Infrastrukturstörung):
```
E: The repository 'https://deb.mariadb.org/11.8/debian trixie Release' no longer has a Release file.
```

(beide Meldungen können in der Server-Sprache lokalisiert erscheinen, z. B. „… wurde der »Origin«-Wert … geändert" bzw. „… enthält keine Release-Datei mehr"). In älteren Panel-Versionen (< v2.8.53) läuft das Panel-Update-Skript unter set -e und steigt bei jeder Art von Repo-Fehler vor der eigentlichen Installation aus — obwohl unser eigenes Repo (git.netcell-it.de) einwandfrei erreichbar ist. Es wird nichts installiert, das Panel bleibt auf der alten Version.

Ab v2.8.53 automatisch geheilt

Ab Panel-Version v2.8.53 blockiert kein einzelnes Drittanbieter-Repo mehr das ganze Update — weder Variante A noch B. Zusätzlich legen aktuelle Panel-Versionen beim Start automatisch eine apt-Konfiguration an (/etc/apt/apt.conf.d/54enconf-releaseinfo), die Variante A grundsätzlich toleriert (Paketsignaturen werden weiterhin geprüft). Den manuellen Fix unten brauchst du nur einmalig, falls der Server noch auf einer Version vor v2.8.53 festhängt — danach ist er dauerhaft immun (auch gegen künftige Repo-Ausfälle wie Variante B).

Sonderfall: MariaDB-Vendor-Repo komplett tot (Variante B)

Fällt speziell deb.mariadb.org komplett aus (Variante B), betrifft das nicht nur Panel-Updates, sondern auch die Installation von mariadb-server selbst — dieses Paket ist per apt-Pin (Pin-Priority: 1001) auf den Vendor bevorzugt, aber nicht exklusiv festgelegt. Solange der Vendor-Mirror keine Paketdaten liefert, greift automatisch Debians eigenes mariadb-server aus dem main-Repo als Fallback (aktuell z. B. 11.8.6 statt der Vendor-Version 11.8.9 — funktional gleichwertig, nur ein paar Patch-Releases älter). Kein manueller Eingriff nötig; sobald der Vendor-Mirror wieder erreichbar ist, zieht die nächste Aktualisierung automatisch wieder die neuere Vendor-Version.

Lösung (SSH als root auf dem Server):

Prüfen, welche Variante vorliegt:

apt-get update
# Variante A: E: Repository '...' changed its 'Origin' value from '...' to '...'
# Variante B: E: The repository '...' no longer has a Release file.

Paketindex aktualisieren — bei Variante A hilft --allow-releaseinfo-change, bei Variante B (Repo tot) bringt das nichts, ist aber unschädlich; in beiden Fällen reicht es, den Fehler zu ignorieren und direkt weiterzumachen:
```
apt-get update --allow-releaseinfo-change || true
```
Panel + Agent aktualisieren — bestehende Konfigurationen bleiben erhalten. Das funktioniert auch dann, wenn Schritt 2 einen Fehler gemeldet hat: apt nutzt für unser eigenes Repo den zuletzt erfolgreich geladenen Paketindex.
```
apt-get install -y --only-upgrade \
  -o Dpkg::Options::=--force-confold \
  enconf-agent enconf-webpanel
```

Version kontrollieren:

dpkg-query -W -f='${Package} ${Version}\n' enconf-agent enconf-webpanel

Nichtstun ist auch eine Option — mit Einschränkung

Ab v2.8.53 sind die automatischen Nacht-Updates von beiden Repo-Fehlervarianten nicht mehr betroffen: der Fehler eines einzelnen Repositorys blockiert die anderen nicht. Solange dein Server aber noch auf einer älteren Version festhängt, kann auch unattended-upgrades an Variante B (komplett totes Repo) scheitern — dann hilft nur der einmalige manuelle Fix oben, um den Server überhaupt erst auf v2.8.53+ zu heben.

„apt" ist in einem kaputten Zustand¶

Symptom: Updates schlagen mit Meldungen über halb-konfigurierte Pakete oder unerfüllte Abhängigkeiten fehl, oder das Panel-Update dreht in einer Wiederholungsschleife („Verifizierung wiederholt sich").

Ursache: Ein unterbrochener oder halber apt-Lauf (z. B. ein abgebrochener unattended-upgrade) hat Pakete auf gemischten Versionen hinterlassen. Der enconf-Paket-Install kann dann nicht durchlaufen.

Lösung (SSH als root):

dpkg --configure -a
apt-get install -f -y
apt-get update --allow-releaseinfo-change
apt-get install -y --only-upgrade \
  -o Dpkg::Options::=--force-confold \
  enconf-agent enconf-webpanel

Weiter kommen: Logs & Support¶

Bringt ein Fix nicht den erwarteten Erfolg, liefern diese Logs die entscheidenden Hinweise:

# Panel- und Agent-Dienst
journalctl -u enconf-api  -n 100 --no-pager
journalctl -u enconf-agent -n 100 --no-pager

# Letzter automatischer/manueller Update-Lauf
journalctl -u enconf-upgrade.service -n 60 --no-pager
tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

Kommst du nicht weiter, schicke die Ausgabe der obigen Befehle an support@netcell-it.de — damit lässt sich die Ursache in aller Regel eindeutig einordnen.