Beiträge von Paul

Zitat von ASS

Das ist m.E. auch garnicht der Fall.

Die Mails gehen einfach wahllos an eine beliebige Liste von Domainnamen.

Ich glaube ihr interpretiert da viel zuviel Intelligenz hinein...

Ja, das hat vermutlich gar nichts damit zu tun. Zumal halt auch Domains betroffen sind, bei denen Netcup gar nicht der Registar sind. Aber irgendwoher muss diese Liste ja kommen. Die Domains fallen ja nicht vom Himmel. Zumal die ja alle expliziten Zusammenhang mit Netcup haben. Die Domains findet man ja nicht einfach gerade mal so zufällig, nur weil der A Record zufällig auf eine Netcup IP auflöst.

Es würde mich ja nicht wundern, wenn dafür sogar eine KI im Einsatz war, die als Prompt die Aufgabe bekommen hat, Domains zu suchen, deren Record auf eine Netcup IP auflöst .

Zitat von mango

RS 1000 G11 Ultra NUE FJUL25

Auch gerade laufen lassen, sieht solide aus, nur von Disk Speed hätte ich mir mehr erwartet, oder ist das normal bei den aktuellen RS Servern? Meine VPS haben hier teils das 3 fache an Disk Speed 🤔

Ich würde mit den Benchmarks noch ein wenig warten. Im Moment werden ja sehr viele neue Server provisioniert, was einen nicht ganz üblichen Workload auf den Nodes erzeugt. Viele VM Images werden erstellt, Image Installationen durchgeführt. Das kann durchaus (vor allem Disk) Performance kosten. Das erklärt auch, warum die CPU Benchmark ganz gut ist (die Kerne sind ja dediziert), aber die physischen Disks sind ja weiterhin shared. Das wird sich sicher die nächsten Tage beruhigen, wenn sich der Workload normalisiert. Dann kann man das ja nochmal in Ruhe testen.

Zitat von tab

Heute sind meine Postfächer weitgehend verschont geblieben, weil die Spammer wohl einen Fehler mit dem Reverse DNS gemacht haben. 60 Zustellversuche, alle aus diesem Grund abgewiesen und somit gleich ab mit der IP in das fail2ban Jail. Ok, etwas mehr als die Hälfte davon wäre sowieso abgewiesen worden, weil die Adresse nicht existiert. Aber das Jail wäre ihnen erspart geblieben.

Ja, hier genauso:

NOQUEUE: reject: RCPT from unknown[89.144.5.230]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [89.144.5.230]; from=<newsletter@zapef.com> to=<webmaster@domain.tld> proto=ESMTP helo=<zapef.com>

Was mich vor allem irritiert, ist der Punkt, dass die Mails an Domains adressiert sind, die im Grunde völlig inaktiv sind. Da gibt es weder eine Webseite, noch eine Mailbox, noch ist diese sonst wo irgendwo öffentlich vertreten (nur die Standard RFC Adressen für abuse, postmaster & Co und daher einen mx Eintrag). Die wurden von mir einfach schon mal registriert um evtl. später mal genutzt werden zu können. Da wundert es mich schon ein wenig, wie diese auf die Liste gekommen sind. Einfach mal so kann man ja nicht mal eben alle Domains abfragen, die ein Registrar verwaltet (zumindest nicht ohne internen Zugriff). Auch sind die Nameserver nicht die gleichen. Einige Domains sind bei Netcup, andere bei Cloudflare und eine auch bei desec. Damit hängt es also auch nicht zusammen. Schon etwas merkwürdig.

Aber Vorsicht. Sobald man den Rang eines Profis erreicht hat, ist es verboten, Anfängerfragen zu stellen oder im Forum mit fehlerhaften Antworten aufzufallen. Da kennt das interne Netcup Tribunal dann keine Gnade mehr. Weiterhin hat man sich damit dann automatisch verpflichtet, eine gewisse Anzahl an Servern auf Reserve zu halten. 2 sollten es mindestens sein (Paragraph 4a der Serverhoarder)!

Das mit dem UEFI vs. Bios klingt etwas seltsam. Normalerweise sollte sich so ein Flag ja bei der Migration nicht einfach so aktivieren oder deaktivieren. Hier kannst du ja definitiv mal ins Rettungssystem booten und dir mal die Partitionstabelle anschauen (z.B. mittels fdisk -l). Dann siehst du ja direkt, ob es überhaupt eine "EFI System" Partition gibt (ein eindeutiges Zeichen, ob UEFI vorher aktiv oder deaktiviert war).

Deine LUKS Partition kannst du im Rettungssystem dann mittels cryptsetup open /dev/sdx $NAME öffnen.

