SmarthomeNG 1.8.2 Image für Raspberry Pi

[rscde]

so, Raspi_SmarthomeNG_public_11.1.9.1.img.7z geladen und die oben genannten Probleme sind behoben.

Herzlichen Dank an dieser Stelle nochmals an Onkelandy und sein Team - bitte weiter so!

[Onkelandy]

Port muss direkt nach der IP kommen IP:8383/admin/

[rscde]

ah ok.
Ich hatte ip-address/admin:8383 probiert, jedoch auch ohne erfolg.

Ich warte mal das neue Image ab, vielleicht ist da dann ja alles gelöst.

Trotzdem vielen Dank!

[Onkelandy]

Hmmm, das ssh Problem kann ich mir nicht ganz erklären. Was sagt denn systemctl status ssh oder sshd ?
Dass die Config Datei weg ist, ist äußerst suspekt, denn die müsste vom Raspbian Image schon da sein.. hmmm.
Admin IF Zugriff bekommst womöglich forbidden..? Probier mal IP:8383/admin/

Warum das ohne port nicht klappt, müsste ich nochmals schauen.

Allerdings kommt morgen ohnehin das neue Image 11.1.9.1
Da beachte ich dann nochmals diese 2 Punkte.

[rscde]

ich habe quasi die gleichen Probleme wie manu241 aus Post #63.
setup_all funktioniert auch nicht...
Ich hätte das ganze per SD-Karte auf einem Raspberry Pi 3 Modell B versucht

[rscde]

Hallo zusammen,

erstmal herzlichen Dank an Onkelandy und allen die bei dem neuen raspi-image mitgewirkt haben.
Es ist immer schön zu sehen dass Projekte weiterentwickelt werden.

Ich hätte mir am Wochenende das aktuelle raspi-image von github heruntergeladen: Raspi_SmarthomeNG_public_11.1.8.2.img.7z
Entpackt, zum ersten test mal auf sd gepackt und los.

Folgende erste Schritte funktionierten leider nicht wie in der Doku beschrieben: https://github.com/smarthomeNG/raspberrypi-image/wiki
- kein ssh Zugriff möglich, openssh-server schien aber installiert zu sein. im Pfad /etc/ssh/ fehlte auch die konfig Datei sshd_config, an dessen Stelle ein Ordner vorhanden war sshd_config.d
- kein Zugriff auf die Admin Oberfläche möglich ip-adress/admin wie in der Doku beschrieben

Das sind wahrscheinlich nur kleinigkeiten, aber wer sich dem Projekt auch nur als Neuling widmen will, verlässt sich erfahrungsgemäß erstmal auf die Doku auf github.

Kann mir zu den Punkten jemand weiterhelfen?

[Morg]

Wie schon angemerkt - Debian und "Abkömmlinge" haben für viele Dateien, die vom System "verwaltet" (bei Installation/Update angelegt) werden, "Soll-Rechte" in einer Datenbank, und bei Updates werden die geprüft und ggf. wiederhergestellt. Gerade im Bereich Konfiguration (/etc) und Runtime (/run, /var) tut man sich mit "einfach Rechte ändern" keinen Gefallen.

Ich habe nicht parat, wo diese Rechte stehen (und würde aus verschiedensten Gründen davon abraten, die zu ändern). In der debian.cnf stehen z.B. Klartextpassworte. (Auf meinem Debian ist das auch root:root 0600). Die möchte ich auch user smarthome nicht lesen lassen. Ggf. wäre es eine Möglichkeit, das Backup als root laufen zu lassen und über sudo erlauben, dass user smarthome diesen einen Befehl ohne Passwort als root starten darf...

[Onkelandy]

Ad 1.)
Oh danke für den Hinweis.. wurde wohl bei openssl was geändert.. Probier mal Zeile 205 in setup_backup.sh wie folgt zu ändern:

sudo openssl enc -e -iter 2 -v -aes-256-cbc -out /$backupfolder/image_backup_encrypted.tar -in /$backupfolder/image_backup.tar

Beim Restore Zeile 16 dann:

sudo openssl enc -e -iter 2 -v -aes-256-cbc -in /$backupfolder/image_backup_encrypted.tar -out /$backupfolder/image_backup.tar

Ad 2.)
Beim Anlegen des Images ist mysql Besitzer und die Rechte sind 644, siehe ansible:

    copy:
      src: configs/mysql.cnf
      dest: /etc/mysql/debian.cnf
      owner: mysql
      group: mysql
      mode: 0644

Bei mir ist das auch beim laufenden Image noch so. Wäre interessant, warum das geändert wurde.. mal sehen.
Du könntest aber so oder so in /etc/cron.hourly/mysql_backup das hier in Zeile 18 einfügen:

