FHEM und ACLs in Bezug auf raspiBackup [gelöst]

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo,

    wir haben hier: RE: raspiBackup - Sichere Deine Raspberry regelmäßig im laufenden Betrieb

    die Diskussion begonnen und hier: RE: raspiBackup - Sichere Deine Raspberry regelmäßig im laufenden Betrieb

    die Diskussion in einem neuen Thread (hierher) verwiesen.

  • Zitat

    Lass mal |wc -l  weg um zu sehen weclhe Dateien es sind.

    Möchtest Du hier alle 110.911 gelistet haben? Ich glaube nicht, aber für den Anfang hier ein Auszug der ersten und letzten:

    Spoiler anzeigen

    /

    //bin

    //bin/zmore

    //bin/ed

    //bin/ss

    //bin/less

    //bin/bzip2recover

    //bin/systemd-ask-password

    //bin/chmod

    //bin/sed

    //bin/rmdir

    //bin/wdctl

    //bin/znew

    //bin/nc.traditional

    //bin/gzexe

    //bin/ip

    //bin/systemd-notify

    //bin/mt-gnu

    //bin/ps

    //bin/gzip

    //bin/grep

    //bin/bzmore

    //bin/nano

    //bin/uncompress

    //bin/systemd-sysusers

    //bin/tar

    //bin/kill

    //bin/journalctl

    //bin/hostname

    //bin/busybox

    //bin/echo

    //bin/chacl

    //bin/unicode_start

    //bin/zcmp

    //bin/dir

    //bin/fbset

    //bin/mv

    //bin/touch

    //bin/udevadm

    //bin/fgconsole

    //bin/fuser

    //bin/sleep

    //bin/cp

    //bin/systemd-hwdb

    //bin/mount

    //bin/true

    //bin/zegrep

    //bin/loadkeys

    //bin/mktemp

    //bin/mountpoint

    //bin/dmesg

    //bin/readlink

    //bin/cpio

    //bin/zforce

    //bin/dumpkeys

    //bin/bash

    //bin/systemd-tmpfiles

    //bin/which

    //bin/modeline2fb

    //bin/zgrep

    //bin/kmod

    //bin/egrep

    //bin/bzexe

    //bin/red

    //bin/dash

    //bin/zcat

    //bin/date

    //bin/con2fbmap

    //bin/false

    //bin/bzip2

    //bin/systemd-tty-ask-password-agent

    //bin/zless

    //bin/pwd

    //bin/uname

    //bin/findmnt

    //bin/umount

    //bin/getfacl

    //bin/loginctl

    //bin/tailf

    //bin/mknod

    //bin/nc.openbsd

    //bin/ln

    //bin/sync

    //bin/more

    //bin/lsblk

    //bin/bzdiff

    //bin/kbd_mode

    //bin/systemd-inhibit

    //bin/mkdir

    //bin/openvt

    //bin/fgrep

    //bin/gunzip

    //bin/setfacl

    //bin/keyctl

    //bin/dd

    //bin/vdir

    //bin/stty

    //bin/bzcat

    //bin/tempfile

    //bin/netstat

    //bin/lesskey

    //bin/bunzip2

    //bin/df

    //bin/setupcon

    //bin/plymouth

    //bin/lessecho

    //bin/lesspipe

    //bin/chgrp

    //bin/networkctl

    //bin/rm

    //bin/zdiff

    //bin/systemctl

    //bin/cat

    //bin/zfgrep

    //bin/chvt

    //bin/su

    //bin/bzgrep

    //bin/systemd-escape

    //bin/systemd-machine-id-setup

    //bin/ls

    //bin/login

    //bin/setfont

    //bin/run-parts

    //bin/chown

    //bin/ping

    //webmin-setup.out

    //raspiBackup.log

    //tmp

    //tmp/.font-unix

    .

    .

    .

    .

    //opt/rc-switch/wiringPi/.git/refs

    //opt/rc-switch/wiringPi/.git/refs/tags

    //opt/rc-switch/wiringPi/.git/refs/tags/2.31

    //opt/rc-switch/wiringPi/.git/refs/tags/2.29

    //opt/rc-switch/wiringPi/.git/refs/tags/2.32

    //opt/rc-switch/wiringPi/.git/refs/tags/2.30

    //opt/rc-switch/wiringPi/.git/refs/remotes

    //opt/rc-switch/wiringPi/.git/refs/remotes/origin

    //opt/rc-switch/wiringPi/.git/refs/remotes/origin/master

    //opt/rc-switch/wiringPi/.git/refs/remotes/origin/HEAD

    //opt/rc-switch/wiringPi/.git/refs/heads

    //opt/rc-switch/wiringPi/.git/refs/heads/master

    //opt/rc-switch/wiringPi/build

    //opt/rc-switch/wiringPi/devLib

    //opt/rc-switch/wiringPi/devLib/piGlow.c

    //opt/rc-switch/wiringPi/devLib/piGlow.o

    //opt/rc-switch/wiringPi/devLib/gertboard.c

    //opt/rc-switch/wiringPi/devLib/libwiringPiDev.so.2.0

    //opt/rc-switch/wiringPi/devLib/lcd128x64.h

    //opt/rc-switch/wiringPi/devLib/piFace.h

    //opt/rc-switch/wiringPi/devLib/lcd128x64.o

    //opt/rc-switch/wiringPi/devLib/Makefile

    //opt/rc-switch/wiringPi/devLib/ds1302.h

    //opt/rc-switch/wiringPi/devLib/ds1302.o

    //opt/rc-switch/wiringPi/devLib/lcd.o

    //opt/rc-switch/wiringPi/devLib/piFaceOld.c

    //opt/rc-switch/wiringPi/devLib/lcd128x64.c

    //opt/rc-switch/wiringPi/devLib/lcd.h

    //opt/rc-switch/wiringPi/devLib/gertboard.o

    //opt/rc-switch/wiringPi/devLib/piNes.h

    //opt/rc-switch/wiringPi/devLib/font.h

    //opt/rc-switch/wiringPi/devLib/maxdetect.c

    //opt/rc-switch/wiringPi/devLib/maxdetect.o

    //opt/rc-switch/wiringPi/devLib/piNes.c

    //opt/rc-switch/wiringPi/devLib/piNes.o

    //opt/rc-switch/wiringPi/devLib/maxdetect.h

    //opt/rc-switch/wiringPi/devLib/piFace.c

    //opt/rc-switch/wiringPi/devLib/lcd.c

    //opt/rc-switch/wiringPi/devLib/piGlow.h

    //opt/rc-switch/wiringPi/devLib/piFace.o

    //opt/rc-switch/wiringPi/devLib/ds1302.c

    //opt/rc-switch/wiringPi/devLib/gertboard.h

    //opt/rc-switch/wiringPi/INSTALL

    //opt/pishutdownwhenbuttonpressed

    //opt/pishutdownwhenbuttonpressed/pishutdownV12HuhnPi.py

    //opt/pishutdownwhenbuttonpressed/pishutdownV11.py

    //opt/pishutdownwhenbuttonpressed/pishutdown.py

    //opt/pishutdownwhenbuttonpressed/pishutdownV10.py

    //backup

    //RaspController

    //RaspController/bmp_v6.py

    //RaspController/monitoring_v5.py

    Ich habe mal nach raspibackup suchen lassen, u.a.:

    Spoiler anzeigen

    //raspiBackup.log

    //usr/local/bin/raspiBackup_fstab_ready.sh

    //usr/local/bin/raspiBackup_temp_post.sh

    //usr/local/bin/raspiBackup_mem_pre.sh

    //usr/local/bin/raspiBackup.0.6.5.1.sh

    //usr/local/bin/raspiBackupNfsWrapper.sh

    //usr/local/bin/raspiBackup_disk_pre.sh

    //usr/local/bin/raspiBackupInstallUI.sh

    //usr/local/bin/raspiBackupNfsWrapper-WeBe.sh

    //usr/local/bin/raspiBackup.sh

    //usr/local/bin/raspiBackup_mem_post.sh

    //usr/local/bin/raspiBackup.0.6.6.1.sh

    //usr/local/bin/raspiBackup_mail.sh

    //usr/local/bin/raspiBackup_execute_post.sh

    //usr/local/bin/raspiBackup.0.6.7.sh

    //usr/local/bin/raspiBackup_disk_post.sh

    //usr/local/bin/raspiBackup_temp_pre.sh

    //usr/local/etc/raspiBackup.conf


  • Möchtest Du hier alle 110.911 gelistet haben? Ich glaube nicht, aber für den Anfang hier ein Auszug der ersten und letzten:

    Nee. Das reicht schon :lol: . Irgendwas ist da auf Deinem System passiert dass alle Dateien ACLs bekommen haben :conf:

    So wie es aussieht hat bei Dir jede Datei ACLs :-/ Die Frage ist wie das passiert ist. Du hast doch ein RaspbianOS oder? Zeige mal bitte

    Code
    cat /etc/os-release
  • Code
    PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
    NAME="Raspbian GNU/Linux"
    VERSION_ID="9"
    VERSION="9 (stretch)"
    VERSION_CODENAME=stretch
    ID=raspbian
    ID_LIKE=debian
    HOME_URL="http://www.raspbian.org/"
    SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
    BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

    Wie bereits in:

    Bracew
    6. November 2022 um 15:25

    geschrieben:

    Zitat

    ...und die SD-Karte meines HuhnPi mit einem Restore vom letzten raspiBackup wieder zurück gesetzt. Danach war wieder alles OK. Zunächst.

    Ich denke, dass ich mir die ACL-Suppe mit dem Restore eingebrockt habe, den bis dahin liefen die Backups wie geschmiert!

  • Ich denke, dass ich mir die Suppe mit dem Restore eingebrockt habe, den bis dahin liefen die Backups wie geschmiert!

    Das ist mir auch schon in den Sinn gekommen :|

    Allerdings verstehe ich nicht wie denn in Deinem Backup auf der Syno gibt es keine ACLs und somit koennen auch keine beim Restore entstehen. Die Syno unterstuetzt keine Posix ACLs die von rsync genutzt werden :conf:

  • Eine Synology(?)-NAS ist eine falsche Vermutung

    Sorry - ich kann mir nicht die Konfiguration aller meiner raspiBackup Nutzer merken :no_sad: . Viele nutzen eine Syno oder QNAP.

    Aber gut zu wissen. D.h. Du exportierst eine USB HDD von einer anderen Raspi und sicherst darauf. Man braucht nicht unbedingt eine NAS. Ich habe lange Zeit auch meine Backups auf einer Raspberry abgelegt.

    Kannst Du mal folgende Befehle auf Deiner Raspi eingeben und die Ausgabe zeigen?

    Code
    mount
    ls -la <nfsMountPoint>
  • Sorry - ich kann mir nicht die Konfiguration aller meiner raspiBackup Nutzer merken

    Ist klar und selbstverständlich.

    Ich habe einen Zentralen RasPi mit HDD. Die anderen Sateliten-RasPi sichern auf der HDD des Zentralen RasPi. Auch der Zentrale RasPi sichert sich selbst auf der HDD des Zentralen RasPi.

    Hier ist es aber ein Sateliten-RasPi (namens HuhnPi) dessen Sicherung bis vor dem Restore gut funktionierte und jetzt über die ACLs außer Tritt kommt. Mit der Änderung aus Deinem Hinweis: Du musst in /usr/local/etc/raspiBackup.conf die folgende Zeile aufnehmen:

    Code DEFAULT_RSYNC_BACKUP_OPTIONS="-aHx --delete" funktioniert es wieder.

    Hier mount und ls -la <nfsMountPoint> vom HuhnPi:

    Code
    ls -la /backup
    insgesamt 8
    drwxr-xr-x+  2 root root 4096 Nov  6 10:42 .
    drwxr-xr-x+ 23 root root 4096 Nov  6 11:14 ..

    Zitat aus Deinem /usr/local/bin/raspiBackupNfsWrapper.sh:

    Code
    NFSSERVER="192.168.0.20"
    NFSDIRECTORY="/media/USBHDD1/public/Backup"
    MOUNTPOINT="/backup"

    Die NFS-Verbindung wird erst zur Backup-Zeit vom raspiBackupNfsWrapper.sh aufgebaut.

  • Du hast am Verzeichnis /backup und am übergeorfneten Verzeichnis (root) ein ACL gesetzt, wie an dem + Zeichen hinter den Dateirechten ersichtlich ist.

    Alle in diesen Verzeichnissen neu erstellte Dateien und Verzeichnisse könnten mit demselben ACL beerbt werden..

    Mit < getfacl /backup > kannst Du Dir die Access Controll List des /backup Verzeichnisses ansehen.

    Siehe < getfacl -h >, < setfacl -h >, < man acl > samt SEE ALSO

    Für das Einrichten eines NFS Clients und Servers siehe https://www.raspberrypi.com/documentation/…file-system-nfs


    Servus !

    RTFM = Read The Factory Manual, oder so

    2 Mal editiert, zuletzt von RTFM (7. November 2022 um 08:01)

  • Die NFS-Verbindung wird erst zur Backup-Zeit vom raspiBackupNfsWrapper.sh aufgebaut.

    Das hatte ich vergessen. Mountest Du noch mal /backup und zeigst Dann die Ausgabe von mount und sudo ls -la /backup?

    Ich denke RTFM hat den entscheidenen Hinweis gegeben. Wenn ich das momentan richtig ueberblicke koennen wir wohl die ACLs auf Deinem System wieder loswerden. Aber dazu brauche ich noch die vorhergehende Ausgabe und muss bei mir lokal auch noch mal was nachstellen.

  • Hallo,

    mir ist noch aufgefallen, dass gestern in: RE: raspiBackup - Sichere Deine Raspberry regelmäßig im laufenden Betrieb

    seitens framp erwähnt wurde:

    Zitat

    Das ist bereits gefixed im naechsten Release. Ich werde den Fix aber jetzt gleich cherry-picken und in die 0.6.7 zurueckrollen. Morgen Jetzt kannst Du Dir den Fix mit sudo raspiBackup.sh -U -S holen.

    mit dem Hinweis auf Version 0.6.7.

    Mit Verweis auf https://github.com/framps/raspiBa…ment-1218038375

    nutze ich auf dem HuhnPi raspiBackup.sh 0.6.6.1.

    Code
    sudo raspiBackup.sh -V
    --- RBK0117I: Aktuelle Scriptversion: 0.6.6.1


    Dann die Ausgabe von mount und sudo ls -la /backup?

    Code
    sudo ls -la /backup
    insgesamt 32
    drwxrwxr-x   7 root root 4096 Nov  6 17:22 .
    drwxr-xr-x+ 23 root root 4096 Nov  6 11:14 ..
    drwxrwxrw-   5 root root 4096 Nov  3 01:23 epi
    drwxrwxrwx   5 root root 4096 Nov  4 01:48 HeizPi
    drwxr-xr--   3 root root 4096 Nov  6 17:22 HuhnPi
    drwxr-xr--   5 root root 4096 Okt 22 01:11 HuhnPi-Org-2022-10-22
    drwxrwxrw-   5 root root 4096 Nov  6 03:38 pi
  • Nachdem RTFM mich angeschubst hat (Noch mal vielen Dank!) habe ich das Problem reproduzieren koennen und somit verstanden :)

    Was habe ich gemacht?

    Ich habe auf einer Raspi per nfs4 ein Verzeichnis exportiert und bei diesem Verzeichnis /disks/silver/raspiBackup Default ACLs definiert:

    Dann habe ich dieses Backupverzeichnis an einer anderen Raspi per nfs4 gemounted und raspiBackup gestartet. Das Ergebnis auf der Backupserverseite:

    Wie man sieht haben alle Verzeichnisse und Dateien ACLs bekommen (das + Zeichen) da das Backupwurzelverzeichnis ACLs hat und diese an alles was darunter erstellt wird weitervererbt :no_sad:

    D.h. wenn man nun dieses Backup direkt - also ohne nfs - zurueckspielt bekommt das restorte System auch ACLs da rsync ACLs kopieren kann wenn kein nfs genutzt wird :wallbash:

    Jetzt ist die Frage ob und wie Bracew s HuhnPi seine ACLs wieder los wird und ob es sein muss.

    1) Genaugenommen sind die ACLs kein Problem. Das System laeuft auch mit ihnen ohne Probleme. D.h. man koennte es jetzt so lassen. Da die Option A bei rsync entfernt wurde werden zukueftig keine ACLs mehr beim Backup kopiert und sollte mal wieder ein Backup restored werden muessen sind die ACLs weg. Natuerlich sollte auch die Quelle allen Uebels - die ACL vom Backupverzeichnis - geloescht werden.

    Wenn Bracew aber sein HuhnPi schnell wieder ACL frei haben moechte muss

    2) entweder das naechste Backup was ohne die Option A erstellt wurde einfach zurueckgespielt werden. Am besten auf eine andere SD Karte um falls doch noch irgendwas nicht OK sein sollte wieder zurueckgehen zu koennen.

    3) Alternativ kann auch das Backup was damals mit ACLs zurueckgespielt wurde noch einmal restored werden. Da jetzt die Option A bei rsync fehlt werden auch keine ACLs mehr zurueckgespielt.

    Welchen der drei Wege Du Bracew einschlaegst musst Du entscheiden :)

    Wie Du es geschafft hast im Backupverzeichnis ACLs zu setzen weisst nur Du :shy:

  • Mit Verweis auf https://github.com/framps/raspiBa…ment-1218038375

    nutze ich auf dem HuhnPi raspiBackup.sh 0.6.6.1.

    Stimmt. Aus irgendeinem Grunde nutzt Du noch das alte 0.6.6.1. Dann musst Du beim Restore immer dran denken noch den Backupverzeichnismountpunkt nach dem Restore anzulegen. Oder Du upgradest auf die aktuelle 0.6.7. Genaugenommen solltest Du auch mal sehen dass Du vom Stretch wegkommst. Stretch ist out of support.

  • Welchen der drei Wege Du Bracew einschlaegst musst Du entscheiden

    Ich würde mich für 1) entscheiden.

    Natuerlich sollte auch die Quelle allen Uebels - die ACL vom Backupverzeichnis - geloescht werden.

    Ja, ich würde gerne auf allen meinen RasPi, die per NFS sichern, das /backup Verzeichnis mit der falschen Vererbung löschen und durch ein "richtiges" ersetzen.

    Wie erstelle ich ein neues korrektes /backup Verzeichnis?

    Dann musst Du beim Restore immer dran denken noch den Backupverzeichnismountpunkt nach dem Restore anzulegen.

    Ja versuche ich, aber hilf mir noch bitte wie ich den Mountpunkt händisch "richtig" anlege. Ich hatte mir bereits das letzte Mal notiert:

    Code
    sudo mkdir /backup
    sudo chown root:root /backup

    Ist das so Ok?

    Stimmt. Aus irgendeinem Grunde nutzt Du noch das alte 0.6.6.1.

    ja, wie wir beide gemeinsam auf Github rausgefunden haben, läuft raspiBackup.sh nur mit dieser Version (0.6.6.1) auf meinen beiden Raspbian 9.13 stretch Pi's

    Wie bereits in https://github.com/framps/raspiBa…ment-1274211717 erklärt, möchte ich zwei meiner Pi's nicht mehr großartig antasten, sondern so lassen. Das Linux meines ebenfalls am Heimnetz angeschlossenen TV's ist noch älter und wird seitens des Herstellers auch nicht mehr aktualisiert.

    Ich fürchte, dass die beiden letzten Sätze hier einen Aufschrei auslösen werden. Der Diskussion werde ich mich aber nicht stellen.

  • Ich würde mich für 1) entscheiden.

    In die Richtung hattest Du Dich ja schon im FHEM Forum geaeussert :)

    Wie erstelle ich ein neues korrektes /backup Verzeichnis?

    Du brauchst kein neues Verzeichnis zu erstellen. Du musst nur das Verzeichnis finden welches die ACLs hat und diese loeschen. Dazu musst Du auf Deine NFS Server gehen. Lt der obigen Ausgabe

    Code
    192.168.0.20:/media/USBHDD1/public/Backup on /backup type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.50,local_lock=none,addr=192.168.0.20)

    muss das Dein .20 sein. Dort gehe in das Verzeichnis

    Code
    /media/USBHDD1/public/Backup

    und fuehre folgenden Befehl aus:

    Code
    find . -type d -maxdepth 1 -exec getfacl -s {} \;

    Damit wird in einer Verzeichnistiefe von 1 nach Verzeichnissen mit ACLs gesucht. Falls Du nichts ausgegeben bekommst musst Du statt . /media/USBHDD1/public angeben. Falls da immer noch nichts kommt /media/USBHDD1/. Falls immer noch ncihts kommt /media. Ich glaube Du fast wirst ACLs erst finden bei /media:shy:

    sudo mkdir /backup

    sudo chown root:root /backup

    Ist das so Ok?

    Code
    sudo mkdir /backup

    reicht vollkommen.

    Ich fürchte, dass die beiden letzten Sätze hier einen Aufschrei auslösen werden. Der Diskussion werde ich mich aber nicht stellen.

    Ich hoffe nicht denn das hat mit dem eigentlichen Thema nichts zu tun :cursing:

    Es ist Deine Entscheidung den Weg des Never touch a running System zu gehen und wenn die Systeme nicht am Internet haengen sehe ich da auch keine Probleme - auch wenn ich diese Strategie nicht gutheisse :shy:

    Nur muss Dir klar sein dass es umso schwieriger wird Systeme auf neue Staende zu bringen je aelter sie sind. FHEM, RaspbianOS werden weiterentwickelt ... Auch raspiBackup wird sich weiterentwickeln und ich rolle keine Fixes mehr in alte Releases rein - wie z.B. das Problem bei Dir in 0.6.6.1 mit dem fehlenden BackupMountpoint :no_sad:

  • Entschuldigung, ich dachte aufgrund von:

    Du hast am Verzeichnis /backup und am übergeorfneten Verzeichnis (root) ein ACL gesetzt, wie an dem + Zeichen hinter den Dateirechten ersichtlich ist.

    dachte ich es liegt an den ACLs des temporär gemounteten /backup Verzeichnis.

    Du musst nur das Verzeichnis finden welches die ACLs hat und diese loeschen.

    Wo sehe ich denn, welches ACLs hat? und wie lösche ich die?

  • Loeschen der ACLs geht mit sudo setfacl -b <verzeichnisname>

    Geht das nicht mit -R recursiv?

    z.B. sudo setfacl -b -R /backup

    Laut man setfacl gibt es auch dort die Option -R

    Zitat

    -R, --recursive

    Apply operations to all files and directories recursively. This option cannot be mixed

    with `--restore'.

  • Ja - da hast Du Recht :) . Ich will eigentlich nur den Uebeltaeter, der dafuer sorgt dass alle Backups ACLs durch Vererbung bekommen, entfernen. D.h. dann entstehen bei zukuenftigen Backups keine ACLs mehr. Die alten Backups haben die ACLs natuerlich noch. Da aber Bracew die Option A bei rsync in raspiBackup entfernt hat werden beim Restore dieser mit ACLs behafteten Backups die ACLs zukuenftig nicht mehr restored und somit ist es nicht notwendig alle ACLs aus den Backups zu entfernen. Aber man koennte es natuerlich tun :thumbup:

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!