Das längste Thema

Grandios: dsync entfernt im Backupmodus plötzlich die Subscriptions von geteilten Ordnern, weil sie angeblich ungültig sind. Zur Krönung nicht nur am Ziel, auch bei der Quelle!

Das System lief bis vor wenigen Tagen mit Debian Jessie. Das Problem tritt zuverlässig ab Stretch auf, bei Buster verhält es sich genauso falsch. Ich habe mir jetzt mal mit einem Downgrade des dovecot-core Pakets geholfen, da ich auf diesem System sowieso nur dsync/doveadm ohne Daemon brauche.

Ich konnte leider noch nicht herausfinden, was sich im Code oder der Standardkonfiguration dazwischen geändert hat. Da es sich selbst bei zwei 2.2.x Releases unterschiedlich verhält, ist es etwas seltsam.

Manchmal ist man betriebsblind.

Ich war gerade eben besorgt, dass auf einem Server fail2ban nichts mehr im log anzeigt und auch nix mehr gebannt wird.

Im System gesucht, woran es denn nun liegen könnte, nichts gefunden, bis es mir dann wie Schuppen aus den Haaren fiel:

Gab ja nix mehr zu bannen. Ich hatte ja auf diesem Server vor kurzem die PasswordAuthentication abgeschaltet.

Also alles gut. Nur etwas Zeit bei der unnötigen Suche nach etwas verschwendet, das nicht da war...

Ich habe gerade mal so drüber nachgedacht... ZFS ist ja an sich ne nette Sache und wird deswegen auch immer mehr Richtung Desktop portiert (siehe Ubuntu).

Aber es ist auch kein Geheimnis, dass ZFS ohne ECC RAM eigentlich ein ziemliches Abenteuer ist... wenn man jetzt mal bedenkt, wie hoch die Wahrscheinlichkeit ist, dass Desktop PCs mit ECC RAM ausgestattet sind, macht mir das irgendwie schon Bauchschmerzen.

Ich meine ich für meinen Teil nutze ZFS in meinem Homeserver auch ohne ECC RAM, aber ich habe hier auch nur ein paar simple Container oder VMs drauf. Nichts hochkritisches oder wichtige Daten. Wenn da mal was flöten geht, restore ich halt schnell ein Backup und gut ist...

Auf Desktopsystemen werden aber in der Regel sehr wichtige Daten persönliche Daten gespeichert. Sicher kann man dann auch hier sagen "Kein Backup, kein Mitleid" - aber wenn das OS potenziell unsichere Sachen auf ahnungslose Enduser loslässt... hmm. Ich weiß nicht so ganz, was ich davon halten soll.

Zitat von whoami0501

aber wenn das OS potenziell unsichere Sachen auf ahnungslose Enduser loslässt.

wenn ein ahnungsloser Enduser Linux einsetzt, dann passt aber was nicht ...

wobei auch bei Windows gibt es Dinge die sollte man nur aktivieren,

wenn man z,B. eine USV hat, und derartiges Equipment findet man bei Endusern eher selten ...

und auch in Firmenumgebungen sind die Arbeitsplatzrechner eher selten an USV-Stromkreise angebunden;

Zitat von mainziman

wenn ein ahnungsloser Enduser Linux einsetzt, dann passt aber was nicht ...

Also die Desktop Varianten sind durchaus für Normalos ohne viel Ahnung gedacht.

Und seitdem ich gestern mal wieder ne Win10 VM hinter einem MITM hatte, weiß ich auch, dass das gut so ist.

Zitat von whoami0501

Aber es ist auch kein Geheimnis, dass ZFS ohne ECC RAM eigentlich ein ziemliches Abenteuer ist... wenn man jetzt mal bedenkt, wie hoch die Wahrscheinlichkeit ist, dass Desktop PCs mit ECC RAM ausgestattet sind, macht mir das irgendwie schon Bauchschmerzen.

Das ist eine Aussage, die ich noch nie verstanden habe.

Natürlich ist ECC RAM besser, aber solche Sätze lesen sich ja fast so, also ob ohne ECC RAM z.B. ext4 sicherer, besser wäre als ZFS.