Zitat von KB19

Falls irgendwer ähnliche Beobachtungen gemacht hat, gerne melden.

Ich habe das hier kurz mal getestet (Extern --> VPS in VLAN ID 100): IPv6 scheint gut zu sein. IPv4 scheint tatsächlich ein paar Probleme zu haben. Ich beobachte es mal weiter.

IPv4

--- Ping-Statistiken ---
74 Pakete übertragen, 71 empfangen, 4.05405% packet loss, time 73203ms
rtt min/avg/max/mdev = 9.287/10.329/13.663/0.739 ms

IPv6

--- Ping-Statistiken ---
102 Pakete übertragen, 102 empfangen, 0% packet loss, time 101149ms
rtt min/avg/max/mdev = 9.149/10.250/17.120/0.952 ms

Edit: Ich korrigiere meine obige Aussage ein wenig. Die Probleme treten jetzt auch mit IPv6 auf. Sowohl ausgehend als auch eingehend.

IPv6 (ID 161 --> ID 100)

--- Ping-Statistiken ---
60 Pakete übertragen, 58 empfangen, 3.33333% packet loss, time 60429ms
rtt min/avg/max/mdev = 0.413/0.536/0.748/0.069 ms

Wie lange sollen die Server denn mit Debian 9 laufen? Ich frage nur deshalb, weil es nicht unüblich ist, dass Server aufgrund von Hardware Defekten oder Migrationen gerne mal verschoben werden. In den meisten Fällen auf neuere Hardware. D.h. nur weil es jetzt mal funktioniert, könnte sich das in Zukunft schnell mal ändern und zu plötzlichen Ausfällen führen. Ist das ein Business-kritischer Service, dann sollte man dieses Risiko unbedingt auf dem Radar haben - vor allem, wenn ein spontanes Upgrade nicht möglich ist. Je länger der geplante Einsatz ist, desto höher wird auch das Risiko. Bei einer kurzfristigen Testinstanz würde ich mir jetzt keine all zu große Sorgen machen, aber es klingt halt schon eher danach, als ob das ein längerfristiges Projekt werden dürfte.

Debian 9 ist aus 2017. DIe Hardware, die aktuell Einsatz findet, ist deutlich jünger und wird daher von dem alten Kernel in Debian 9 nicht unterstützt (daher auch die Kernel Panic). Eine Shared Umgebung ist für solche Zwecke vermutlich nicht die richtige Wahl. Oder aber man baut sich seinen eigenen Kernel, den man irgendwie in Debian 9 zum Laufen bekommt. damit es auch auf neuerer Hardware läuft.

Aber um noch mit einen konstruktiven Vorschlag zu enden: Es gibt bei einigen anderen Anbietern (OV* aus Frankreich oder HE aus Deutschland) alte Bare Metal Server zu recht günstigen Preisen. Auf denen sollte ein Debian 9 recht problemlos laufen. Aber von einem VPS würde ich in diesem Zusammenhang wirklich abraten. Da gibt es dann auch nicht das Risiko einer Migration auf neuere Hardware.

Zitat von tab

Ist doch eh alles der selbe Verein.

Tatsächlich. Ich wusste zwar, dass Stra** zu ION** gehört, aber dass darüber auch noch das Vereinte Internet ist, hat ich bis dato tatsächlich gar nicht auf dem Schirm. Dann macht das ja doch Sinn. Bin ja mal gespannt, ob sie jetzt alle Server dahin migrieren oder nur manche.

Auch interessant. Gerade eine Mail von einem Mitbewerber bekommen.

Zitat

vielen Dank, dass Sie unsere [...] Server nutzen.

Um Ihnen auch in Zukunft ein attraktives Preis-Leistungs-Verhältnis bieten zu können, reagieren wir auf gestiegene Energie- und Verwaltungskosten mit einer nachhaltigen Maßnahme: Wir migrieren ausgewählte Server in ein Rechenzentrum mit effizienterer Energienutzung.

Davon ist auch Ihr [...] betroffen. Geplant ist, Ihren Server im Zeitraum vom 28.07.25 bis 01.08.25 vom Rechenzentrum in Frankfurt nach Niederlauterbach zu übertragen.

Niederlauterbach? Etwa das hier? https://www.spar-dsl.de/1und1-zieht-se…-frankreich-um/

Aber das ist eigentlich nicht der Provider in dem verlinkten Artikel. Kaufen die sich da ein? Etwas merkwürdig.

Zitat von tom434

Jetzt offiziell: https://www.golem.de/news/hardware-…503-194603.html

Also damit habe ich jetzt nicht gerechnet: https://www.hardwareluxx.de/index.php/news…indfactory.html

