openhabforum.de

Hallo,
ich arbeite mit einem Raspberry 3B und openHABian. Das Upgrade von OH 2.5.10 auf OH 3 schlägt fehl. Nun habe ich ein frisches OH 2.5.12 installiert (Image File mit Etcher auf die SD Karte). Mein Plan ist, ein Backup, das ich mit OH 2.5.10 im openHABian Configuration Tool openhabian-config erzeugt und mittels Samba auf den PC kopieren konnte, nun in mein frisches OH 2.5.12 einzuspielen und dann über openhabian-config das Upgrade auf OH 3 durchzuführen.
Ich bin soweit gekommen, dass ich Samba im OH 2.5.12 über openhabian-config aktiviert habe und die Verzeichnisse auf dem Windows 11 File Explorer sehe. Die Backups werden wohl in \\openhabian.local\openHAB-userdata\backups abgelegt. Leider kann ich mein OH 2.5.10 Backupfile nicht nach \\openhabian.local\openHAB-userdata\backups kopieren. Es kommt folgende Fehlermeldung: "Zugriff auf den Zielordner wurde verweigert. Sie benötigen Berechtigungen zur Durchführung des Vorgangs."
Die andere Richtung funktioniert übrigens. Ein in OH 2.5.12 erzeugtes Backup konnte ich auf meinen Windows 11 PC kopieren.
Ich bin ratlos und vor allem völlig hilflos in Linux. Würde mich über Ratschläge und Hilfestellung freuen.
Gruß
Andreas

Es ist einfach so, dass der verwendete User keine Schreibrechte für das Verzeichnis hat (und das ist auch beabsichtigt). Du musst die Backup-Datei nicht in dem selben Ordner ablegen, in dem das Backup erzeugt wird, sondern nur "irgendwo" auf dem Zielsystem. Gewöhnlich wird man dafür das home-Verzeichnis des Users verwenden, der das Backup wieder einspielt.
Mutmaßlich musst Du das Backup mit dem root-User einspielen, dann läuft das Ganze in mehreren Schritten ab:
Schritt 0: Du beendest openHAB
Schritt 1: Du kopierst die Datei "irgendwohin", halt ein Verzeichnis, auf das Du Schreibrechte hast. Notfalls openhab-conf oder so...
Schritt 2: Du verschiebst die Datei mit root-Rechten in den Ordner /root/ (das ist das home-Verzeichnis von root).
Schritt 3: Du spielst das Backup mit sudo openhab-cli restore /root/<dateiname> ein.
Schritt 4: Du führst sudo openhab-cli reset-ownership aus, um die durcheinandergeratenen Berechtigungen zu korrigieren.
Schritt 5: Du startest openHAB.

Super vielen Dank für die schnelle Antwort. Es ist nur leider so, dass ich tatsächlich völlig hilflos in Linux bin. Mein Problem starten bei Schritt 0. Wie beende ich openHAB? In Situationen wie dieser ziehe ich immer meine Din A4 Unix/Linux Command Reference zu Rate. Die Lösung liegt wahrscheinlich im Befehl kill. Doch kill wen? Befehl ps zeigt mir nur zwei laufende Prozesse, bash und ps.
Schritt 1 hat scheinbar funktioniert.
Für Schritt 2 kommt dann wohl der Befehl mv zum Einsatz. Wegen root-Rechten evtl. sudo mv?
Schritt 3 und 4 sind mal Anweisungen mit der ich arbeiten kann.
Bei Schritt 5 wird es wieder schwierig. Wie starte ich openHAB? Ich würde einfach sudo reboot eingeben, aber wahrscheinlich geht das auch eleganter.

Nein, kill ist zum Abschießen eines (nicht mehr kontrollierbaren) Prozesses da.

Du musst lediglich den Dienst beenden (openHAB ist ein Dienst, der auf dem System läuft).
Der passende Befehl: alternativ sollte auch funktionieren, aber die erste Schreibweise ist die "bessere" Variante.

Dienste sind Programme, die gestartet werden, ohne dass dazu ein Benutzer auf dem System angemeldet sein muss oder aktiv ein Programm aufrufen muss.

