Upgrade auf Milestone 5.1.0.M1 oder auch Debian

[int5749]

Keine Ahnung, was Du genau falsch gemacht hast

Das war leider relativ einfach wenn Linux Rarely User auf so ein Update trifft
Ich hatte schlicht und stumpf die Anleitung von Proxmox abgearbeitet und dabei erst den "enterprise source" gesetzt und als mit bewusst wurde, dass dieser falsch war noch den "no-subscription" und dachte das einer überschreibt das andere Da es spät war, konnte mir der co-Pilot helfen und auf die richtige Spur führen, daher konnte ich dann final doch meine Signatur anpassen.

Derzeit laufen alle LXC un ich baue die neuen parallel auf. Habe sogar noch einen LXC für Influx, SQlite und Mosquitto mit Debian 11.

Anfangen würde ich mit dem LXC für openHab und evcc

ceph ist nur interessant, wenn man ein HA-Cluster aufbauen will und ordentlich zu viel Geld hat, denn man benötigt mindestens drei echte Nodes, die jeweils Plattenplatz zur Verfügung stellen. Dabei werden die Daten mindestens dreimal gespeichert, sprich, es steht nachher auch nur ein Drittel der Plattenkapazität zur Verfügung Cool wenn man HA braucht (High Availability, nicht Home Assistant), weil die Daten dank Ceph automatisch repliziert sind. Der Wechsel eines Containers/VM auf einen anderen Knoten geht deshalb innerhalb Bruchteilen von Sekunden vonstatten. Für das Homelab aber definitiv sehr weit drüber.

Frontail ist gewöhnlich über Port 9001 erreichbar und stellt ein log:tail für die Dateien events.log und openhab.log per http zur Verfügung. Aber wie gesagt, das ist abgekündigt, und openHAB bringt ja nun schon seit längerem einen fast vollständigen Ersatz mit (Main UI->Administration->Entwickler-Tools->Log Viewer) Einzige Einschränkung: der integrierte Log Viewer funktioniert natürlich nur, wenn openHAB grundsätzlich läuft. Das gilt in ähnlicher Form auch für Frontail, so dass man ohnehin wissen muss, wie man die Logdateien "zu Fuß" ausliest.

FireMotD -> Fire Message of the Day, die wird sichtbar, wenn Du Dich als User openhabian per ssh (oder an einem lokalen Terminal) anmeldest. Die Meldung enthält dann die grundlegendsten Daten zum System, Auslastung, Speicher, Anzahl möglicher Updates usw. Wie gesagt, nett, aber nicht kriegsentscheidend.

Ceph ist abgehakt
Frontail dann auch, dann muss ich eben über das Admin Interface gehen oder die Logs manuell aufrufen. Ist ja eh eher selten notwendig
FireMotD war nett, aber die System Performace bekomme ich auch über die Proxmox UI

Vor dem Update und der Neuinstallation habe ich noch ein paar Fehler gefunden, dazu mache ich einen separaten Thread auf.

[int5749]

So, nachdem das semantische Modell keine Fehler mehr aufzeigt, würde ich mit der Migration auf einen neuen LXC beginnen.

Dieser ist schon erstellt und alle Updates durchgeführt.

Wenn ich auf openHabian verzichte und die Repositoy Installation wähle, ändern sich doch auch die Pfade im System?
Kann ich das Backup vor dem einspielen manuell anpassen??
Wäre das clean-cache und reset-ownership nach dem einspielen des Backups oder schon nach der Installation von openHab erforderlich??

Hatte openHabian nicht auch Samba mit installiert und konfiguriert? Oder verwechsle ich das?

Viele Grüße und ein schönes Wochenende

[int5749]

So, vom Ablauf würde ich nun wie folgt vorgehen.

