Jetzt bin ich auch endlich mal in den Genuss von einem G9 Server gekommen
Wirklich profitieren kann ich davon nicht, aber hohe Zahlen sind toll.
Das schreit doch nach dem Einrichten eines Log4J-Honeypots? Schnell noch eine passende Domäne registriert ("largest-bitcoin-vault.com"), formlos auf Twitter beworben ("My friend says they're using log4j and he wants to move his account elsewhere ASAP 
") und schon kann die Bandbreite in wenigen Tagen voll ausgenutzt werden…
Cool. Die Medien haben angefangen Open Source Software dafür zu blamen, was gerade bei log4j passiert.
Ja, mit einem Exchange Server kann so was Gravierendes nicht passieren...
Gibt's schon ein Netcup-Tutorial, welches aufzeigt, wie man log4j durch den Exchange Server ersetzen kann? Frage für einen Freund, der das dringend benötigt…
Hier zunächst einmal die aktuellen Mail-DNS-Einstellungen für meinedomain.de:
Code@ TXT v=spf1 mx a include:_spf.webhosting.systems ~all @ MX 10 mx2f8c.netcup.net […][…] DMARC report von Google […]
Code[…] <source_ip>209.XX.XX.XX</source_ip> […]
Kurze Nachfrage: Ist 209.XX.XX.XX die/eine der Domäne meinedomain.de zugeordnete IPv4-Adresse?
Ansonsten ist diese weder indirekt durch _spf.webhosting.systems noch durch mx2f8c.netcup.net abgedeckt und erklärt den SPF-spezifischen Fehler.
DKIM bezieht sich auf die versendete E-Mail selbst und ein Fehler lässt sich eigentlich nur dadurch erklären, dass beim Versand bei Nutzung dieser IP-Adresse etwas mit der Signierung falsch läuft. Die Ursache lässt sich ggf. dadurch ermitteln, dass man zwei E-Mails mit demselben Inhalt über verschiedene IP-Adressen (genauer: einmal via die beanstandete IPv4 209.XX.XX.XX und einmal nicht von dort) an eine eigene E-Mail-Adresse schickt, welche diese (immer) entgegennimmt.
Könnte man sich die möglichen Probleme mit dem Datei/Bootsystem evtl. ersparen, wenn man das alles nicht mit rüberkopiert?
Also beim klonen die Bootpartition auf dem Zielserver unangetastet lässt und auch nicht die bootrelevanten Verzeichnisse (/etc/mdadm, /etc/fstab, /boot ...) nicht überschreibt?
Auf dem Zielserver ja schon ein identisches, bootfähiges Minimalsystem installiert.
Man könnte alle Dateien mit UUID-/partitionsspezifischen Inhalten (/etc/fstab, /etc/crypttab, /etc/mdadm, …(?)) temporär mit "chattr +i" vor einer Modifikation schützen, wenn diese keiner Ergänzung oder Anpassung bedürfen, ja.
Ob man um ein abschließendes "update-initramfs" herumkommt, hängt davon ab, was dort abgelegt ist (lässt sich durch Vergleich der Inhalte zweier Abbilder, insbesondere wenn sie dieselbe Kernelversion verwenden, feststellen – siehe hier), obwohl ich diesen Schritt nicht für sonderlich problematisch halte und er gleichzeitig einen Test einer Operation darstellt, welche in Zukunft auf dem Zielhost (hoffentlich) sowieso mehrmals durchlaufen werden wird.
Allerdings sollte man nicht vergessen, dass UUID-Kennungen auch an anderer Stelle* hinterlegt sein können (vergleiche MariaDB-Galera-Cluster, GlusterFS), abgesehen von bislang nicht erwähnten IP-Adress-/Namensreferenzen (welche man partiell durch Split-Horizon-DNS-Definitionen für bspw. "vpn-thishost.local.domain.tld" bündeln/minimieren, aber wohl nicht umgehen kann). ["Ich mach' das mittels Ansible"-Posting in 3, 2, 1… 
]
* insbesondere auch in Kopie auf anderen Rechnern!
[…] im anschluß am ziel-system im recovery im chroot den grub installieren
Codegrub-mkdevicemap -n grub-install /dev/sda grub-install /dev/sdb[…] und zu guter letzt initramfs und grub aktualisiern
Codeupdate-initramfs -u -k all update-grub2
Ich glaube, vor dem letzten Schritt sollte man noch einmal einen Blick in /etc/fstab (und ggf. /etc/crypttab) werfen, ob da irgendwelche Zeilen mit UUID auftauchen – Bin mir nicht sicher, ob die vorangehenden Schritte die korrekten Werte eintragen, denn deren Generierung geschieht ja bei der Partitionierung/Dateisysteminitialisierung, die vor Übernahme aller Dateien erfolgte.
Na, dann kann ich mich ja nun wieder aus dem Forum zurückziehen. Hatte mich ja nur deshalb hier angemeldet um ein Ziel vor Augen zu haben.
Kann ich nicht verantworten und werde alle XX+ Likes automatisiert wieder rückabwickeln lassen. 
Grundsätzlich wollten wir nicht über 5 Euro gehen, aber vermutlich muss man wohl doch tiefer in die Tasche greifen. Oder aber Netcup stellt sein 8000er Tarif mal so ein, das Leute die den Server runter ziehen begrenzt.
Ein "normaler" RS1000G9 (den es mit ein wenig Glück über den Netcup-Weihnachtskalender ggf. noch verbilligt gibt) sollte dies stemmen können und auch nicht mehr als ein Webhosting 8000 kosten (dank 30-Tage-Rückgabemöglichkeit dank Zufriedenheitsgarantie wäre auch eine Zeitspanne für direkte Vergleiche möglich), allerdings muss dann die Administration, insbesondere aber die Absicherung des Rootservers hierfür gestemmt werden können.
Same here.
pamsel hätte so davon profitieren können... 
https://www.netcup.de/bestellen/produkt.php?produkt=2826 20€ für ein Notizbuch?
Wenn man es nach Rückkehr aus dem Homeoffice (wo es keiner sieht) in der Firma verwendet, hat man damit aber die Chance, sich mit dem Fremdlogo ganz schnell beliebt zu machen… (Für die Videokonferenzen im Homeoffice wäre ein Netcup-Hoodie wahrscheinlich besser geeignet; das induziert dann subtil die stillschweigende Frage beim Vorgesetzten, ob man noch uneingeschränkt für die ursprüngliche Firma arbeitet. )
Linktip zum Thema: Overemployed
Zack Zugangsdaten zum CCP & einem Server gefunden...
Sharing is caring… 
Kann ich leider nicht lesen, die wollen Daten in die USA übermitteln.
Dafür gibt es ja archive.{is,md,fo} …
Gleichzeitig gibt DDR5 in der spec ECC on-chip vor, weil die strukturen einfach zu eng und klein werden (leckströme).
Dazu gibt es übrigens einen interessanten Beitrag von Ian Cutress: "Why DDR5 does NOT have ECC (by default)".
ein neuer Terminus f. die Steigerung vom Serverhording; was wäre hier der Superlativ?
Rechenzentrumhoarding.
Spricht eigentlich irgendwas dagegen, ZFS-Snapshots an einen ZFS-Pool zu senden, der über iSCSI eingebunden wird? Abgesehen von der unsinnigen Tatsache, dass die LUNs auf einem ext4 in einem RAID5 liegen und das iSCSI-Target keinen ECC-RAM hat.
Abgesehen von der Tatsache, dass die Synology DiskStation kein ECC-RAM hat, dürfte sich das genannte Szenario nicht (sonderlich*) von dem unterscheiden, in welchem man ZFS in KVM-Instanzen bei Netcup (insbesondere auf einem Storage-RS) betreibt. Suboptimal wegen des RAID-Arrays, aber möglich. (Wichtig ist hier, dass die DiskStation selbst zu keinem Zeitpunkt mit einem eigenen ZFS-Treiber auf den ZFS-Pool zugreift; das sollte normalerweise der Fall sein, wenn die entsprechenden Platten/Partitionen für iSCSI-Targets verwendet werden, ich würde mich dessen aber explizit im Vorfeld versichern.)
EDIT: *Wenn hier nochmal eine ext4-Schicht dazwischen liegt (Nutzung virtueller Blockgeräte), ist das natürlich ein Unterschied, welcher nochmals den Durchsatz negativ beeinflusst. Bleibt immer noch machbar, viel umständlicher (=mehr Overhead) geht dann aber auch nicht mehr. Das wäre für mich der Punkt, zu überlegen, ob ich wirklich derartig viele Snapshots auslagere und insbesondere auch regelmäßig von dort restauriere, dass sich ein derartiger Pool rentiert, oder ob ich dann nicht besser die zfs send/recv-Streams via tar o.ä. auf einem anderen Dateisystem ablege/serialisiere wie bei Cloudspeicher-Anbietern, die keine ZFS-Unterstützung bieten. In letzterem Fall ist natürlich eine zusätzliche Toolchain und ggf. genügend Platz für einen Restore-Vorgang im Originalpool einzuplanen. Das ursprüngliche Szenario oben ist also eindeutig einfacher und erlaubt die Ausnutzung aller ZFS-Merkmale (inkrementelle Sicherung, redundante Speicherung von Datasets, …).
spätestens wenn man mehrere Domains hat, ist das sogar unmöglich;
Entweder (a) mehrere IP-Adressen verwenden oder (b) einen Mailserver mit einer IP-Adresse für mehrere Domänen verwenden? Wenn man "legitimerweise" Mailserver bei externen Dienstleistern bspw. via m____n.m______.org über MX-Einträge referenzieren kann, sollte das auch mit einer eigenen "Mail-Domäne" möglich sein.
Wird so richtig pikant mit Vollverschlüsselung […]
Gemeint ist hier ja hoffentlich wohl die Vollbitverschlüsselung…
Eine Frage habe ich allerdings noch an diejenigen hier, die sich mit ECC-RAM auskennen: […]
Ist alles Hardware-/Chipsatz-abhängig, vgl. How do I get notified of ECC errors in Linux? (Am besten einmal von oben nach unten durchgehen und ggf. Begriffe notieren, wenn es keine Erklärungslinks zu diesen dort gibt.)
aRaphael und des Blech bleibt dabei des selbe?
Das (sonstige) Blech bestimmt, aber nicht die DIMM-Riegel…
Das sieht ja fast vielversprechender aus, auch wenn ich nicht weiß, was rum Ding in maintenance seht
Ist denn sichergestellt, dass die Konfiguration der Container-Instanz vollständig ist (aus den obigen Angaben nicht ersichtlich)? Da gibt es ja einige Umgebungsvariablen und Abhängigkeiten:
Note that Redash depends on Redis & PostgreSQL to run, which are not included in the image.
Ich habe ja schon öfter gelesen, dass zfs ohne ECC-RAM nicht empfehlenswert ist.
Fürs Protokoll: Das ist überbewertet*. ECC-RAM ist immer empfehlenswert, aber es geht auch ohne. Auf mehreren NUC/SBC läuft ZFS ohne ECC-RAM seit Jahren einwandfrei. Die Argumentation ist, dass ZFS intern mehrere Puffer verwendet, sodass die Gefahr von Bitfehlern beim Umkopieren größer sei als bei anderen Dateisystemen. Um dieses Risiko zu verringern, gibt es ein auch Flag, welches ich auf obigen Rechnern verwende:
# see https://www.csparks.com/BootFedoraZFS/index.md
# enable the unsupported ZFS_DEBUG_MODIFY flag which is supposed to mitigate (but not eliminate) the risk of using ordinary memory instead of ECC memory
options zfs zfs_flags=0x10*analog zu der "Albtraumsituation", dass ein existierender HW-RAID-Controller nicht im IT(=Pass-through)-Modus betrieben werden kann (vgl. VPS-/RS-basierte Installationen)