Dateisystemfehler auf Appliance / Möglichkeiten Recovery

[rapha]

Hallo,

mir ist nach einer automatischen Sicherung der pascom 19.02 VM ein Modulabsturz (ext4) im Kernel der pascom aufgefallen. Das Dateisystem auf / ist auch beschädigt.

Meine Frage dazu:
Genügt es die pascom in einer neuen VM zu installieren und die letzte Sicherung aus dem Phone-System (*.csb) nach der Ersteinrichtung wiederherzustellen?

Die VM bzw. Ersteinrichtung würde ich genau wie das (vmtl. defekte) Original erstellen/durchlaufen.
Es sind benutzerdefinierte Ansagen auf dem System vorhanden, keine Faxe oder Voicemails.

#instance> /var/log/kern.log

#fsck.ext4 /dev/sda1 -nf

Gruß,
Rapha

[rapha]

Nachtrag: Kann ich die 19.03 einrichten und das Backup (csb) von der 19.02 direkt einspielen?
Werde dies am Wochenende mal so machen.

Aktuell steht auf der Console der Instanz Waiting for execution (6), ein Backup über das Management-Interface schlägt auch fehl.
Ich fürchte einen Neustart verkraftet die Anlage nicht , von einem Update ganz zu schweigen.

{
  "url": "https://pbx01.domain.com:8443/api/v1/jobs/9572/",
  "id": 9572,
  "uuid": "89b5dbd3-cc20-4bde-9bd1-14cfd4b32c58",
  "module": "container",
  "taskname": "backup",
  "state": "done",
  "task_data": {
    "container": "pbx01",
    "target_filepath": "/persistent/controller/backups/pbx01/1580373515-pbx01.csb"
  },
  "created": "2020-01-30T08:38:35.329638Z",
  "started": "2020-01-30T08:38:36Z",
  "status_tmstmp": null,
  "status_msg": "",
  "updated": "2020-01-30T09:28:39.174886Z",
  "status_data": {},
  "result_tmstmp": "2020-01-30T09:28:39Z",
  "result_bool": false,
  "result_msg": "Exception:Container pbx01hook backup.sh failed\n\n\n",
  "result_data": {},
  "host": null,
  "container_id": 42,
  "file": null
}

Gruß,
Rapha

[rapha]

Aktueller Stand: Die alte VM ist hinüber, bootet nicht mehr.

Die neue VM läuft soweit, das Backup konnte erfolgreich geladen werden. Es wird das Appliance-Zertifikat nicht wiederhergestellt (Self-Signed), daher mussten alle Telefone erst dem neuen Zertifikat vertrauen (manuelle Einstellung).

Gruß,
Rapha

[Steve]

Hallo @rapha ,

entschuldige die späte Rückmeldung.
Im csb Backup sind die Ansagen und alles was in der Instanz konfiguriert ist enthalten, nicht enthalten sind die Einstellungen der Interfacecontainer im Management, das betrifft deren Zertifikate und den provisionierungsschlüssel. Letzterer lässt sich über über das WebUI rauskopieren (damit die sicheren ProvisionierungsURLs der Endgeräte weiterhin gültig sind), die Zertifikate mit Privatekey müsste man per SSH aus dem Interfacecontainer ziehen, würde aber eher let’s encrypt oder selbst hochgeladenes Zertifkat (gekauft oder intern vom AD signiert) empfehlen.

Grüße,
Steve

[rapha]

@Steve

entschuldige die späte Rückmeldung.

Alles gut, schnellere Rückmeldungen kann ich im Forum nicht erwarten (habe schon deutlich längere Antwortzeiten in anderen Foren erlebt ). Hier wird sich gekümmert, Danke!

@Steve

würde aber eher let’s encrypt oder selbst hochgeladenes Zertifkat (gekauft oder intern vom AD signiert) empfehlen

Intern Let’s Encrypt nutzen:
Die internen Telefone (eigentlich nur Snom, Grandstream hat mit dem Zertifikat kein Problem) haben keine direkte Internetverbindung, das CN=DST Root CA X3,O=Digital Signature Trust Co. (Let’s Encrypt Root-CA) ist vorhanden aber nur bis 2021 gültig. Dann hätte ich spätestens nach Ablauf der Gültigkeit ein Problem. Hier also besser ein AD-signed Zertifikat zu verwenden.

Extern habe ich auf Let’s Encrypt umgestellt; Dabei konnte ich den FQDN des Interfaces allerdings nicht nachträglich ändern. Laut certmanager-Log wurde immer mit dem “alten” FQDN bei Let’s Encrypt registriert.

Gruß,
Rapha

[pro345]

@rapha

Die internen Telefone (eigentlich nur Snom, Grandstream hat mit dem Zertifikat kein Problem) haben keine direkte Internetverbindung, das CN=DST Root CA X3,O=Digital Signature Trust Co. (Let’s Encrypt Root-CA) ist vorhanden aber nur bis 2021 gültig. Dann hätte ich spätestens nach Ablauf der Gültigkeit ein Problem. Hier also besser ein AD-signed Zertifikat zu verwenden.

Hm, wahrscheinlich (zumindest wäre es mMn erwartbar) haben zukünftige Snom Firmware-Versionen dann aber schon neuere LE Root Certs integriert, sodass man dieses Problem wahrscheinlich mit Aktualisierung der Firmware lösen kann.
Und bei einem Cert von einer internen CA wie z.B. MS (AD) CA müsste man dann ja auch das dortige Root Cert auf alle Tischtelefone ausrollen.

just my 2 cents,
Robert

[rapha]

@pro345

Und bei einem Cert von einer internen CA wie z.B. MS (AD) CA müsste man dann ja auch das dortige Root Cert auf alle Tischtelefone ausrollen.

Korrekt, das könnte aber die Provisionierung übernehmen, siehe Snom Wiki.
Turnunsmäßig (~30 Tage vor Ablauf) müssen die CA-Certs ja sowieso erneutert bzw. getauscht werden.

https://service.snom.com/display/wiki/TLS+Support#TLSSupport-UploadingServerCertificatesviaProvisioning

Gruß,
Rapha

[Steve]

Über die XML Provisionierung können Zertifikate mitgegeben werden.