sudo chmod 0644 /etc/mysql/debian.cnf
sudo chown mysql:mysql /etc/mysql/debian.cnf

[Sisamiwe]

Gerne Liste mit Änderungen posten.

Dann fange ich mal an...

Ich habe das Image neu auf USB gebannt, system_update und setup_all ausgeführt, und mal eine mysqlDB über mysql importiert. Ich schreibe dann mal hier zusammen, was mir alles auffällt.

1. Das Backup der Gerätekonfiguration startet und läuft durch. Die Dateien "image_backup.tar" und "backup_log.txt" werden erstellt.
   Dann kommt die Meldung:
   

   Backup finished and saved as /home/smarthome/backup/image_backup.tar.
   	Please check /home/smarthome/backup/backup_log.txt for unexpected errors.
   	
   	Encrypting tar file as there are certificates and other private information stored. This might take longer.
   	Please provide a password and remember that for the restore process!
   	enc: Can't parse "-out" as a number
   	enc: Non-positive number "-out" for -iter
   	enc: Use -help for summary.
   	
   	Encryption done. Please copy the file /home/smarthome/backup/image_backup_encrypted.tar to a save place.
   	Deleting unencrypted file.

   Danach ist aber keine Datei "image_backup_encrypted.tar" zu finden.
   Es wird auch kein Passwort abgefragt.
2. Das automatische Backup der mysql, wie über setup_all eingestellt, schlägt fehl. In der "mariabackup.log' steht.
   

   Sun Dec 12 18:33:28 CET 2021 MySQL Backup running.
   	Sun Dec 12 18:33:28 CET 2021 Backup type: full
   	Could not open required defaults file: /etc/mysql/debian.cnf
   	Fatal error in defaults handling. Program aborted
   	Sun Dec 12 18:33:28 CET 2021 mysql_backup: Backup failure! Check /var/log/mysql/mariabackup.log for more information
   	Sun Dec 12 18:33:28 CET 2021 mysql_backup: Backup failure! Check /var/log/mysql/mariabackup.log for more information

   Komisch, dass die Infos in der Datei auf die gleiche Datei verweisen.
   
   Die Datei "/etc/mysql/debian.cnf" exisitiert. Der Eigentümer ist "root", die Zugriffsrechte sind 0600. Somit darf der User smarthome nicht zugreifen.
   Ändere ich die Rechte auf 0644, klappt das Backup.

More to follow....
Ich ergänze das dann hier im Beitrag.

[Onkelandy]

Denke nicht, dass es ums /var/log geht.. oder doch? Dort hat die Gruppe adm, die ich normal für Logging-Sachen nutze, vermutlich tatsächlich keine Schreibrechte..

/var/backups könnte man beim Imageerstellen durchaus dann auch der adm Gruppe zuschieben und die Recht anpassen. Sähe ich an und für sich nicht als dramatisch.

Gerne Liste mit Änderungen posten.

[Morg]

Michael, ich habe das nur flüchtig verfolgt - darf smarthome nicht auf /var/log bzw. die dort hinterlegten Logs zugreifen (normal, würde ich nicht mit Gewalt umbiegen wollen) oder auf /var/backup...?

Im ersten Fall, wenn ein Skript durch smarthome gestartet wird und nicht in die Logdatei schreiben darf, würde ich entweder über syslogd loggen oder ein eigenes Log anlegen, das ist "sauberer".

Im letzteren Fall (wenn es um die nfs-Freigabe geht), spricht ja nichts dagegen.

(Letztlich ist es egal, aber solche Rechteänderungen könnten auch durch Update- und Installationsskripte rückgängig gemacht werden, und dann weiß wieder keiner, warum etwas nicht läuft...)

[Sisamiwe]

Kann ich versuchen.

Hallo,

ich habe es hinbekommen. Primär war es ein Rechteproblem. Der User "smarthome", der ja das mysql_restore ausführt, darf standardmäßig nicht auf das /var/log/mysql zugreifen. So kann das Script die Datei nicht schreiben und es bricht ab. Ich habe die Rechte korrigiert dann klappt es.

Wenn Du willst, kann ich die Punkte gern mal als Liste zusammenschreiben.

Beste Grüße
Michael

[Onkelandy]

schloessl Hier siehst du, was in punkto SQL im Image installiert ist: https://github.com/smarthomeNG/ansib...ian/18_SQL.yml
Der Connector wird im shng Playbook installiert und heißt pymysql
Den nutzt das database Plugin

[Onkelandy]

Moin moin, ich habe das Debian 11 bullseye + SmartHomeNG 1.8.2 versucht.

Kannst du mal ein paar relevante Logfiles posten bitte? Die Fehler sind ja grauenhaft

[manu241]

manu241 Welche Image Version hast du?

Moin moin, ich habe das Debian 11 bullseye + SmartHomeNG 1.8.2 versucht.