Kokosnuss hat geschrieben: ↑25. Feb 2025 09:59
Kannst du mir vielleicht die Vorteile deiner VS Code Remote Variante gegenüber dem auslagern der Config nennen?
Keine Ahnung, ob das überhaupt ein Vorteil ist
Ich beschreibe mal mein Setup:
1. Proxmox Host mit ZFS
Auf dem Host gibt es diverse Datasets, unter anderem eines mit den Konfigurationen aller openHAB Instanzen (momentan Produktiv, Test OH5, Test OH4, Test OH-2.5). Jede Instanz hat ein eigenes Verzeichnis, in dem sich jeweils conf, userdata und addons finden lassen. Diese sind über MountPoints in den jeweiligen Containern eingehängt.
2. openHAB Instanz (egal, ob nun mit openHABian oder direkt mit apt installiert - letztlich ruft openHABian auch nur apt auf)
Das System basiert bei mir immer auf dem letzten debian Container, der über Proxmox direkt verfügbar ist. Ich erzeuge zunächst den unprivilegierten Container, gewöhnlich mit 3 GB RAM und 4 Kernen sowie 8 GB Storage (die eigentlichen Daten landen ja auf einem separaten Dataset), dabei trage ich direkt den Public Key für den User root ein.
Anschließend fahre ich den Container hoch, logge mich ein und starte
apt update && apt -y full-upgrade && apt -y install htop sudo, wenn ich openHABian verwenden will packe ich auch gleich noch git mit drauf, aber bei der letzten Installation habe ich darauf verzichtet, die "interessanten" Sachen (für
mich interessant) sind jetzt alle weg oder werden nicht mehr weiter gepflegt (FireMOTD und frontail - Letzteres ist inzwischen aber eh nicht mehr so wichtig). mit
dpkg-reconfigure tzdata und
... locales passe ich Zeit und Lokalisierung an und richte noch einen Administrationsuser ein, der sudo ausführen darf und den normalen Remote Zugriff per Private Key hat.
Bis zu diesem Punkt ist der Container ein Standard Container, diese Schritte führe ich bei ausnahmslos allen Containern durch (also bis auf die MountPoints für die Konfiguration natürlich).
Dann installiere ich openHAB (über apt oder openHABian, wie in der offiziellen Doku beschrieben). Da ich die Standard Pfade für die drei gemappten Verzeichnisse kenne
landet der essenzielle Teil dank der MountPoints direkt auf dem eigenen Dataset.
Nach der Installation stoppe ich openHAB und passe ein paar Dinge an, insbesondere prüfe ich UID und GID des Users openhab, denn ich möchte, dass die Dateien auf dem Dataset alle mit gleicher GID/UID angelegt werden. Notfalls ändere ich die IDs ab und passe die Besitzrechte an.
Weiters prüfe ich, dass das Verzeichnis
$OPENHAB_USERDATA (das entspricht dem home-Verzeichnis des Users openhab) für Gruppe und andere lediglich lesbar, aber nicht schreibbar ist. Anschließend erzeuge ich ein Verzeichnis
.ssh in diesem Ordner und kopiere den Public Key von openhab in die Datei
authorized_keys. Das Verzeichnis sichere ich mit
chmod 700, die enthaltenen Dateien bekommen
600.
Außerdem passe ich in
/etc/passwd die Standard Shell für den User openhab an (
bin/bash)
Danach muss ich in VSCode nur noch die Verbindungsdaten für den neuen Host eintragen (
%USERDATA%\.ssh\config), also den Verbindungsnamen, den Hostname, den User und den Private Key
Nun wähle ich in VSCode im Remote Plugin "Verbindung mit Remote Host herstellen...") aus, in der Liste taucht der soeben eingefügte Eintrag auf. Wie üblich muss ich dann die Echtheit des Remote Host bestätigen und einmalig mein Passwort zum Entschlüsseln des Private Key eingeben. Danach rödelt VSCode etwas (die Remote Instanz wird eingerichtet) und abschließend definiere ich einen Arbeitsbereich. Dieser Arbeitsbereich ist allerdings auf dem openHAB System gespeichert, ich kann diesen also von jedem Rechner aus öffnen, mit dem ich mich per VSCode anmelde.
Im Arbeitsbereich öffne ich die drei Ordner
/etc/openhab/,
/var/lib/openhab/ und
/var/log/openhab/, und an dieser Stelle kommt leider eine Unschönheit zutage, VSCode zeigt nämlich einfach den Namen des Nachkommen an, ich habe also drei Ordner mit identischem Namen
openhab aber man gewöhnt sich daran...
Das Ganze klingt vermutlich aufwändig, ist es aber nicht (spätestens beim zweiten oder dritten Mal).
Der für mich wichtigste Vorteil: Die Dateien gehören dem User openhab, nicht einem User openhabian. Der Zugriff erfolgt ausschließlich über ssh per Private Key, da der User openhab kein Passwort hat, kann man sich nicht mittels Passwort authentifizieren (und das sollte auch so bleiben - aus Gründen...)
Ich benötige kein Samba und muss auf dem Desktop auch keine Freigabe einrichten. Das Dataset habe ich bei mir dennoch per Samba verfügbar, aber eben nicht aus dem openHAB System heraus, sondern von meinem NAS Container. Dort kann ich lediglich lesend auf die Dateien zugreifen, weil ich nicht als User openhab angemeldet bin - für mich ein Plus.
Ich hinterlege außerdem noch einen anderen Public Key in der Datei
$OPENHAB_USERDATA/etc/keys.properties. Diese funktioniert genau wie die
users.properties, mit dem Unterschied, dass man hier eben einen RSA Schlüssel angibt, statt eines Passwortes. In der
users.properties lege ich noch den User openhab lahm - wenn ich auf die Karaf Konsole zugreife, dann per ssh mittels Private Key.
VSCode installiert die Plugins übrigens auf dem Remote Host, d.h. die Plugins sind ebenfalls auf jeder VSCode Instanz "einfach da", wenn ich remote arbeite, egal ob vom heimischen Schreibtisch, per Laptop oder auch über eine extra VM, die ich dank Guacamole über ein VPN ansteuern kann, egal von wo, selbst vom Dienst-Rechner (wobei wir so etwas qua Dienstvereinbarung "dürfen" - die Rechner sind gut gesichert...)
Meine dringende Empfehlung ist tatsächlich, ein eigenes Dataset für die Konfigurationsdaten anzulegen.
Falls Du kein ZFS nutzt, kannst Du das auch konventionell z.B. über lvm erreichen. Die Daten liegen so direkt in "konzentrierter Form" vor, Du musst lediglich das Dataset sichern, um ein vollständiges Backup zu haben. Über zfs geht das bequem per zfs autosnapshot, für lvm wäre mein Tipp rsync in Verbindung mit rsnapshot, welches ähnliche Funktionen zur Verfügung stellt. Ich repliziere täglich alle Datasets auf ein separates System (leider steht dies im Gestell direkt neben dem Hauptsystem, upsi...), zumindest vor normalen Schäden bin ich geschützt. (die Snapshots werden per zfs send übertragen, d.h. es werden nur die Änderungen zum letzten übertragenen Snapshot gesendet, das geht trotz mehrerer TB Datenbestand innerhalb von wenigen Minuten). Mit einem NAS, welches rsnapshot ausführeen kann, kannst Du das weitgehend gleich gestalten, rsnapshot legt Snapshots an und überträgt die Differenz zum letzten Snapshot per rsync, die Daten werden dabei nicht überschrieben, sondern es werden (konfigurierbar) mehrere "Vollbackups" angelegt, wobei die unveränderten Daten aber nur einmal vorhanden sind, bei den veränderten Daten gibt es dann pro geänderter Version eine eigene Datei. Der Zugriff erfolgt aber so, als wären jeweils vollständige Backups vorhanden, das funktioniert mit Hardlinks auf die Dateien und braucht nur sehr wenig Platz. So kann man auf den Stand von vor 15, 30, 45, 60 Minuten zugreifen, auf ned Zustand vor 2,3,4,5,6,7,8 Stunden, auf den Zustand von gestern, vorgestern..., letzte Woche, zwei Wochen, drei Wochen... letzten Monat, ... Es gibt also eine fixe Anzahl an Sicherheitskopien, die jeweils wieder überschrieben werden (ähnlich wie bei rrd4j), mit unterschiedlichen zeitlichen Abständen, alles recht frei konfigurierbar.
Die Ablage über ein Bind auf das NAS ist auf den ersten Blick verlockend, aber Du hast ja schon selbst erkannt, dass openHAB nicht starten kann, wenn das NAS - aus welchem Grund auch immer - nicht zur Verfügung steht. Die Backup-Variante funktioniert genauso automatisch, wenn das NAS mal nicht läuft, gibt es halt für diesen Zeitraum kein Backup, aber dennoch keinen zwingenden Ausfall von openHAB.
Hier wird z.B. täglich der LXC-Container komplett gesichert aber es sind auch smartere Lösungen möglich. Auch ein Umzug auf einen neuen Rechner wird damit zum Kinderspiel (gerade diesen Sonntag gemacht).