Ich kenne die Internas von ZFS nicht, aber ich kann mir nur schwer vorstellen, dass ein Bitflip schlimmere Folgen haben sollte als bei ext4,...

Also müsste es doch eher heißen "es ist auch kein Geheimnis, dass ein Computer ohne ECC RAM eigentlich ein ziemliches Abenteuer ist."

Liege ich da falsch ?

Zitat von Andi22

Das ist eine Aussage, die ich noch nie verstanden habe.

Natürlich ist ECC RAM besser, aber solche Sätze lesen sich ja fast so, also ob ohne ECC RAM z.B. ext4 sicherer, besser wäre als ZFS.

Ich kenne die Internas von ZFS nicht, aber ich kann mir nur schwer vorstellen, dass ein Bitflip schlimmere Folgen haben sollte als bei ext4,...

Also müsste es doch eher heißen "es ist auch kein Geheimnis, dass ein Computer ohne ECC RAM eigentlich ein ziemliches Abenteuer ist."

Liege ich da falsch ?

Naja... ZFS macht schon ein bisschen mehr im RAM als ext4, meine ich.

https://pthree.org/2013/12/10/zfs…ld-use-ecc-ram/

Andi22

- Will ZFS and non-ECC RAM kill your data?

- There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem.

zum Thema ZFS an Hand der Links von vmk

Zitat

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

welche Art von Checksumme wird hier berechnet? eine Art CRC od. ECC od. ein ganzer Hash we z.B. SHA256?

und ist diese Checksumme bei z.B. Backupprogrammen direkt verwertbar? im Sinne von Checksumme geändert, ergo Datei geändert sichere sie;

Zitat

With ZFS, if you are just reading from disk, a failing bit in memory (when not using ECC RAM) will potentially corrupt the file on disk.

hier würde ich aber meinen das ein derartiges Verhalten grob fahrläßig fehlerhaft ist;

was derartiges anbelangt, ist z.B. bei NTFS dass bereits bei lesendem Zugriff das LastAccess-Datum aktualisert wird, auch nciht ohne,

aber der File selbst wird dabei nicht angetastet; die generelle Aktualisierung vom LastAccess-Datum kann per Registry-Eintrag deaktiviert werden;

ZFS und btrfs haben für alles (Blöcke, Metadaten) Checksummen aktiv. ZFS recovered im RAID dann halt den validen Chunk und repariert im Hintergrund automatisch den defekten Chunk.

- https://openzfs.github.io/openzfs-docs/B…/Checksums.html

- https://btrfs.wiki.kernel.org/index.php/FAQ#…es_Btrfs_use.3F

Zum Glück nutzt hier niemand Windows, denn dort gibt es so was ReFS: https://www.iperiusbackup.net/en/refs-vs-ntf…on-when-to-use/ . Nicht vorzustellen, eine Firma würde Windows für Dateien einsetzen. Die gehen massenweise pleite!!!

Zitat von whoami0501

Naja... ZFS macht schon ein bisschen mehr im RAM als ext4, meine ich.

https://pthree.org/2013/12/10/zfs…ld-use-ecc-ram/

So wie ich es verstehe, geht es in dem Artikel darum , dass ECC RAM sinnvoll ist, aber nicht darum, warum bei non ECC RAM ZFS schlechter ist als z.B. ext4

Zitat von vmk

- Will ZFS and non-ECC RAM kill your data?

- There's nothing special about ZFS that requires/encourages the use ofz.B. ext4 ECC RAM more so than any other filesystem.

Danke, genau das meine ich.

Der erste Link bringt ja sogar gute Argumente, warum man bei non ECC besser ZFS verwenden sollte anstatt einem FS ohne Checksummen.

Den 2ten Link hab ich nicht wirklich gelesen, da ich gerade keine Zeit habe den ganzen Thread zu lesen, aber Dein verlinkter Beitrag sagt ja auch genau das "There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem"

Ich glaube wir sind uns alle einig, dass ECC RAM besser ist.

Mir geht es mehr um die Aussagen, die implizieren, dass wenn man kein ECC RAM hat, man besser ext4 oder NTFS o.ä. nehmen sollte.