1. Backup von openHab auf altem LCX
2. Sichern der Backup Datei
3. finales Update Debian Trixie
4. Installation openHab über apt (dann sollten die gleichen Verzeichnisse wie bei openHabian genutzt werden
5. Installation und Konfiguration Samba
6. einspielen des Restore

Aber an welcher Stelle sollte ich dann clean-cache und reset-ownership anwenden? Habe ich einen sinnvollen oder notwendigen Schritt vergessen?

Nachtrag: Wenn ich OH von Scratch installiere und da ich derzeit auf einem Milestone Build bin. Dann würde ich ja nun auch ein Milestone (aktuellste Version) installieren und könne das Backup eines älteren MS einspielen?? Oder sollte ich genau meine MS Version installieren, Backup zurückspielen, System einpendeln lassen und dann das Update auf die aktuelle Version machen?

Viele Grüße

[udo1toni]

Grundsätzlich: die openHABian Scripte nutzen apt im Hintergrund. Also nein, die Pfade sollten die gleichen bleiben
Zur Frage des "wann":
clean-cache leert den Cache von openHAB, der über den Neustart des Systems hinaus aufgehoben wird. Folge: Alle Addons werden erneut "installiert" und einige Daten müssen neu in den Cache kopiert werden. Dieser Schritt ist zwingend, wenn man mit einem full-Backup (das beinhaltet den Cache) auf eine andere Version restored, weil die Addons eventuell in einem anderen Namespace liegen müssen oder auch echte Updates erhalten haben.

reset-ownership sorgt dafür, dass alle Dateien und Pfade dem User openhab mit der Gruppe openhab zugeordnet werden (letztlich das gleiche wie ein
chown -R openhab: $OPENHAB_USERDATA $OPENHAB_CONF /var/log/openhab/, wobei openhab-cli hier vielleicht noch andere Dateien einschließt...)
Es kann sein, dass openHAB auch ohne reset-ownership läuft, aber der Befehl schadet nicht und im Zweifel könnten fehlende Rechte zu seltsamem Verhalten führen.

Beide Befehle sind nach einem Restore vor dem nächsten Start von openHAB sinnvoll

Je größer der Versionssprung, desto größer die Unterschiede, die eventuell in der Konfiguration zu richten sind.
Bei einem Update von openHAB wird immer automatisch ein update-script ausgeführt, welches "triviale" Korrekturen vornimmt (nur für Dinge, die über die UI bzw. REST API konfiguriert wurden) Falls Du viel über die UI konfiguriert hast, kann es gut sein, dass Du bei einem inplace Upgrade (also alte Version installieren, Daten einspielen, Update) weniger Dinge von Hand korrigieren musst.
Wenn Du über Textdateien konfigurierst, ist die Reihenfolge egal, da Du eh alle Dinge selbst anpassen musst.

[int5749]

Wieder ein wenig Zeit gefunden das Upgrade zu pushen, da auf dem System noch andere Apps laufen, musste ich erst einmal alles zusammen suchen.

Ich habe nun openHAB clean über APT installiert und stehe nun bei:

If everything went well, you can start openHAB and register it to be automatically executed at system startup.

Sollte ich sinnvollerweise einmal openHAB nackt starten lassen und somit gemäß Anleitung erst einmal:

Code: Alles auswählen

sudo systemctl start openhab.service
sudo systemctl status openhab.service

sudo systemctl daemon-reload
sudo systemctl enable openhab.service

durchführen um das abzuschließen, oder wäre hier bereits ein Restore sinnvoll??

Viele Grüße

[udo1toni]

Das kannst Du halten wie ein Dachdecker Ich habe meine Konfiguration auf einem separaten Dataset liegen, da bietet es sich natürlich an, openHAB einmal zu starten und anschließend einen Snapshot zu machen, damit hat man dann die Möglichkeit, jederzeit zu einem "jungfräulichen" System zurückzukehren.

[int5749]

Backup eingespielt, clean.cache und reset-ownership ausgeführt, openHAB neu gestartet.

Nun und nur noch zur Sicherheit, bevor ich wieder etwas falsch oder verfrüht mache.

Der User und Kennwort für die UI und ggfs. der Token etc. sind nicht im Backup enthalten und müssen neu gesetzt werden??
Über die Karaf komme ich derzeit auch nicht auf die openHAB Instanz.

[udo1toni]

Der User für die UI sollte im Backup enthalten sein, ebenso der User für die Karaf Konsole. Die Token sollten ebenfalls wieder erreichbar sein.

Eventuell musst Du openHAB nochmals neu starten.

User für Samba und GNU/Linux Shell sind unabhängig von openHAB.

[int5749]

So, nach dem ganzen Stress der letzten Wochen und einen externen Schubs habe ich das Thema wieder aufgenommen.
Ich hoffe alle hatten eine besinnliche und entspannte Weihnachtszeit, morgen ist das Jahr schon wieder rum.

Nachdem ich das Backup in der neuen OH Installation eingespielt habe, werde ich beim Zugriff auf's WebInterface immer noch aufgefordert einen neuen Admin User anzulegen :/ Ich habe sowohl OH wie auch das System neu gestartet und auch das Backup noch einmal eingespielt.

Bevor ich nun etwas falsch konfiguriere, noch einmal der Ruf nach Unterstützung. Beim Backup kann man ja keine Parameter angeben, das nur ein Teil ins Backup kommt?

Ich habe dann einfach mal einen User erstellt um mich anzumelden und siehe da: das Backup wurde scheinbar nicht wieder hergestellt :/ denn es sind keine Items/Things, einfach nichts da

Nach dem Log sollte das Backup aber eingespielt sein. Auch das Ursprungssystem ist OH5

int5749@Skynet:~$ sudo $OPENHAB_RUNTIME/bin/restore /tmp openhab-backup-25_11_20-07_25_34.zip

##########################################
openHAB restore script
##########################################

Using '/etc/openhab' as conf folder...
Using '/var/lib/openhab' as userdata folder...
Making Temporary Directory
Extracting zip file to temporary folder.

Backup Information:
-------------------
Backup Version | 5.1.0.M2 (You are on 5.1.0.M2)
Backup Timestamp | 25_11_20-08_02_36
Config belongs to user | openhab
from group | openhab

Your current configuration will become owned by openhab:openhab.

Any existing files with the same name will be replaced.
Any file without a replacement will be deleted.

Okay to Continue? [y/N]: y
Moving system files in userdata to temporary folder
Deleting old userdata folder...
Restoring system files in userdata...
Deleting old conf folder...
Restoring openHAB with backup configuration...
Deleting temporary files...
Backup successfully restored!

int5749@Skynet:~$ openhab-cli clean-cache

This command will delete the temporary files within openHAB.
May resolve issues with addon installation and configuration.

This option needs to run as root! (e.g. use 'sudo openhab-cli clean-cache')

int5749@Skynet:~$ sudo openhab-cli clean-cache

This command will delete the temporary files within openHAB.

[udo1toni]

Warum nutzt Du nicht openhab-cli zum restore?
Was soll /tmp innerhalb des Aufrufs?

Normalerweise wäre der Weg, das Backup manuell einzuspielen:

Code: Alles auswählen

sudo openhab-cli restore openhab-backup-25_11_20-07_25_34.zip

(gegeben, dass die Datei openhab-backup-25_11_20-07_25_34.zip im aktuellen Verzeichnis liegen).