Mir ist das ein bisschen unklar. Du hast momentan einen Proxmox Server (mit LXC Containern oder VMs) und willst diesen durch einen VPS (vermutlich bei Netcup) ablösen? Auf diesem neuen VPS soll dann aber kein Proxmox mehr laufen, sondern ein Setup mit Docker Containern?

Vorschlag 1: Wenn du sowieso schon Erfahrungen mit PVE und PBS hast, könntest du das auch mit dem VPS so machen, wenn du dort die Dienste in verschiedene LXC Container auslagerst. Du könntest aber auch einen einzelnen LXC Container nutzen, dort Docker installieren und dann wie bisher deinen angemieteten PBS nutzen.

Vorschlag 2: Restic. Am besten lokal auf dem Host einen DB Service installieren, der von den Containern genutzt wird. Von diesem DB Service kannst du regulär DB Dumps erstellen. Die Container selbst schreiben ihre Daten entweder in Docker Volumes (/var/lib/docker/volumes) oder auf einen Host Mount (z.B. in /srv). Diese Daten können dann von Restic (inkl. DB Dumps) gesichert werden. Dafür würde sich dann z.B. die genannte Storage Box anbieten, die über sftp angesprochen werden kann.

We've had this problem here in the forum before (https://forum.netcup.de/administration…ungen/?pageNo=1). It seems that MT is blocking Netcup IPs or DC IPs in general. The TO in the other thread solved it by using a VPN. That made it work. Which strongly implies that the source IP is the problem here.

Zitat von VeePay

Auf welchem WH hast du es laufen?
Finde keine Mindestvoraussetzungen.

Schau mal hier: https://freshrss.github.io/FreshRSS/en/ad…requisites.html

Auch wenn es prinzipiell mit sqlite bzw. mysql läuft, wird aber trotzdem eine PostgreSQL DB empfohlen. Daher eignet sich hier ein eigener Server sicherlich besser. Ansonsten kann man das sicher auf jedem WH installieren. Das braucht nur wenig Ressourcen (wenn man auf eine PostgreSQL verzichten möchte).

Zitat von -Manu-

Ein "Node" ist immer Teil eines Clusters. Fällt (je nach Ausplanung) eine Anzahl X an Nodes aus, dann übernehmen die restlichen Nodes in Anzahl Y die gehaltenen Maschinen....das bekommt man in der Regel (außer ggf. einer extrem kurzen Unterbrechung) nicht mit. Egal ob Hyper-V, VmWare und Co... vorausgesetzt, der Cluster ist korrekt konfiguriert und besitzt die zwingend nötigen Redundanzen.

Ich denke hier liegt ein Missverständnis vor. Das ist bei Netcup kein Cluster im eigentlichen Sinne, dass Nodes hier hin- und herwechseln. Ja, sie können manuell verschoben/migriert werden, aber prinzipiell sind die VMs erst einmal fest einem Node zugeordnet (Stichwort: Local Storage). In anderen Cloud Umgebungen hat man in der Regel die Disks in einem Blockstorage as a Service über das Netzwerk (z.B. Ceph, NetApp, vSAN, ...). Aber auch dort würde im Falle eines Ausfalls die VM erst einmal (automatisch) auf einen anderen Host verschoben werden müssen. Einen (wenn vielleicht auch nur kurzen) Ausfall hat man dann aber trotzdem, denn am Ende laufen die VMs immer auf irgendeinem Host. Und wenn dieser mal (warum auch immer) abstürzt, betrifft das grundsätzlich auch alle VMs, die gerade auf diesem Node laufen.

Ich vermute ja eher, dass hier eine Verwechslung mit dem VPS 2000 G11 vorliegt, den es ja auch in der Aktion gab. Dieser hat nämlich exakt 14,99 € gekostet. Beim Überfliegen kann man hier schon mal die beiden 2000er vertauschen.

Eine schöne Idee! Ein kleiner Verbesserungsvorschlag bzgl. des Designs: Bitte die animierten Wellen am unteren Rand deaktivieren. Das ist leider super nervig, wenn man diese im Blickfeld hat, sich aber auf den Text konzentrieren will. Es bietet ja auch keinerlei Mehrwert. Ansonsten wirkt es sehr einladend!

Zitat von finnvweiss

Ich spekuliere ja ungern, aber kann es sein das bei NC irgendwas gewaltig schief gegangen ist? Weil die VPS 500 werden ja auch nicht bereitgestell?

Es ist mit ziemlicher Sicherheit alles gut! Das kann durchaus alles etwas länger dauern. Das ist ganz normal. Hier muss man sich einfach etwas gedulden. Solange du eine Bestellbestätigung per Mail bekommen hast, wirst du auch früher oder später den Server bekommen

