_alo_

Ich würde sagen: besser nicht, das erschwert die Fehlersuche. Die Gefahr, dass Pi-hole mir was für den Server der ins Netz will, wegfiltert, wäre mir da zu groß.

Ist das die resolv.conf aus dem lucky-backup-Container?? Meine sieht da anders aus, wieso? Die 192.168.178.1 hat mein unifi-Gateway, welches als Resolver meine FritzBox (FTTH-Router, die bekommt die beiden DNS-Resolver meines ISP) sowie zusätzlich 8.8.8.8 eingetragen hat. unraid kennt auch nur die 192.168.178.1 als DNS-Server - wurde der Eintrag evtl. daraus übernommen? P.S.: die Datei ist bei vielen meiner docker die obige, aber die von meinem pihole z.B. wäre ähnlich zu deiner ursprünglichen... woran liegt das? da hab ich mich mangels Problemen noch nie mit befasst wie die docker container an ihr DNS kommen....

was stand denn vorher drin? bzw. welcher Nameserver/Resolver kennt smtp.gmail.com bzw smtp.googlemail.com denn nicht?

Ich habe mir gerade (endlich) mal in den unraid Notification Settings die SMTP Settings (mit einem extra App-Passwort für unraid!) eingerichtet: Wichtig hierbei war, den default "Use STARTTLS" von "No" auf "Yes" zu ändern, sonst gab es auch hier eine Fehlermeldung 😉 vielleicht hilft Dir das?!

Wenn's auch günstiger für zuhause sein darf, vielleicht auch mal das Silverstone GD08 anschauen: Dazu gibt es auch 19" Winkel zum Anschrauben: Ansonsten bin ich auch Fan von meinem Fractal Meshify2, aber das funktioniert liegend in 19" nicht, dürfte zu hoch/breit sein... (und die XL-Gehäuse von denen sind ja noch höher)

Alle automatisch über das Plugin "Auto Update Applications" Es kann natürlich vorkommen, dass man einzelne Updates aus Gründen nicht möchte, oder sie fehlschlagen, aber dafür hat man dann ja zur Not noch ein Backup des Vortages (Plugin "Backup/Restore Appdata"). Ansonsten kannst du auch den Schalter "Update all Docker Applications" auf "no" stellen und sie dann einzeln unten in der Liste deiner docker-container zum Update an-/abwählen:

ich sprach diesen von @saber1 geposteten Link an. Dass die versuchen, es sicherer zu bekommen ist klar, z.B. mit 2FA, aber was sprichst Du bei gmail speziell an? Die Arbeiten doch (um 2FA zu umgehen) mittlerweile alle mit App-Passwörtern und wenn ich sie z.B. damit in der Fritz!Box für die Push-Benachrichtigung eintragen kann (das geht bei mir über gmail), wieso dann nicht auch hier in LuckyBackup? Wobei ich auch nicht nachvollziehen kann, wieso dann GMX nicht gehen soll.... Aber das Gegenprüfen mit anderen eMailprovidern (z.B. auch deines ISPs) wäre bei mir das erste, dafür eine eigene Domain mit Postfächern buchen käme da bei mir erst gaaanz spät (je nachdem wie deren Mailserver konfiguriert ist, muss das ja nicht besser laufen). Du hast aber nicht zufällig irgendwo eine Firewall dazwischen sitzen, wo der Port 587 nicht (mehr) nach draußen durch geht, oder? Aber gerade das hier macht mich etwas stutzig: Beobachte mal deine dyn. IP-Adresse. Vielleicht stehen bestimmte Pools deines Providers auch auf einer Spam-Blacklist, die GMX nutzt/selbst erstellt, dann hast du wenig Chancen.... Funktionieren Deine Zugangsdaten (mit App-Passwort!) denn überhaupt in einem eMail-Client wie Thunderbird? Gibt dieser vielleicht genauere Fehlermeldungen aus?

Ja genau

Genau, was Altu sagt. Wenn das so plötzlich aufgetreten ist (und kein Container-Update damit zu tun hat), wird es wohl an GMX liegen: Die werden wahrscheinlich etwas umgestellt haben, weswegen smtp-auth fehlschlägt, dort mal suchen/fragen. Ansonsten kann es theoretisch auch sein, dass sie durch irgendwelche Änderungen den client sendemail ausgeschlossen haben? Unwahrscheinlich, aber denkbar. Dann vielleicht mal einen anderen client nutzen, sofern luckybackup das zulässt, z.B. den Standard sendmail. Gab es diese Diskussion nicht schon in einem hier geposteten Link? Oder Du probierst das einfach mal mit einem anderen eMail-Provider.

ansich alles richtig aber ein paar Anmerkungen: zu 2. dabei die mover-action nicht vergessen: auf cache->array stellen zu 4./5. eigentlich nicht notwendig, sofern du docker/vm nicht startest und auch bei keinen anderen shares neue Daten in den Schreibcache schreibst, bleibt der cache nach dem Moverlauf leer zu 8. beim Runterfahren wird das array automatisch gestoppt. Das extra-Stoppen kannst du Dir also sparen. zu 11./12. an dieser stelle würde ich nur die mover-action umstellen auf cache<--array und das ganze evtl. auch so belassen. Oder du nimmst den secondary Eintrag wieder raus