Zitat von Andi22

Mir geht es mehr um die Aussagen, die implizieren, dass wenn man kein ECC RAM hat, man besser ext4 oder NTFS o.ä. nehmen sollte.

wenn ich die Teile, welche ich da oben zitiere betrachte, mag das so sein, aber das ganze ist ja mehrschichtig;

die untere Schicht ist der Massenspeicher - SSD/HDD

de mittlere Schicht ist das RAM und die CPU

die obere Schicht ist die Definition sowie Implementierung des Filesystems im OS mit seinen APIs

de oberste Schicht ist die Anwendung selbst

wenn eine Anwendung per API einen File lesen will (CPU/RAM), dann spielt hier natürlich das Filesystem eine Rolle,

es macht hier natürlich einen Unterschied, ob tatsächlich wirklich nur gelesen wird, od. ob unsinnigerweise, nur weil

da was unpassendes - Checksummenberechnungen ergeben das - Inhalte der Platte/SSD verändert werden;

wer sagt, ob das 'unpassende' auf Grund von Bitfehlern im RAM - weil kein ECC - od. nicht doch tatsächlich von der Platte kommt?

Hat jemand Erfahrung, ob bzw. wie stark sich eine große Anzahl blockierter IPs (>1000) auf die Performance eines Servers auswirkt?

Bei jedem Zugriff muss ja abgefragt werden, ob er erlaubt ist.

das ist eine Frage, wo diese IPs blockiert sind, und vor allem wie;

am wenigsten belastend f. den Server ist es, wenn Pakete von diesen IPs

mittels IPTables einfach geDROP'd werden

Es sind automatische Einträge von fail2ban

Zitat von aRaphael

Hat jemand Erfahrung, ob bzw. wie stark sich eine große Anzahl blockierter IPs (>1000) auf die Performance eines Servers auswirkt?

Bei jedem Zugriff muss ja abgefragt werden, ob er erlaubt ist.

Wenn die Regeln in einer Kette landen, die nur bei neuen Verbindungen (-m state --state NEW -j mychain) abgearbeitet werden oder aufgebaute Verbindungen (-m state --state ESTABLISHED,RELATED -j ACCEPT) bereits vorher abgefangen werden, hält es sich wohl in Grenzen. Das setzt halt voraus, dass man Connection-Tracking nutzt, was auch Ressourcen belegt.

Wenn es wirklich sehr viele blockierte IP-Adressen sind oder Du mit vielen neuen Verbindungen zu tun hast, solltest Du Dir vielleicht mal ipset ansehen. Ob es dafür vorgefertigte Konfigurationen für fail2ban gibt, weiß ich nicht. Meiner Meinung nach sind 1.000 Regeln für den Kernel noch kein Problem, wenn es sich nicht um uralte oder extrem schwache Hardware handelt.

Danke für die Hinweise

Zitat von killerbees19

Wenn es wirklich sehr viele blockierte IP-Adressen sind oder Du mit vielen neuen Verbindungen zu tun hast, solltest Du Dir vielleicht mal ipset ansehen.

Ich persönlich würde diesen Server lieber von Passwort-Auth auf Key-Auth umstellen und das Login über Passwort ganz abschalten, aber davon muss ich die User noch überzeugen.

Wenn es geht: ssh Server nur auf ipv6 schafft Ruhe.

Ich habe mir gerade nochmal das Thema i5-7600K "abwürgen" angenommen...

Ich versuche gerade per UEFI (Gigabyte Board) eine maximale Clock Rate für die CPU vorzugeben, aber ich bekomme es nicht hin. Egal ob Windows oder Linux, wenn man Leistung zieht, lässt der Governor die CPU auf 3,8 GHz hochtakten...

De facto brauche ich das ganze nur unter Linux - kann man da irgendwie dem Governor eine maximale Taktrate vorgeben? Also ohne ihn fix zu setzen. Also irgendwie sowas wie Ondemand, aber nur bis x GHz. Geht das?

Oder - das wäre natürlich optimal: Weiß jemand, wie man so ein Limit in Gigabytes UEFI durchsetzt?