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

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Ich will eigentlich nur den Uebeltaeter, der dafuer sorgt dass alle Backups ACLs durch Vererbung bekommen,

    Kann es vielleicht daher kommen, dass die Platte mit den Backups mal "autogemounted" wurde nach media/............. (durch anschließen an einen anderen Pi.... oder wie auch immer)

    Automount nach /media..... -->> ACL

  • Bingo

    Ich hatte nämlich auch einmal ein Problem, dass ein Backup bzgl. acl's fehlschlug, weil zum Zeitpunkt des Backups eine Platte autogemountet war.

    Daraufhin hast du in raspiBackup (glaube ich) /media vom Backup excluded.

    Da Bracew aber eine ältere Version von raspiBackup hat......

  • Daraufhin hast du in raspiBackup (glaube ich) /media vom Backup excluded.

    Jupp. Habe ich in diesem Issue gefixed, :) Aber wie man dort sieht ist der Fix erst im naechsten Release 0.6.8 enthalten ...

    Es haben sich mal wieder ne Menge issues gesammelt und die naechste Release wird nicht mehr lange auf sich warten lassen. Ich hoffe es wird noch vor Weihnachten klappen.

  • Hallo,

    an meinem Zentralem-RasPi hängt eine mehrere Terra Byte (TB) große USB-Festplatte (USB-HDD). Diese nimmt nicht nur die Backups auf, sondern ist u.a. im Heimnetzwerk das (Daten-)Zuhause aller Familienmitglieder, sammelt Daten der Sensoren und ist das Zuhause für dieses, jenes und eines.

    Wenn ich also das

    Loeschen der ACLs

    bereits im

    /media

    -Verzeichnis starte, würden dann nicht alle Dateien auf der USB-HDD von den ACLs befreit werden und dies ggf. zu einem Kollateralschaden führen?

    Wie bereits einmal zuvor dargestellt ist die Struktur auf dem Zentralem-RasPi mit der Festplatte unterhalb von /media/USBHDD1/public/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

    Da noch genügend Platz auf der USB-HDD des Zentralem-RasPi vorhanden ist, folgende Überlegung meinerseits:

    1.) Umbenennen des /media/USBHDD1/public/Backup in /media/USBHDD1/public/BackupALT

    2.) Neu erstellen des /media/USBHDD1/public/Backup mit leerem Inhalt und "richtigen" ACLs

    3.) Auf den Sateliten-RasPi's den NFS-Mountpunkt /backup löschen (rm -rf /backup) und neu mit den "richtigen" ACLs erstellen

    4.) Über die nächsten 3 Wochen werden die Cron-Job gesteuerten raspiBackup ihre Verzeichnisse und Daten mit den "richtigen" ACLs von allein erstellen

    5.) Irgendwann, wenn alles Backups neu angelegt wurden und die entsprechenden Ordner jeweils drei Backups enthalten, den alten Ordner /media/USBHDD1/public/BackupALT löschen.

  • würden dann nicht alle Dateien auf der USB-HDD von den ACLs befreit werden und dies ggf. zu einem Kollateralschaden führen?

    Vermutlich ja. Lass davon die Finger.

    "richtigen" ACLs

    Es sollen keine "richtige" ACLs vorhanden sein sonder keine ACLs :) Es darf also kein '+' Zeichen in uebergeordneten Verzeichnissen vorhanden sein.

    Das tueckische ist dass auch kein uebergeordnetes Verzeichnis ACLs auf der USB Platte haben darf.

    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

    Daraus entnehme ich dass /media/USBHDD1/public auch ACLs enthaelt und das Umbennenen des Backup Verzeichnisses in Alt und neues Anlegen von Backup nichts bringt :no_sad:

    100% sicher gehst Du wenn Du Dein Backupverzeichnis z.B. auf /raspiBackup auf der USB Platte anlegst (ich denke nicht dass / ACLs hat) und dieses Verzeichnis per nfs exportierst und auf den Raspis mountest.

    Zitat

    /media/USBHDD1/public/Backup

    D.h. wenn eines der Ueberverzeichnisse von /backup ACLs hat bringt Dein Ansatz mit den Schritten 1-5 nichts :no_sad:

  • Ich denke das ist die Ausgabe auf dem HuhnPi. Dort hat Bracew ja den Backup mit ACLs restored und somit hat natuerlich / auch ACLs.

    Bracew Lass uns doch mal folgende Ausgaben sehen die auf der .20 Raspi - also Deinem nfs Server - mit der USB Platte ausgefuehrt werden:

    Code
    getfacl -s /public/Backup
    getfacl -s /public
    getfacl -s /
  • Daraus entnehme ich dass /media/USBHDD1/public auch ACLs enthaelt

    Code
    ls -la /media
    insgesamt 12
    drwxr-xr-x  3 root root 4096 Sep 15  2020 .
    drwxr-xr-x 26 root root 4096 Sep 26 13:52 ..
    drwxr-xr-x 10 root root 4096 Nov 22  2013 USBHDD1

    /media/USBHDD1 hat offenbar noch keine ACLs. Dies wäre die oberste Ebene auf der USB-HDD.

    /media/USBHDD1/public hat ein "+" und somit offenbar ACLs.

    100% sicher gehst Du wenn Du Dein Backupverzeichnis z.B. auf /raspiBackup auf der USB Platte anlegst (ich denke nicht dass / ACLs hat) und dieses Verzeichnis per nfs exportierst und auf den Raspis mountest.

    Wenn ich das richtig verstehe, meinst Du auf dem Zentral-RasPi /media/USBHDD1/raspiBackup anlegen und neu für raspiBackup verwenden, wie zuvor mein Schritt 2.), für die "neuen" Backups?

    Dann mit 3.) und 4.) fortsetzen und irgendwann als 5.) /media/USBHDD1/public/Backup löschen.

    Wenn ich auf dem Zentral-RasPi /media/USBHDD1/raspiBackup anlegen würde, welche Rechte müsste ich diesem Ordner geben, damit alle anderen Sateliten-RasPis mit raspiBackup reinschreiben können?

    ls -la /backup

    Das /backup-Verzeichnis ist auf den Sateliten-RasPis, z.B. HuhnPi. Dort ist es ja schief gegangen, deshalb sind dort ja über 100.000 Dateien mit ACLs versehen, warum auch immer.

    Auf dem HuhnPi habe ich nun:

    /backup müsste jetzt ohne ACLs sein, oder?

    Lass uns doch mal folgende Ausgaben sehen die auf der .20 Raspi - also Deinem nfs Server - mit der USB Platte ausgefuehrt werden:

  • Wenn ich das richtig verstehe, meinst Du auf dem Zentral-RasPi /media/USBHDD1/raspiBackup anlegen und neu für raspiBackup verwenden, wie zuvor mein Schritt 2.), für die "neuen" Backups?

    Dann mit 3.) und 4.) fortsetzen und irgendwann als 5.) /media/USBHDD1/public/Backup löschen.

    Genau :thumbup:

    Wenn ich auf dem Zentral-RasPi /media/USBHDD1/raspiBackup anlegen würde, welche Rechte müsste ich diesem Ordner geben, damit alle anderen Sateliten-RasPis mit raspiBackup reinschreiben können?

    Code
    sudo mkdir /media/USBHDD1/raspiBackup

    Dann muss /media/USBHDD1/raspiBackup noch in der /etc/exports eingetragen werden wie schon /media/USBHDD1/public/Backup. Und natuerlich musst Du dann auf den raspiClients den nfs Mount aendern.

  • Dann muss /media/USBHDD1/raspiBackup noch in der /etc/exports eingetragen werden

    In /etc/exports steht zu Zeit:

    Code
    /media/USBHDD1/public/Backup 192.168.0.0/255.255.255.0(rw,sync,no_subtree_check,no_root_squash)

    und müsste geändert werden in:

    Code
    /media/USBHDD1/raspiBackup 192.168.0.0/255.255.255.0(rw,sync,no_subtree_check,no_root_squash)
  • müsste geändert werden in:

    Guter Punkt :thumbup: Ich dachte eher an das Dazufuegen. Aber es ist besser den alten nfs Export voellig zu deaktivieren. Damit stellst Du sicher dass kein Client mehr auf den alten Backupspace zugreifen kann und er erhaelst Fehler wenn Du den nfs mount dort nicht entsprechend anpasst.

  • Und natuerlich musst Du dann auf den raspiClients den nfs Mount aendern.

    In /usr/local/bin/raspiBackupNfsWrapper.sh auf den Sateliten-RasPis:

    Code
    NFSSERVER="192.168.0.20"
    NFSDIRECTORY="/media/USBHDD1/raspiBackup"
    MOUNTPOINT="/backup"
  • So, ich habe:

    1.) auf dem Zentralen-RasPi: sudo mkdir /media/USBHDD1/raspiBackup

    2.) auf dem Zentralen-RasPi: /etc/exports wie zuvor besprochen geändert.

    3.) den Zentralen-RasPi neu gestartet: sudo reboot

    4.) auf dem HuhnPi In /usr/local/bin/raspiBackupNfsWrapper.sh NFSDIRECTORY geändert

    5.) Huhn-Pi neu gestartet: sudo reboot

    6.) sudo /usr/local/bin/raspiBackupNfsWrapper.sh auf dem HuhnPi gestartet.

    Meldung in der bash des HuhnPi:

    Auf dem Zentralen-RasPi:

    Code
    ls -la /media/USBHDD1/raspiBackup
    insgesamt 12
    drwxr-xr-x  3 root root 4096 Nov  9 09:41 .
    drwxr-xr-x 11 root root 4096 Nov  9 09:22 ..
    drwxr-xr-x  2 root root 4096 Nov  9 09:41 HuhnPi
    
    ls -la /media/USBHDD1/raspiBackup/HuhnPi/
    insgesamt 8
    drwxr-xr-x 2 root root 4096 Nov  9 09:41 .
    drwxr-xr-x 3 root root 4096 Nov  9 09:41 ..

    Das Direktory HuhnPi wurde also erstellt. NFS muss demnach funktioniert haben. Es fehlen aber denoch Berechtigungen.

    Wenn ich auf dem Zentral-RasPi /media/USBHDD1/raspiBackup anlegen würde, welche Rechte müsste ich diesem Ordner geben, damit alle anderen Sateliten-RasPis mit raspiBackup reinschreiben können?

    Oder, jetzt neu gefragt, müsste ich /media/USBHDD1/raspiBackup/HuhnPi/ vorher anlegen und Rechte verpassen?

  • Oder, jetzt neu gefragt, müsste ich /media/USBHDD1/raspiBackup/HuhnPi/ vorher anlegen und Rechte verpassen?

    Nein. Das ist nicht notwendig.

    11-09-2022 09:41:08 ??? RBK0266E: Es fehlt die Berechtigung um Linux Dateiattribute auf /backup zu erstellen (Dateisystem: nfs4).

    Da liegt der Hase im Pfeffer :shy: Zeige doch mal das Debuglog. Kannst es mir auch per PN zuschicken wenn Du willst.

  • Danke fuer das Log. War echt eine gute Entscheidung damals ein Debuglog bei raspiBackup einzufuehren und viel zu Loggen. Ohne das Log koennte ich Dir nicht helfen :no_sad:

    Dort sehe ich beim Pruefen ob die Fileattribute gesetzt werden koennen

    Code
    20221109-094106 DBG 3198:          --> supportsFileAttributes /backup
    20221109-094107 DBG 3212:              --- ----r-xrwx+ # nobody # nogroup
    cp: Erhalten der Zugriffsrechte für „//backup/raspiBackup.fileattributes“: Die Operation wird nicht unterstützt
    20221109-094107 DBG 3218:              --- ----r-xrwx # nobody # nogroup
    20221109-094107 DBG 3226:          <-- supportsFileAttributes 1

    Da faellt auf dass die Testdatei die in /tmp erstellt wurde ACLs hat :wallbash:

    Das ist auch klar denn Du hast auf Deinem HuhnPi ja ueberall ACLs nach dem Restore :-/ . D.h. Du musst jetzt die ACLs bei / und bei /tmp loeschen. Dann sollte es funktionieren.

    Code
    sudo setfacl -b <verzeichnis>

Jetzt mitmachen!

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