Beiträge von Paul

    In der Standardkonfiguration von systemd-resolved ist das DNSSEC Feature deaktivieren. Das funktioniert soweit recht problemlos und auch zuverlässig. Hatte man es in der Vergangenheit aktiviert, dann war das genau der Punkt, der wohl am meisten Probleme gemacht hat. Und vor allem dann, wenn man die wie von frank_m angesprochene "allow-downgrade" Option gesetzt hatte. Die hatte nämlich oft nicht ganz so zuverlässig funktioniert wie man sich das gedacht hatte (siehe z.B. hier https://github.com/systemd/systemd/issues/32570). Mittlerweile sollten aber auch da diesbezüglich die meisten Bugs (oder sogar alle) behoben sein.

    Ich nutze hier systemd-resolved schon recht lange. Das primär wegen 2 Funktionen, die der normale Resolver nicht kann:

    1. Cache

    2. Split DNS (vor allem in Verbindung mit einem VPN)

    Ich hatte AlmaLinux 10 sowohl auf einem VPS G11 als auch auf einem RS G11 versucht, aber bei keinem konnte die ISO erfolgreich in den Installationsassistenten (Anaconda) booten. Der Mauszeiger wurde zwar eingezeigt, der Hintergrund blieb grau. Das passierte sowohl mit dem offiziellen Netcup ISO aus dem SCP als auch mit einer eigens hochgeladenen ISO. Ich hatte jetzt aber auch wenig Lust mit irgendwelchen Kernel Parametern zu spielen. Ein aktuelles Fedora 42 hingegen bootet erfolgreich in Anaconda. Vielleicht muss man hier auch auf AlmaLinux 10.1 warten. Würde ich aktuell sowieso empfehlen, weil gerade in EPEL doch noch einige Pakete fehlen, die erst mit 10.1 hinzukommen.

    Prinzipiell sollte die CPU das aber unterstützen. Zumal AlmaLinux 10 ja weiterhin x86_64_v2 Pakete baut (im Gegensatz zu RHEL).

    Zitat

    AlmaLinux OS 10 has followed Red Hat’s decision to ship x86-64-v3 optimized binaries by default, but we will also provide an additional x86-64-v2 architecture, allowing users on that older hardware to continue to receive security updates for another 10 years.

    Vielleicht fehlt mir diesbezüglich einfach das Wissen. Wenn ich aber ein solch signifikant höheren Steal Time sehe und dazu noch von anderen lese, daß dies zu hoch sei um zuzugreifen, erwarte ich nicht, daß was ich in meinem Ticket selbst geäußert habe, daß die Ressourcen geteilt werden und gewisser "steal" der Norm entspricht als Antwort zurück ?(

    Da müssen wir auch 2 Dinge unterscheiden. Wenn tab schrieb, dass 50% mal ok waren und das jetzt auf 60% erweitert wurde, meinte er nicht, dass es generell ok wäre, so einen hohen Steal zu haben, sondern dass es für Netcup ok ist, wenn eine Kunden VM aus der (ARM) VPS Serie einen solchen Steal hat und sie bei einer Meldung/einem Ticket diesbezüglich nichts unternehmen werden.

    Generell ist nämlich ein Steal von 50% eigentlich gar nicht ok. Auch schon 30% Steal sind im Grunde zuviel, wenn man die CPU Leistung eigentlich bräuchte. Es geht hier eher darum, ab wann man sich deswegen beim Support melden sollte. Und da sagt Netcup, dass sie erst ab einer gewissen Grenze etwas machen. Im Grunde ist das dann eigentlich auch ok, weil die ARM Server sehr billig sind und man sowas eigentlich erwarten müsste. Für den Preis muss es quasi überbucht sein. Da muss man auch als Kunde Abstriche in Kauf nehmen. Ich habe mir das selbst auch schönreden wollen und dachte, ich kann mit dem ARM Server 30% sparen und trotzdem die gleiche Leistung erwarten. Sogar mehrmals. Aber irgendwann erkennt man dann doch, dass man etwas mehr bezahlen sollte, wenn man schon penibel auf die Leistung schaut.

    Huch? Schlechte Erfahrungen gemacht?

    Leider ja. Ich hatte seit Einführung der ARM Server jetzt mehrere (inkl. BETA). Im Idle war immer alles ok. Aber sobald etwas Load auf die Server kam, ist wirklich bei jedem der Steal immer direkt auf 40-60% förmlich explodiert. Da bringen mir halt die 10 Cores eines VPS ARM 2000 relativ wenig, wenn man sie eh nicht wirklich nutzen kann. Da bleibe ich dann doch lieber bei meinen x86 VPS, die bei exakt gleichem Workload einen Steal von <1% aufweisen und zahle den minimalen Aufpreis mehr. Und da das nicht nur bei einem, sondern allen und das zeitlich verteilt aufgetreten ist, bin ich mit der ARM Serie im Moment generell etwas vorsichtig.

    Im Grunde kann ich es auch verstehen. Der günstige Preis muss ja irgendwo herkommen. 10 Cores für 10,79 €und dann noch 1TB NVME Disk. Da muss man irgendwo Abstriche in Kauf nehmen. Es gibt sicher auch zufriedene Kunden, vor allem wenn man die vielen Cores nicht braucht.

    Wenn man es natürlich streng sieht, dann sollte ein Backup grundsätzlich nie beim gleichen Provider liegen, wo auch die produktiven Daten verarbeitet werden. Ein evtl. gesperrter Kundenaccount würde z.B. den Zugriff auf das produktive und das Backup System sperren. Daher wäre im Falle der VPS Lösung eigentlich ein weiteres Backup erforderlich. Je nach Wichtigkeit des Systems wäre das durchaus denkbar und auch sinnvoll. Man könnte z.B. 2 Mailserver haben, die mittels Dovecot dsync Replikation die Daten synchron halten und gleichzeitig ein Backup in die Storagebox schreiben.

    SnowBerryZ danke für die Info. Bin derzeit in Diskussion mit mir, ob lieber einen zweiten VPS, 1000 ARM G11, oder 'ne Storage Box für das Backup der Mailcow. Preislich macht das keinen großen Unterschied.

    In diesem Fall würde ich sogar eher zu dem VPS tendieren. Dieser hat den Vorteil, dass er im Notfall auch als Backup System live gehen kann, wenn mit dem produktiven System irgendwas längerfristiges nicht mehr funktionieren sollte. Da hat man denn für den gleichen Preis noch einen zusätzlichen Vorteil/Nutzen.

    Ja das stimmt ^^ der ist aber vom Preis mehr an einem "RS 4000 G11" dran, da verwirrt Preis/Leistung was den Namen betrifft

    Ja, definitiv. Das war auch mein erster Gedanke, dass der 2000 Ultra eigentlich nur der normale, "fehlende" RS 3000 ist, den es so im normalen Sortiment gar nicht gibt (mit ein klein bisschen größerer Disk). Aber vermutlich gibt es durchaus eine Zielgruppe dafür. m_ueberall wollte ja ein Produkt mit mehr RAM. Zumindest sein Wunsch wurde erfüllt ^^ .

    Auf Nummer sicher zu gehen ist immer besser. Es muss keine Malware sein. Aber dass so ein Prozess läuft - ohne dass man es will und dann auch noch 100% CPU Load verursacht - ist immer ein Warnsignal. Genaueres wird man erst wissen, wenn man sich den Container (am besten in einer isolierten Umgebung) genauer anschaut. Es ist prinzipiell immer riskant, wenn man fremde Container lädt und laufen lässt. Da helfen einem dann auch die gut gemeinten Sicherheitsvorkehrungen nichts, wenn man als Admin die Malware selbst installiert. Früher hatte man in Linux signierte Repositories/Pakete um genau solche Szenarien so gut wie möglich zu verhindern. Durch die neue Container Welt untergräbt man das diese Konzept halt wieder. Hat alles seine Vor- und Nachteile.

    Zitat

    pg_recvlogical is a command-line tool included with PostgreSQL used for managing and consuming logical replication slots. It facilitates the streaming of changes from a logical replication slot, enabling real-time data capture and consumption. pg_recvlogical acts as a consumer of data, receiving changes from the replication slot and outputting them to a specified file or standard output.

    Dass dieser Prozess 100% CPU nutzen soll, ist etwas seltsam. Zumindest dann, wenn es sich tatsächlich um den genannten Postgres Prozess handeln sollte. Welche Container laufen denn alle bei dir? Es könnte sich natürlich auch gut um Malware handeln, die sich hinter diesem Prozess versteckt (und sich nur so genannt hat um nicht aufzufallen). Versuche hier wirklich mal den Container und den Prozess zu lokalisieren und genauer zu untersuchen. Falls dein System wirklich kompromittiert wurde, solltest du das auf keinen Fall einfach so weiter betreiben. Versuche also wirklich so schnell es geht da Klarheit zu schaffen. Vielleicht bringt ja auch irgendein Container oder ein Nextcloud Plugin eine integrierte Postgres Installation mit. Du kannst dir ja auf dem Host alle Prozesse mal anschauen und überprüfen, ob da noch andere Postgres Prozesse laufen. Müsste ja eigentlich, wenn alles mit rechten Dingen zugehen sollte.

    Ah, Fedora hat sie in den Repos als aktuellste Version. Narf.

    Hah, tatsächlich. Dabei laufen fast alle Server bei mir sogar mit Fedora (aber keiner davon nutzt Apache) ^^. Aber dass Fedora aktuellere Pakete als Archlinux hat, sieht man auch nicht alle Tage.

    Da nicht einmal Archlinux diese Version bisher in seinen Repos hatte, dürfte die wohl glücklicherweise eigentlich nirgends im Einsatz sein (es sei denn man hat Apache selbst kompiliert).

    Der Wert von 2010 Punkte bei dem "AMD EPYC 7513" ist wirklich beachtlich! Habe ich so nicht nirgends gesehen :/

    Auf den zweiten Blick hat der EPYC 7513 aber auch einen Grundtakt von 2,6GHz. Merkt man in der Praxis nicht wirklich, aber bei Benchmarks deutlich. ;) Die 10-15% lassen sich damit völlig problemlos erklären. Das ist ja auch der Grund, warum Desktop PCs bei solchen Benchmarks deutlich besser abschneiden, obwohl sie nur ein Bruchteil einer Server CPU kosten. Nicht ohne Grund sind ja gerade für Gaming Server Desktop CPUs wie der Ryzen interessant und werden auch bei einigen Providern entsprechend angeboten.

    Der EPYC 9643 hat einen Grundtakt von 2,25Gz und einen Turbo Boost von bis zu 3.7 GHz. Gerade bei Benchmarks kann so ein Boost für deutlich bessere Werte sorgen. Netcup hat ja in der Vergangenheit schon bestätigt, dass sie den Turbo Boost durchreichen. Da sich diesen aber alle VMs auf dem Node teilen müssen, ist es oft Glückspiel, wer ihn gerade erhält und ob er überhaupt in seinem maximalen Wert erreicht wird. Es gibt noch einen All Core Max Wert von 3.1 GHz.

    Wenn ich also Single Core Werte lese, die an 2000 oder darüber sind, dann würde ich mal stark behaupten, dass hier von dem Turbo Boost profitiert wurde. Je weniger auf dem Node gerade los ist, desto höher ist ja die Wahrscheinlichkeit, dass man davon profitiert. Realistisch sind sicherlich Werte von 1600-1800, die durch den Grundtakt erreicht werden. NIchtsdestotrotz sind das immer noch sehr gute Werte, die 50% über denen vorheriger Generationen liegen. Ich konnte hier jetzt auch noch keinen Fall sehen, wo das deutlich unter 1600 gefallen ist.

    An der reinen CPU Leistung kann man Netcup hier wohl keinen Vorwurf machen. Das passt soweit. Die Disk Performance ist dann natürlich ein ganz anderes Thema. Hier wird Netcup schon irgendwie dafür sorgen, dass die Leistung gerecht verteilt wird. Sie machen halt auch keinerlei Garantien oder Versprechungen, welche IO Leistung ein RS erwarten kann. Daher ist das immer ein schwieriges Thema, weil man als Kunde zwar unzufrieden sein kann, aber keinen wirklichen Punkt hat, auf den man sich berufen kann. Es wird nur die Größe in den Leistungsdaten erwähnt.

    Auf der anderen Seite sind die 4k Werte besser. Insgesamt scheinen RS also zwar niedrigere, dafür aber konstantere Werte zu haben, die weniger schwankungsanfällig sind und auch unter Last noch die gleiche Leistung bringen.

    Disk Benchmarks sind immer noch so eine Sache für sich. In der Praxis wird man nämlich gar keinen Unterschied feststellen können zwischen 500MB/s und 2GB/s, weil man solche Brandbreiten nie wirklich erreichen wird. Das gibt ja allein die Netzwerk-Anbindung gar nicht her. In der Praxis sind ganz andere Werte wichtig. Z.B. die Latenz oder IOPS. Da merkt man dann wirklich, ob die Applikation langsam oder schnell reagiert.

    Ich habe mal einen VPS mit dem neuen RS Ultra vergleichen. Die durchschnittliche Brandbreite war bei beiden in etwa gleich. Dafür hatte der RS weniger Schwankungen in der Latenz (3ms vs 13ms). Hier kommen dann auch Werte wie iowait zum Tragen, die vermutlich beim RS besser sein werden und vor allem in Last Situationen weniger stark nach oben hin ausreißen.

    Ich will das jetzt auch nicht schönreden und am Ende muss das jeder für sich selbst entscheiden, ob er mit der Leistung zufrieden ist oder nicht. Ich möchte nur den Gedankengang teilen, dass für die tatsächliche Leistung die Bandbreite nicht zwingend entscheidend ist und einem ein falsches Bild vermitteln kann. Ich selbst mache meistens den Test, dass ich einfach die Applikation installiere und mir das Verhalten dort anschaue. Ich vergleiche dann z.B. die gefühlte Ladezeit und Werte wie TTFB. Sind diese dann auch schlechter, dann wäre ich auch unzufrieden ;).

    Doch, soweit würde ich mich schon aus dem Fenster lehnen. Diese Phishing Kampagne richtig sich ganz explizit an Netcup Kunden. Ob da auch vereinzelt Nicht-Netcup-Kunden betroffen sind, kann sicherlich sein. Aber hier hat sich schon jemand Gedanken gemacht, wen er hier anschreiben muss. Das ist nicht die übliche Spamliste von Mailadressen, weil ein Service Provider ein Datenleck hatte. Da wurde schon ganz gezielt nach Domains gesucht.