Beiträge von psychofaktory

    das man inzwischen von der docker.img weg kann ich ein guter Tipp hatte ich garnicht so auf dem schirm.

    Das ist tatsächlich eine feine Sache.

    Zum einen ist dann direkt transparent ersichtlich was sich ansonsten alles innerhalb der docker.img abgespielt hat indem man sich einfach das Verzeichnis anschaut.

    Zum anderen (und das ist der wirklich große Mehrwert) sind nicht mehr alle Container beschädigt und müssen ggfs. neu angelegt werden wenn die docker.img defekt war (z.B. aufgrund zu wenig freiem Speicherplatz, oder einer abrupten Systemunterbrechung, Stromausfall, etc.).

    Afaik bietet ZFS File integrity, was vorallem nach meinen letzten Erfarhungen ziemliche geil wäre.

    Auf diese Funktion wäre ich eben auch scharf.

    Auf der anderen Seite ist es noch nicht lange in unRaid integriert, sieht man ja auch da dran das recht viele Update diesbzgl. kommen.

    Also eher abwarten...
    Das hat sich bei Unraid bereits mehr als einmal als sinnvolle Strategie erwiesen nicht direkt bei allen Neuerungen sofort mit auf den Zug aufzuspringen.

    Die Punkt waren jetzt nicht speziell auf dein Problem bezogen, sondern als ganz allgemeine Anregung für mehr Stabilität.

    Ist letztlich natürlich alles wieder vom Einzelfall und der individuellen Konfiguration abhängig.

    Docker Verzeichnis: wie geht das?


    Rotation der Docker... ? Wo bitte?


    Netzwerktyp: Finde dazu keinen Hinweis unter Netzwerkeinstellungen?

    Die drei Punkte kannst du alle unter "Einstellungen" -> "Docker" setzen. Dazu muss aber erst der Docker-Dienst beendet werden.

    Wenn du von der docker.img auf Verzeichnis umstellst wirst du anschließend die Docker nochmal alle neu anlegen dürfen. Das geht dank dem vorlagenbasierten Modus und den im Appdata-Verzeichnis abgelegten Daten zum Glück idR recht schnell.

    Bei der Umstellung des Netzwerktyps kann es ggfs. auch zu Problemen kommen, je nach Konfiguration.

    ipvlan ist seitens Unraid aber wohl langfrist der neue Standard und von offizieller Seite wird dazu geraten darauf umzustellen. Läuft bei mir seitdem wie gesagt auch deutlich stabiler. Zuvor gab es ein paar mal ein "Kernel Panik". Das Fehlerbild war dann genau wie bei dir.

    Boogie2005 hast du den Fehler gefunden?


    Vielleicht sollten wir mal ein paar Best-Practice-Ansätze zusammentrage die für mehr Stabilität sorgen.

    Bei mir konnte ich z.B. nachdem es an verschiedenen Stellen zu Problemen kam durch diese Anpassungen erhebliche Verbesserungen erzielen:

    • Plugins aktuell halten und vor allem verwaiste Plugins löschen und ggfs. durch die neuen Varianten ersetzen
    • Über das "User Scripts"-Plugin habe ich einen Cron-Job erstellt der regelmäßig die Log-Files bereinigt, damit hier nichts voll läuft
    • verwaiste Docker-Images sollten ebenfalls von Zeit zu Zeit bereinigt werden
    • In der Syslinux-Konfiguratino habe ich als Zeitgeber clocksource=hpet eingetragen. Bei meinem Board hat das ebenfalls Verbesserungen (insbesondere bzgl. der installierten VMs) mit sich gebracht
    • Bei meinem Cache (btrfs, raid1 aus 2 NVMe-SSDs) habe ich einen wöchentlichen Balance-Zeitplan eingerichtet
    • Die Schwellenwerte für die Datenträgertemperatur wurden auf die tatsächlichen Werte für meine Festplattenmodelle aus dem Datenblatt angepasst (um Fehlalarme zu vermeiden)

    Die größte Verbesserung konnte ich aber durch Anpassung der Docker-Einstellungen erreichen:

    • Umstellung des Docker-Stammverzeichnisses von der docker.img-Datei auf "Verzeichnis"
    • Rotation der Docker-Protokolldateien aktivieren
    • Umstellung des Docker-Netzwerktyps von macvlan auf ipvlan

    Anhand der seinerzeit gängigen Empfehlungen habe ich den Cache btrfs formatiert und das Array xfs. Habe auch ECC-RAM.

    Inzwischen gibts ja auch die Möglichkeit ZFS zu verwenden. Wie sind da eure Meinungen dazu? Wie würdet ihr das machen?

    Version 6.12.5 2023-11-27

    Upgrade notes

    This release includes bug fixes and security updates. All users are encouraged to upgrade.

    Known issues

    There is a mitigation included for a ZFS Data Corruption issue. This is accomplished by including this option in the default /etc/modprobe.d/zfs.conf file:

    zfs_dmu_offset_next_sync=0

    Please see the 6.12.0 release notes for general known issues.

    Rolling back

    If rolling back earlier than 6.12.4, also see the 6.12.4 release notes.

    Changes vs. 6.12.4

    Bug fixes and improvements

    • Replace very old 'MemTest86+' with Memtest86+ version: 6.20
    • When 'mirror syslog to flash' is enabled, view syslog-previous at Tools -> Syslog, and in diagnostics
    • Docker:
      • Docker containers were not always stopping, preventing docker from unmounting
      • Docker containers using IPv6 on custom networks were unable to start
    • emhttpd: if User Shares not enabled, update_cron was not called during array Start sequence
    • rc.nginx stop - force nginx to stop
    • shfs: Allocation method was not working correctly if 6 or more disks were specified in the 'include' mask
    • webgui:
      • Downgrade.php was not updated for 6.12
      • always show ipvlan / macvlan setting
    • ZFS: use 'zfs import -f' to ensure pools from other systems get imported
    • prevent auto-spindown of unformatted devices

    Package updates

    • curl: version 8.4.0 (CVE-2023-38546 CVE-2023-38545 CVE-2023-38039)
    • firefox: version 119.0.r20231106151204 (AppImage)
    • intel-microcode: version 20231114
    • kernel-firmware: 20231024_4ee0175
    • qemu: version 7.2.0
    • samba: version 4.17.12 (CVE-2023-3961 CVE-2023-4091 CVE-2023-4154 CVE-2023-42669 CVE-2023-42670)
    • smartmontools: version 7.4
    • zfs: version 2.1.13

    Linux kernel

    • version 6.1.63
    • CONFIG_USB_NET_CDC_NCM: CDC NCM support
    • CONFIG_NFS_V4_1: NFS client support for NFSv4.1
    • CONFIG_NFS_V4_1_MIGRATION: NFSv4.1 client support for migration
    • CONFIG_NFS_V4_2: NFS client support for NFSv4.2
    • CONFIG_NFS_V4_2_READ_PLUS: NFS: Enable support for the NFSv4.2 READ_PLUS operation
    • CONFIG_NFSD_V4_2_INTER_SSC: NFSv4.2 inter server to server COPY

    Die "Nightly" Version ist die Version, die den aktuellen Stand der Entwicklung zum Zeitpunkt ihrer Veröffentlichung darstellt.

    Sie enthält daher immer die neuesten Features/Funktionen, kann aber auch noch Fehler beinhalten.

    Die Kodi Version 20.2 ist die aktuelle "stabile" Version. Stabile Versionen werden weniger häufig veröffentlicht und enthalten daher auch nicht die aktuellsten Neuerungen. Dafür sind sie in der Regel aber deutlich stabiler und somit besser für den täglichen Einsatz geeignet.

    Ein Übertrag der betreffenden Funktion aus der Nightly in Kodi 20.2 wäre nur möglich, wenn du dir das Kodi Repository clonst, mit dem zugehörigen Commit zusammenführst und dann selbst kompilierst.

    Alternativ kannst du anstatt der 20.2 auch die aktuelle Nightly-Version verwenden. Die dann aber möglicherweise an anderer Stelle Fehler enthält.

    Oder du wartest auf die nächste stabile Veröffentlichung.

    Ich hab teilweise auch so lange Kennwörter. Aber da ich am Smartphone ohnehin über meine KeePass-Datenbank (welche via Nextcloud zwischen den Geräten synchronisiert wird) auf die gespeicherten Kennwörter zugreife, ist das dann immer nur ein Copy&Paste.

    Mit Sonderzeichen hatte ich da bisher noch keine Probleme. Falls eine Anwendung damit doch nicht klar kommen sollte, tut es der Sicherheit denke ich aus rein praktischer Sicht heutzutage keinen großen Abbruch bei einem 30-Zeichen langen Kennwort bestehend aus Buchstaben in Klein- und Großschreibung, Zahlen und Sonderzeichen die Sonderzeichen wegzulassen bzw. nur "sichere" Sonderzeichen zu verwenden.

    Quelle:

    Passwort-Sicherheit-Check: Wie sicher ist mein Passwort?

    30 Zeichen (Klein- und Großschreibung, Zahlen und Sonderzeichen): "Ein herkömmlicher PC könnte dein Passwort innerhalb von 680 Sextilliarden Jahren knacken."

    30 Zeichen (Klein- und Großschreibung, Zahlen): "Ein herkömmlicher PC könnte dein Passwort innerhalb von einer Sextillion Jahren knacken."

    Bootloader ist unlocked

    Das ist das Problem.

    Die Google-Dienste haben im Hintergrund "Sicherheitsmechanismen" aktiv, die prüfen ob z.B. ein Bootloader geöffnet wurde oder nicht.

    In den Einstellungen des PlayStores kann man bei Android-Smartphones dann z.B. sehen "Gerät ist nicht zertifiziert".

    Manche App-Entwickler geben vor, dass ihre App auf "nicht zertifizierten" Geräten nicht installiert werden dürfen.

    Daher wird dir die App im PlayStore erst garnicht angezeigt.

    Um das zu umgehen gibt es verschiedene Möglichkeiten. Du könntest die APK z.B. von Drittanbietern beziehen. Die Frage hier aber ist: Wie vertrauenswürdig ist die Quelle dann? Immerhin kann eine kompromittierte App ggfs. persönliche Daten abgreifen und/oder anderweitigen Schaden anrichten.

    Das wiederrum lässt sich teilweise umgehen in dem man auf Lösungen wie den Aurora-Store setzt. Diese App emuliert quasi ein geeignetes Gerät und gibt sich gegenüber dem PlayStore als solches aus. Eine eigentlich für ein Gerät nicht kompatible App kann so unter Umständen dennoch installiert werden. Das funktioniert allerdings je nach Anforderungen der App an das Gerät auch nicht bei jeder App. Außerdem benötigen manche Apps zusätzliche Abhängigkeiten zu den Google-Diensten. Bei Banking-Apps ist das z.B. häufig der Fall, oder eben den Apps der Streaminganbietern. Daher auch die Fehlermeldung bei der manuellen Installation von Aptoide.

    Wenn der Bootloader geöffnet wurde (und offen bleiben soll), stehen aber noch andere Optionen zur Verfügung. So könnte man das Gerät rooten und mittels Magisk-delta in Kombination mit MagiskHide und dem Magisk-Modul "Universal SafetyNet Fix" vor dem PlayStore den geöffneten Bootloader verbergen und ein zertifiziertes Gerät vorgaukeln. Dann sollte die Disney+-App auch wieder auftauchen.

    Wenn du den Bootloader geöffnet bekommen hast solltest du auch das hinbekommen.

    Ansonsten: Bootloader wieder schließen.

    Kann dir leider nicht genau sagen in wie weit das für die Shield anwendbar ist, aber die basiert ja auf Android (TV). Und dafür gibt es verschiedene Ansätze wie man Daten sichern könnte.

    U.a wäre eine Synchronisation der zu sichernden Daten auf ein Backupmedium via FolderSync oder Syncthing denkbar.

    Es gibt aber auch Backup-Apps wie Helium Backup oder SwiftBackup die speziell auf den Anwendungsfall ausgelegt sind. Unter Android TV habe ich da aber keine Erfahrungswerte.

    Was in jedem Fall gehen sollte ist das manuelle Übertragen von Ordnern und Dateien auf einen anderen Rechner via adb z.B. mit der Software adbLink.

    Wenns nur um Kodi geht, dann wie don schon sagte Kodi-Ordner wegsichern. Das ginge auch mit dem Backup-Addon.

    Eine Komplettsicherung der gesamten Daten-Partition (oder auch anderer Partitionen) via TWRP (oder einem anderen Recovery) ist idR nur möglich, wenn der Bootloader zuvor entsperrt wurde damit das Custom Recovery genutzt werden kann. Beim Bootloader entsperren würden dann aber initial alle Daten gelöscht. Das dürfte dich hier also eher nicht weiter bringen.

    Also ich kann nur sagen, dass ich Sponsorblock jetzt schon seit längerem unter Youtube ReVanced und Android nutze. Da hat das bisher wirklich gut funktioniert.

    Gestern Abend konnte ich das dann auch unter Inivdious in Kodi live in Aktion sehen. Bei vier getesteten Videos wurden 3x die Werbeblöcke übersprungen. Das ist für mich zumindest deutlich besser als bei 4 Videos 4x die Werbeblöcke aufgedrückt zu bekommen.