sudo ist ein Befehl, um einen einzelnen Befehl unter einem anderen Benutzer Kontext auszuführen. Man kann sich das mit "SpecialUser DO" merken. Mit einem Parameter -u könnte man angeben, welcher User verwendet werden soll, lässt man den Parameter weg, wird root verwendet (und das ist auch die weit überwiegende Verwendung von sudo, man möchte ein Programm ausführen, welches erweiterte Rechte benötigt)
sudo fragt beim ersten Aufruf (und danach, wenn ein Zeitraum x seit dem letzten Aufruf vergangen ist) nach dem Passwort des angemeldeten Users. Darf der User kein sudo verwenden, so hat er auch keine Möglichkeit dazu.
Im Unterschied dazu könnte man mit su - auch in den root-User Kontext wechseln. Dazu muss man dann aber das root-Passwort eingeben, nicht das des angemeldeten Users. Außerdem gelten die erweiterten Rechte dann für die geöffnete Shell, also für alle Befehle, die ausgeführt werden. Das ist gewöhnlich nicht erwünscht, höchstens, wenn man ein System einrichtet und ständig sudo verwenden müsste...

systemctl gehört zu systemd, das ist der Teil, der sich darum kümmert, alle Prozesse im OS zu verwalten. systemd kümmert sich also darum, das Betriebssystem zu starten, alle Dienste, die benötigt werden usw. systemctl kann man sich mit SystemControl merken. Es gibt verschiede Optionen, was ich mit einem Dienst machen möchte, das wären start, stop, restart, enable, disable und status. Die Optionen sind weitgehend sprechend enable und disable beziehen sich allerdings nur auf den automatischen Start. Ich kann also durchaus einen Dienst starten, der disabled ist. Er wird dann lediglich beim Reboot des Rechners nicht automatisch mit gestartet.
Jeder Dienst (engl. service) braucht eine Datei, in der drin steht, wie der Dienst gestartet und gestoppt werden kann, welche Parameter zu verwenden sind usw. Diese Dateien liegen an unterschiedlichen Stellen im System. systemctl weiß aber, wo es nachschauen muss.
Wenn man sudo systemctl enable irgendein.service aufruft, wird im Hintergrund ein Softlink auf die "echte" irgendein.service Datei angelegt, z.B. in einem Ordner /etc/systemd/system/multiuser.target.wants/. Es gibt noch weitere Ordner, die für bestimmte Stellen im Start- und Stop-Prozess des Betriebssystems stehen. Wo der betreffende Link angelegt wird, steht ebenfalls in der .service Datei. Bei disable wird der Softlink gelöscht. Das Ganze könnte man also notfalls auch per Hand erledigen...

Vielen Dank für die tolle Erklärung. Ich musste noch eine kleine Hürde mit einer fehlenden "2" nehmen, aber dann hat es geklappt. Ich konnte wie gewünscht mein Backup, das ich mit OH 2.5.10 erstellt hatte in des frisch installierte OH 2.5.12 einspielen. Falls es noch jemanden geben sollte, der sich wie ich in Linux schwer tut, liste ich hier die exakten Befehle, die bei mit zum Ziel geführt haben.

Schritt 0: sudo systemctl stop openhab2.service
Schritt 1: Mit dem Windows File Explorer nach \\openhabian.local\openHAB-conf kopieren
Schritt 2: cd /etc/openhab2
sudo cp openhab2-backup-23_01_30-09_28_30.zip /root/
Schritt 3: sudo openhab-cli restore /root/openhab2-backup-23_01_30-09_28_30.zip
Schritt 4: sudo openhab-cli reset-ownership
Schritt 5: sudo systemctl start openhab2

Danach habe ich noch in openhabian-conf die Settings für den Betrieb meines RaZberry-Moduls durchgeführt (30 System Settings -> 35 Serial port -> beide Einträge angewählt) und mein kleines Smart Home läuft wieder, soweit ich das nach zwei Stunden Testphase beurteilen kann.

Techniker hat geschrieben: ↑2. Feb 2023 20:43 Ich musste noch eine kleine Hürde mit einer fehlenden "2" nehmen

Ja, ich war natürlich gedanklich schon bei openHAB3...

Als kleiner Trost: ab openHAB3 bleibt es beim einfachen openhab an den verschiedenen Stellen, also Verzeichnisnamen, Dienste, Pakete usw.
Beim Übergang von openHAB1 auf openHAB2 hielt man es für eine gute Idee, die Nummer anzuhängen (was sich schnell als Irrtum herausgestellt hat)