das ist hier auch zu erwarten/hoffen.... generell haben ja alle Provider ein Interesse daran über das peering keine BB-Engpässe und geringe Latenzen zu haben. Deshalb schrieb ich ja, dass das routing erstmal wahrscheinlich schlechter wird. Letztlich muss der private Peeringpartner (Welcher stand im heiseArtikel - ich hab den Namen gerade nicht parat) ja auch seine Übergabe-Anschlüsse zu den anderen Providern erst aufbauen bzw. von der Bandbreite her erweitern, wenn hier "plötzlich" so ein großer Player hinzukommt. Das ist sicher nicht ohne... Das sollte schon werden.....ich würde es auch erstmal so lassen... aber was Vodafone da bislang alles so macht (BB-Probleme beim shared medium COAX, CG-NAT Einführung, jetzt das öffentliche Peering zu streichen) macht den Provider m.M.n. zunehmend unattraktiver

ah, ok, ich sehe folgende Änderung zur alten Version: d.h. es wurde der fpm vorher immer reloaded, auch wenn er gestoppt war?! Und das ist ein Problem? vielen Dank für die Einblicke ins Thema Plugins!

vielen Dank, das hat mir sehr geholfen und ich hab wieder viel dazugelernt 👍 Der Installationsfehler war jetzt ein Bug im Plugin oder nur bei mir? bringt mich aber wieder dazu mich mehr mit (email)Benachrichtigungen. Logs und/oder Prüfungen von Diensten/Backups etc. nach automatischen Updates auseinanderzusetzen, damit sowas auch auffällt...

ok, der erste Reboot war vorhin ohne Neuinstallieren des Plugins, einfach nur um zu schauen, was er so für Meldungen beim Booten für fpm ausgibt.... Jetzt hab ich das Plugin neu installiert, die Einstellungen wurden dabei nicht überschrieben(👍) und ich habe nochmal rebootet Die plg unter plugins-error kann/soll ich jetzt manuell löschen? noch eine Frage: nach dem timestamp unter plugins-error zu urteilen, gab es ein Problem mit einem (auto-)Update am 26.09., sehe ich das richtig? der Reboot erfolgte dann am 03.10., d.h. bis dahin wurden auch noch Backups geschrieben (siehe erster Post), weil das Plugin noch aktiv/geladen war, richtig?

genau: wo finde ich das gesamte Systemlog? stehe da gerade auf dem Schlauch.... In der Gui bzw /var/log/syslog.* reicht nicht weit genug zurück...