Zitat von mango

Weiß jemand wie groß der Untschied der AMD 7702 CPUs aus den G9.5 Root Servern im Vergleich zu den aktuellen VPS G11 CPUs ist? Sind das große Unterschiede?

Es kommt ganz darauf an welchen VPS G11 du hast bzw. bekommst. Beim RS bekommst du eine klar definierte CPU (AMD Epyc 7702 - Rome). Die VPS G11 gibt es sowohl in einer Rome Variante als auch mit einer neueren Milan CPU. Letztere hat einen Leistungsplus von etwa ~50% laut diversen Benchmarks. Aber unabhängig davon, muss man sich bewusst sein, dass die G9.5 CPUs (Rome) aus dem Jahr 2019 sind. Sprich das sind nicht mehr die jüngsten. Die aktuellen Angebote holt man sich definitiv nicht, weil man besonders viel CPU Leistung benötigt. Die aktuelle Generation G11 ist hier deutlich überlegen. Sobald CPU Leistung relevant wird, sollte man hier nicht zu der alten CPU greifen. Entsprechend sind solche Vergleiche auch immer nur bedingt sinnvoll. Um einen besseren Eindruck zu bekommen, kann man sich hier mal umsehen: https://www.vpsbenchmarks.com/hosters/netcup/yabs

Zum Vergleich:
* (VPS 2000 G11 Milan): https://www.vpsbenchmarks.com/yabs/netcup-8c…20241129-e5fc06 (Single Core 1824)
* (RS 2000 G9.5) https://www.vpsbenchmarks.com/yabs/netcup-6c-16gb-30077 (Single Core 933)

Vielleicht ein etwas extremes Beispiel. Aber es zeigt doch recht gut den Nachteil einer alten CPU.

Schau mal im Server/KVM Bereich hier im Forum rein. Da gab es in letzter Zeit recht viele Diskussionen zu diesem Thema. Zusammengefasst bieten sich folgende Möglichkeiten an. Welche man davon jetzt bevorzugt, ist wirklich individuell verschieden. Am ehesten macht mal das, womit man die meiste Erfahrung hat:

• Snapshot erstellen und einspielen
• dd im Rettungssystem
• rsync
• Backup / Restore

Aus vertraglicher Sicht musst du den alten Server regulär kündigen und einen neuen Server buchen. Da wirst bzw. möchtest du aber definitiv eine zeitlang beide Server unter Vertrag haben und bezahlen müssen. Das hat aus operativer Sicht aber definitiv Vorteile. Eine Migration (vor allem, wenn sie erst nach einigen Jahren stattfindet) ist meist immer etwas, wofür man sich Zeit nehmen sollte. Es gibt immer die ein oder andere kleinere Konfiguration, die man vielleicht vergessen, nicht genug dokumentiert oder einfach an sich geändert hat, weil man zusätzlich auch noch die Version aktualisiert. Da ist es immer besser, man hat den alten Server weiterhin online und kann in Ruhe vergleichen. Den Luxus, dass man auf beide Systeme gleichzeitig drauf an kann um zu vergleichen, sollte man daher nicht außer Acht lassen. Hat alles wie gewünscht geklappt, kann man den Server auch hier in der Tauschbörse noch anbieten. Ist das allerdings kein Aktionsserver, dürfte es schwer werden, hier einen Abnehmer zu finden. Du willst ja auch nicht ohne Grund wechseln .

Zitat von gem

Vielen Dank, das bestätigt meine eigenen Recherchen.

Mir ging es auch weniger um Fedora als Distro sondern darum, dass RDP jetzt in Gnome quasi integriert ist und ich das eigentlich sehr bequem finde.

Außerdem scheint über die Zukunft von xrdp bei Wayland noch vieles offen zu sein.

Ich denke, ich kehre dann erstmal wieder auf xrdp mit xfce zurück, dass liegt mir persönlich mehr und läuft seit Monaten extrem stabil.

Das ist wohl keine schlechte Idee . xrdp mit xfce läuft vor allem dann besser, wenn es sich um einen Server (VPS, RS) ohne richtige GPU handelt. Die Gnome Shell läuft halt wirklich nur mit einer richtigen GPU flüssig. Ich hatte das in der Vergangenheit schon ein paar Mal mit VMs getestet und das war nie so wirklich toll. Daher würde gnome-rdp auch eher nur im Homlab nutzen. Vermutlich ist auch eher nur dafür gedacht und hat deswegen nur wenig Optionen, die man im Homelab ja auch nicht wirklich benötigt.