Ich scheine das Problem gefunden zu haben: Ich denke so läuft das: im Plugin Ordner unter /boot/config/plugins liegt die Cron-Datei im Plugin unter /usr/local/emhttp/plugins/appdata_backup/scripts liegt das checkCron.php-Skript welches die Cron-Datei mit den Eingaben erstellt/anreichert/aktualisiert das unraid-Skript /usr/local/sbin/update_cron sucht sich alle diese cron-Dateien und sammelt den Inhalt zusammen dieses Skript wird aus dem Plugin heraus, nachdem es den cron-Befahl genaut hat, aufgerufen Der Fehler bzw. mein Problem besteht in der for-Schleife vom update_cron ShellSkript: Es werden nur die Crons der Plugins zusammengeführt, die eine entsprechende .plg Datei unter /var/log/plugins/ besitzen! (diese sind allerdings wiederum Symlinks auf /boot/config/plugins/*.plg) Auf meinem Backup-Server unter 7.1.4 sieht das so aus: auf dem Main Server unter 6.12.15 leider so: d.h. mir fehlt offenbar "einfach nur" die .plg-Datei ! aber wieso ist sie verschwunden? jetzt fällt mir auch erst auf, dass er das Plugin nicht mehr listet (was ja über dieses PLG-Manifest erfolgen würde): .....aber die Settings findet er hingegen ja noch.... Kann ich diese appdata.backup.plg einfach rüberkopieren? Oder besser über die GUI das Plugin neu drüber installieren? Was wäre der bessere Weg?

Unter 6.12.15 läuft es ungefähr zeitgleich zum letzten shutdown (Umbau des Servers in anderen Raum) nicht mehr Davor lief es ewig ohne Probleme. Das macht mich ja so stutzig, ich wüsste auch nicht dass ich sonst etwas am Plugin oder generell am unraid umkonfiguriert hatte. Ich werde mir diese Dateien des Plugins und das Prozedere mal anschauen, danke für die Infos

Ja das wäre Plan B aber ich wollte hier schonmal die grundsätzlichen Fragen stellen, weil ja offenbar verschiedene Plugins crontab Einträge schreiben…

Naja, wenn du von zwei komplett unterschiedlichen Domains was lädst wundert mich nicht, dass es Unterschiede gibt. Und wenn Vodafone sich aus dem öffentlichen Peering am zb decix verabschiedet und lieber nur privates Peering betreiben will, wird es Veränderungen geben, je nachdem was der private Anbieter für Peerings hat oder wer mit ihm wie leeren möchte… dass das routing für die Kunden erstmal schlechter wird, scheint sehr wahrscheinlich. Ein Anbieterwechsel oder VPN scheint dann die einzige Lösung zu sein. VPN Anbieter werben ja gern damit „besseres peering als bei ihrem isp“ - ich hab das bislang für Marketing-quatsch gehalten, aber man wird immer eines besseren belehrt….

Worüber Routen die denn jetzt zu github, dass die angeblich jetzt so schlechte Bandbreite haben? 🤣 Was meinst du mit Tunnel angelegt, wohin?

Mir ist heute aufgefallen, dass das Plugin "Backup Appdata", welches ich selbst gerne weiterempfehle, schon länger keine Backups mehr erstellt hat ☹️ Seltsamerweise endeten die Backups am Tag des letzten Reboots vor über einem Monat. Alle Backups der letzten 7 Tage vor diesem Reboot waren noch da, d.h. der Cronjob lief nicht mehr! Wie ich sehen konnte, fehlt der crontab-Eintrag unter /etc/cron.d/root komplett🤔 Gut, dann hab ich an den Scheduler Einstellungen des Plugins die Zeiten geändert und hab darunter "Save" geklickt, in der Hoffnung, er würde die Crontab entsprechend anpassen und den Eintrag wieder reinschreiben. Aber leider macht er das nicht! Die Datei bekommt einen neuen Zeitstempel, aber der Inhalt bleibt seltsamerweise gleich: Auf meinem Backupserver hab ich das Plugin soeben auch installiert, die gleichen Scheduler-Einstellungen vorgenommen und er schreibt folgende Zeile in die Crontab: Ich hab das Backup gerade über die Einstellungsseite manuell angestoßen und er hat anschließend auch vier zu alte Backups gelöscht, alles wie es soll: Klar kann ich den Cron-Eintrag jetzt auch wieder manuell eintragen, aber mich wundert wieso der Eintrag verschwunden ist? wieso er nicht neu geschrieben wird? Welcher Prozess ist dafür zuständig? wieso ich keine Logs/Fehlermeldungen hierzu sehe? Hat das schonmal jemand gehabt? P.S.: Dass der Main-Server noch auf 6.12.15 und der Backup-Server auf 7.1.4 läuft, tut m.W. nichts zur Sache, das Plugin hat schon lange kein Update mehr bekommen. Und es lief ja vor dem letzten Reboot auch Monate/Jahre.... Oder ist es evtl. doch ein bekannter Bug in v6, der bei mir nur noch nie aufgetreten ist? P.P.S.: oder muss ich mir langsam Sorgen um meinen USB-Stick machen?

die konfiguration sollte ja noch auf dem Stick bzw. in deinem Backup sein🤔 oder worum genau geht es? ja dann mach das doch wenn der Platz reicht 🤷‍♂️ Sonst kannst Du ja auch die 2TB HDD nehmen. Lautstärkemäßig sollten die ca. 15min am Tag, in denen das Backup läuft, wohl kaum ein Problem sein, oder? Zudem kannst Du den Zeitpunkt ja entsprechend schieben, dass es Dich nicht stört. Bedenke auch, dass Du ein (am besten externes) Backup deiner Daten haben solltest um einen Defekt des Servers abzufangen (Ransomware/Überspannung/Feuer/Wasser/Diebstahl/...)

ich auch, hatte das in einem anderen Thread ja auch schon geschrieben: DDR4 steigt seit Juni/Juli enorm im Preis an, da muss man immer genauer schauen, ob DDR5 nicht einfach vom Preis her "schon dran" ist 😉

Ich bin jetzt auch kein Stripe-Experte aber die Seite scheint anhand vom Browser/OS zu entscheiden, welche Methode noch angezeigt wird. Mein Chrome unter MacOS zeigt auch nur googlePay, kein applePay, sieht also aus wie unter Windows bei mir. Vielleicht liegt's da auch an google (chrome)? 🤷‍♂️ Wahrscheinlich ist das Problem die automatischen Erkennung bei Stripe..... Was nutzt du da als Betriebssystem? Mint? Hast Du es vielleicht schonmal am Handy probiert? Edit: vielleicht ist dein System / Browser auch einfach so stark datenschutzmäßig eingestellt, dass keine Infos an Stripe mit übergeben werden, die zu der Darstellung von weiteren Zahlungsmethoden notwendig wären.... Das Problem besteht sicherlich bei der Verwendung von Stripe, nicht bei LimeTech direkt. Du hast dieses Problem wahrscheinlich auch bei anderen Shops, die Stripe nutzen?!

....auf der Homepage wird aber immer noch GooglePay und ApplePay für Stripe mit angezeigt - funktioniert das nicht? unter Windows (Edge): unter MacOS (Safari):