Beiträge von andreas.

  • [gelöst] spontaner Reboot

    Zitat von mro
    Spoiler anzeigen


    Tips?

    Ich habe mal meine KI zu deinem Problem gefragt.
    Sie teilt dazu folgendes mit:

    Spoiler anzeigen

    Die Fehlermeldung zeigt einen Kernel-Panic in FreeBSD 14.4 im Bereich des UFS-Dateisystems mit aktiviertem Journaling. Hier ist eine Einordnung, was der Fehler bedeutet und wie du damit umgehen kannst:

    🔍 Was sagt die Fehlermeldung?

    • panic: handle_disk_io_initiation: Unexpected type jnewblk
      Der FreeBSD-Kernel stieß während einer Festplatten-I/O-Operation auf einen unerwarteten Blocktyp jnewblk (Journal-New-Block). Dieser gehört zum UFS-Journaling (softdep), ist an dieser Stelle im Code aber nicht korrekt behandelt worden → führt zum sofortigen Kernel-Panic.
    • Der Backtrace zeigt, dass der Fehler während eines periodischen Sync-Vorgangs (sched_sync → ffs_fsync → bufwrite → softdep_disk_io_initiation) ausgelöst wurde. Das passt zur Uptime von ~23 Minuten (typischer Sync-Intervall).

    🐛 Hintergrund & Bekannte Issues

    • Dies ist ein bekannter Bug in FreeBSD 14.x im softdep-Subsystem des UFS-Journalings. Er wurde in der FreeBSD-Community und im Bugzilla mehrmals gemeldet.
    • Er tritt oft unter Last, bei vielen kleinen Schreiboperationen oder bei spezifischen Storage-Backends auf (KVM kann hier durch Latenz oder Queue-Management den Auslöser liefern, ist aber selten die direkte Ursache).
    • FreeBSD 14.4-RELEASE-p2 enthält möglicherweise noch keine vollständige Korrektur. Neueere Patch-Level oder 15.x haben das Problem oft behoben.

    ✅ Empfohlene Maßnahmen

    1. Sofortiger Workaround: UFS-Journaling deaktivieren

    Code
    # Runtime (bis zum nächsten Neustart):
sysctl vfs.ffsjournal=0

# Persistente Deaktivierung:
echo 'vfs.ffsjournal="0"' | sudo tee -a /etc/rc.conf

    ⚠️ Hinweis: Du verlierst damit den Schutz vor inkonsistenten Dateisystemen bei einem unerwarteten Powerloss. Für VMs mit zuverlässigem Storage oft akzeptabel.

    2. FreeBSD auf den neuesten Patch-Level bringen

    Code
    freebsd-update fetch
freebsd-update install

    Prüfe die FreeBSD Errata nach Einträgen zu softdep oder ffs journaling für 14.4-RELEASE.

    3. Storage & KVM-Backend prüfen

    • Prüfe /var/log/messages oder dmesg auf vorangehende umass, ahci, virtio-blk oder timeout-Warnungen.
    • Stelle sicher, dass der KVM-Storage-Backend (qcow2, raw, LVM, Ceph etc.) keine Latenzspikes oder Queue-Overflows meldet.
    • Falls möglich: Storage-Polling-Intervalle oder virtio-blk-Queue-Größe anpassen (-drive ...,iothread=1 oder cache=none,io=native).

    4. Langfristige Alternative

    Falls Journaling nicht zwingend erforderlich ist, wechsle auf ZFS (zfs create -o compression=on -o mountpoint=/... rpool/...). ZFS ist auf FreeBSD standardmäßig integriert, stabiler im KVM-Context und umgeht das softdep-Problem komplett.

    📌 Zusammenfassung

    Es handelt sich um einen Software-Bug im FreeBSD-Kernel (UFS-Journaling), nicht zwingend um Hardware oder KVM-Fehler. Deaktiviere vorübergehend das Journaling, aktualisiere das System und prüfe Storage-Latenzen. Bei wiederholten Panics nach Update-Einspielung lege einen Bugreport an FreeBSD Bugzilla mit dmesg, sysctl vfs.ffs* und der KVM-Storage-Konfiguration.

    Eventuell hilft es dir weiter.

  • Server 2. IP - ist das so richtig?

    Zitat von darkstar

    Ich habe jahrelang Proxmox auf eigener Hardware gehabt aber würde nie versuchen, das selbst auf virtuellen Servern zu installieren (der RS ist ein VPS mit garantierten Ressourcen). denn es macht keinen Sinn KVM im KVM genested laufen zu lassen.

    Proxmox ist nicht nur dazu da, um VM´s auf Dedicated Server zu nutzen, sondern wird hier von einigen Kunden auch dazu genutzt, um LXC´s innerhalb eines VPS / RS zu betreiben.

    Weiterhin kann Proxmox auch im Zusammenspiel mit dem Proxmox Backup Server zur deutlichen Erhöhung der Verfügbarkeit beitragen, da alles vollautomatisiert von Proxmox im Hintergrund erledigt wird.

    Und wenn man Proxmox auf mehreren VPS´s / RS´s zum Betreiben seiner LXCs innerhalb seines vLAN nutzt, kann man sogar die einzelnen LXC´s von VPS / RS zu VPS / RS vollautomatisiert verschieben lassen.

  • KRITISCH: Gehacktes Webhosting – Support reagiert nicht

    hackuni :

    Da ich eine lokale KI betreibe, habe ich mal deine Frage meiner lokalen KI übergeben und innerhalb von ca. 2 Sekunden deine Frage wie folgt beantwortet bekommen.

    Ob diese Antwort nun zu deiner Lösung beitragen wird, habe jetzt nicht geprüft. Klingt aber doch schon sehr glaubwürdig.

    Die Antwort der KI innerhalb von 2 Sekunden:

    Spoiler anzeigen

    Das ist eine echt unangenehme Situation, aber erst einmal ein ganz wichtiger Hinweis vorab: Setz die Rechte bitte auf keinen Fall auf 777! Das bedeutet "jeder darf alles lesen, schreiben und ausführen". Damit öffnest du dem Virus (und anderen Angreifern) die Tür sperrweit auf. Setz Ordner zurück auf 755 und Dateien auf 644.

    Dass du nichts löschen kannst, liegt vermutlich an einem von zwei Gründen:

    1. Immutable-Flag: Professionelle Malware setzt oft ein spezielles Attribut (chattr +i), das selbst dir als Besitzer verbietet, die Datei zu löschen oder zu ändern.
    2. Cronjobs/Auto-Recreation: Der Virus hat einen Zeitplan (Cronjob) im System hinterlegt. Sobald du eine Datei löschst, wird sie innerhalb von Sekunden durch ein verstecktes Skript neu erstellt.

    Hier ist dein Schritt-für-Schritt-Plan, was du jetzt tun solltest:

    1. Die schnellste Lösung: Backup wiederherstellen

    Netcup erstellt in der Regel automatische Backups. Wenn die Infektion erst kürzlich passiert ist oder du ein sauberes Backup von vor Oktober hast, ist das der sicherste Weg.

    • Schau im Kundenpanel (CCP) oder im Control Panel deines Webspaces nach, ob du eine Sicherung aus einer Zeit wiederherstellen kannst, in der deine Seite noch sauber war.
    • Achtung: Wenn du ein Backup von November oder Dezember nimmst, ist der Virus höchstwahrscheinlich schon darin enthalten.

    2. Passwörter sofort ändern (Überall!)

    Bevor du aufräumst, musst du die "Eintrittstüren" schließen, sonst infiziert sich das System sofort wieder:

    • Ändere dein Passwort für das CCP.
    • Ändere dein Passwort für das Plesk Control Panel.
    • Lösch alle FTP/SFTP-Benutzer und leg sie mit starken Passwörtern neu an.
    • Ändere die Passwörter deiner Datenbanken.
    • Falls du WordPress, Joomla etc. nutzt: Ändere sofort die Administrator-Passwörter.

    3. Analyse und manuelle Reinigung (Schwierig)

    Wenn ein Backup nicht möglich ist, musst du tiefer graben:

    • Cronjobs prüfen: Schau im Control Panel unter "Geplante Aufgaben" oder "Cronjobs". Such nach Einträgen, die du nicht kennst (oft kryptische Namen oder Pfade zu /tmp oder versteckten Ordnern). Lösch diese als Erstes!
    • Versteckte Dateien: Achte auf Dateien, die mit einem Punkt beginnen (z.B. .hidden_shell.php).
    • Wenn diese Tipps nicht weiterhelfen, Netcup Support kontaktieren: Schreib ein Ticket an den Support. Erklär ihnen, dass dein Account kompromittiert wurde und du keine Dateien löschen kannst. Die Admins haben Root-Zugriff und können sehen, ob das immutable-Flag gesetzt ist oder welche Prozesse im Hintergrund laufen.

    4. Der "Nuclear Option" (Empfohlen bei schwerem Befall)

    Wenn ein System einmal so tief infiziert ist, dass Dateien blockiert werden, findet man oft nie alle Hintertüren ("Backdoors"). Der sicherste Weg ist:

    1. Daten sichern: Sichere dir nur die absolut notwendigen Daten (z.B. die Datenbank-SQL-Datei und den /uploads-Ordner mit deinen Bildern). Lade auf keinen Fall .php Dateien aus dem Backup wieder hoch!
    2. Komplette Löschung: Lösch alle Dateien auf deinem Webspace (oder lass das vom Support machen/setz den Account komplett zurück).
    3. Neuinstallation: Installiere dein CMS (z.B. WordPress) komplett neu aus einer frischen, offiziellen Quelle.
    4. Updates: Aktualisiere sofort alles (PHP-Version, Plugins, Themes) auf die neueste Version.

    Zusammenfassung: Was machst du jetzt?

    1. Stopp den Versuch mit chmod 777.
    2. Ändere alle Passwörter.
    3. Prüfe, ob ein altes Backup (vor Oktober) existiert → falls ja: Wiederherstellen.
    4. Falls nein: Schreib ein Ticket an den Netcup Support und bitte um Hilfe beim Löschen der blockierten Dateien.
    5. Für die Zukunft: Installiere ein Sicherheits-Plugin (z.B. Wordfence bei WordPress), nutze starke Passwörter und aktiviere 2FA, wo immer es geht.

    Warum ist das passiert? Meistens passiert das durch veraltete Plugins, Themes oder zu schwache Passwörter. Der Virus nutzt eine Sicherheitslücke aus, installiert einen "Bot" und sichert sich so ab, dass du ihn als normaler Nutzer nicht mehr entfernen kannst.

  • Debian 13 - Boot Meldung "RDSEED32 is broken"

    Zitat von mango

    Ich habs gerade mal probiert und eingefügt bei GRUB_CMDLINE_LINUX_DEFAULT="quiet rdseed=0"
    Danach habe ich gemacht.

    sudo update-grub
    sudo reboot

    Seltsamerweise wird die Meldung immernoch beim Booten angezeigt.

    Und wie verhält sich deine VM, wenn du den Kernelparameter von der Reihenfolge wie folgt setzt?

    GRUB_CMDLINE_LINUX_DEFAULT="rdseed=0 quiet"

    und dann die VM mit dem Befehl poweroff herunterfährst und danach neu startest?

    Zitat von mango

    Ich weiß nicht ob ich das RDSEED überhaupt brauche, bin damit noch nie in Kontakt gekommen.

    In einer VM emuliert der Hypervisor die Hardware. RDSEED ist eine echte CPU-Funktion des physischen Prozessors und VM´s haben keinen direkten Zugriff auf echte CPU-Features wie RDSEED.

    Was ist RDSEED? RDSEED ist eine CPU-Instruction, die vom Prozessor echte Zufallszahlen aus physikalischen Quellen erzeugt, anstatt pseudo-zufällige Zahlen zu berechnen.

    Wenn RDSEED auf dem Hypervisor defekt ist, können folgende Probleme für die VM entstehen:

    • Sicherheitsrisiko: Kryptografische Schlüssel könnten vorhersagbarer sein.
    • Performanceeinbußen: Der Kernel muss auf langsame Software-RNGs ausweichen.
    • Potenzielle Blockaden: Bei hoher Last kann /dev/random blockieren, wenn nicht genug Entropie verfügbar ist.

  • Debian 13 - Boot Meldung "RDSEED32 is broken"

    Zitat von mango

    Okay, danke für die Antwort, dann ist das also kein kritisches Problem. Anscheinend kann bei virtualisierten CPUs RDSEED durch den Hypervisor falsch durchgereicht werden, aber da kann ich ja nichts machen. Oder?

    Und den Befehl "apt upgrade linux-firmware" habe ich gerade probiert, aber scheint nicht zu gehen.

    Es gibt noch eine Alternative: Wenn der o.g. Befehl bei einer VM nicht funktioniert, so könnte auch der Kernelparameter rdseed=0 in der Datei grub zur Umgebungsvariable GRUB_CMDLINE_LINUX_DEFAULT hinzugefügt werden. Denn damit wird zwar das ursprüngliche Problem nicht gelöst, welches auf dem Hypervisor zu suchen ist, aber die o.g. Ausgabe wird während des Systemstarts zukünftig unterbunden.

  • Debian 13 - Boot Meldung "RDSEED32 is broken"

    Diese Meldung [0.084436] RDSEED32 is broken. Disabling teh corresponding CPUID bit ist kein kritischer Systemfehler – sie wird lediglich als Warnung ausgegeben.

    Der Linux-Kernel hat erkannt, dass deine CPU bzw. der RDSEED-Befehl fehlerhaft ist und entsprechende Funktionen deaktiviert.

    Abhilfe könnte aufgrund einer fehlerhaften Firmware der Befehl apt upgrade linux-firmware bringen.

  • RS 1000 G12 kein Netzwerk nach Ubuntu Installation

    Zitat von TrashGordon

    auch im Rettungssystem "Destination Host Unreachable"

    kein unsichtbares Steuerzeichen

    Für uns Kunden wäre mal interessant zu wissen, ob Netcup noch Support für diese Produkte in ausreichender Qualität anbietet. Von daher könntest du auch für dein Problem über den Notfall-Support über dessen Telefon-Nr. +49 721 754 0 755 5 ein Ticket aufgeben und uns deine Erfahrungen damit mal mitteilen. Denn die Kosten entstehen ja nur, wenn das Problem auf deiner Seite zu suchen ist, aber nicht, wenn es über dem Rettungssystem sich genauso unerwünscht verhält, wie unter dem installiertem OS.

  • RS 1000 G12 kein Netzwerk nach Ubuntu Installation

    Vor längerer Zeit hatte ich auch unter Ubuntu den Fall, dass aufgrund eines unsichtbaren Steuerzeichens im Netplan keine Netzwerkverbindung zustande kam, aber über dem von Netcup gestellten Rettungssystem die Netzverbindung wie gewünscht funktionierte.

    Das Problem war in meinem Fall, dass sich im Netplan ein unsichtbares Steuerzeichen eingeschlichen hatte, welches ich mit Hilfe von vi und dem Befehl : set list zuerst sichtbar gemacht und danach beseitigt hatte, gelöst war.

    Nach dem Neustart des Netzwerkdienstes, lief dann auch die Netzwerkverbindung wie gewünscht wieder.

  • Wahl der Hardware für einen Docker-Server

    Zitat von Bud

    bei meinem Docker-Server habe ich leider auf das falsche Pferd gesetzt: Mein aktueller VPS 500 G11s stößt beim Arbeitsspeicher bereits an seine Grenzen. Da sich die CPU, wie im beigefügten Screenshot zu sehen, ohnehin langweilt, bin ich nun auf der Suche nach einer passenden Alternative.

    Schau dir auch mal die Legende zum Grafen mit dem Arbeitsspeicher genauer an. Denn nicht immer wird auf dem Grafen angezeigt, dass der RAM auch tatsächlich mit Daten gefüllt ist.

    Sofern auch SWAP auf dem Server eingerichtet ist, was auch zu empfehlen ist, solltest du dir in diesem Zusammenhang auch mal den Grafen des SWAP´s genauer anschauen.

    SWAP wird meistens für Anwendungen zum Auslagern von deren Inhalten genutzt, wenn dessen Daten über einen längeren Zeitraum nicht genutzt werden, aber sehr kurzfristig wieder in den RAM geladen, sobald deren Daten wieder benötigt werden.

  • Das längste Thema

    Nach ca. zwei Wochen der Preisanpassungsankündigung ist mir aufgefallen, dass die vServer mit der Typenbezeichnung RS 4000 G11/12 RS 8000 G11/12 mittlerweile aufgrund des besseren IO-Verhaltens sich nicht mehr so überbucht anfühlen.

    Auch Sprachmodelle, wie GPT-OSS 20b und qwen3.5-35b, die man sich über die Webseite huggingface.co als Datei herunterladen kann, erreichen unter dem Dienst LM-Studio, welchen man auch auf seinem Server als Serveranwendung im Hintergrund laufen lassen kann, mittlerweile ca. 12 bis 15 Tokens pro Sekunde. Vorher waren es ca. 2 bis 3 Tokens pro Sekunde.

    Wenn man zuschaut, wie das jeweilige Sprachmodell antwortet, so ist es schneller als der Abspann am Ende eines Films. Denn so schnell wie es geschrieben wird, kann man es nicht mitlesen.

    Stellt ihr dieses Verhalten bei euren vServern auch fest?

  • RAMpocalypse: We need to talk about pricing

    Zitat von [netcup] Alexander W.

    We are monitoring the market very closely. Here is the current price development for NAND flash wafers directly from the fab (source: DRAMeXchange):

    Spoiler anzeigen

    There may be small corrections in certain consumer segments, but the underlying production costs have quadrupled over the past twelve months. On top of that, the fabs are still fully booked. As long as that is the case, there is no relief on the supply side. That is what determines our purchasing prices. And even if prices were to drop tomorrow, we have already purchased our current hardware at today's elevated prices. X/

    Damit wir uns den Chart auch vom zeitlichen Verlauf besser anschauen können, müßtest du mal schauen, ob du uns den Chart nicht so reinstellen kannst, dass wir auch den zeitlichen Verlauf daraus ablesen können und auch bei Bedarf diesen Chart bzw. diese Abbildung vergrößern können. Denn jetzt ist diese Abbildung doch nur sehr klein und ohne zeitlichen Verlauf zu sehen.

  • Das längste Thema

    Zitat von KB19

    Dreht bei euch UptimeRobot seit einigen Stunden auch komplett durch? Ich bekomme im Minutentakt down/up Notifications für quasi alle überwachten Ziele, nicht nur bei den netcup vServern. X/

    Ich nutze auch diesen Dienst für Server beim Mitbewerber und habe dieses von dier beschriebene Verhalten bis jetzt nicht beobachtet.

  • RAMpocalypse: We need to talk about pricing

    @[netcup] Alexander W.,

    Ich habe mal so getan, als würde ich mir bei euch einen vServer mit der Typenbezeichnung RS 16000 G12 für gleich 12 Monate bestellen wollen.
    Dabei ist mir aufgefallen, dass euer Einkaufswagen wichtige Hinweise zu den Zahlungsbedingungen verschweigt. Z.B. wird die Gesamtsumme von 1.997,40 Euro im Einkaufswagen wehrend des Bestellablaufs nicht angezeigt, sondern nur folgendes:

    Abrechnungszeitraum: alle 12 Monate
    Vertragslaufzeit: mind. 12 Monate
    Standort: Nürnberg, Deutschland
    Netzwerk: IPv4 + IPv6 Connectivity
    Produktbezeichnung: RS 16000 G12 ip 12M NUE
    Einrichtungsgebühren: 0 Euro
    Preis pro Monat: 166,45 Euro

    Besser wäre, dem potenziellen (Neu-) Kunden auch aufzuzeigen, dass er nach seiner Bestellung dann auch die Summe von 1.997,40 Euro für gleich 12 Monate im Voraus zu zahlen hat.

    Denn die hohe Summe von 1.997,40 Euro wird dem potenziellen (Neu-) Kunden dann auch erst den entsprechenden Aha-Effekt bringen.

  • RAMpocalypse: We need to talk about pricing

    Zitat von darkness

    Es geht hier nicht um die verbaute Grafikkarte, sondern um die Lenovo ThinkStation P3 Tower Gen2 selbst – und diese ist mittlerweile EOL.

    Es ist daher sehr wahrscheinlich, dass zeitnah eine neue Generation (Gen3) erscheint, vermutlich wieder mit einer vergleichbaren Grafikkarten-Konfiguration.

    Bei meinem Beitrag #321 ging es auch vorrangig um die in der Serie "ThinkStation P3 Tower Gen2" verbaute Hardware (DDR5 RAM und Grafikkarte), was auch zum Thema "RAMpocalypse: We need to talk about pricing" besser paßt.

    Die Serie von Lenovo mit der Bezeichnung "ThinkStation P3 Tower Gen2" spielte hierbei keine Rolle.

    Man hätte sich solche Workstation auch zum Ausschlachten kaufen können, um dadurch an solcher Hardware vergünstigt ranzukommen.

  • RAMpocalypse: We need to talk about pricing

    Zitat von andreas.

    Die Grafikkarte NVIDIA RTX PRO mit GDDR7 RAM gibt es noch nicht lange. Ich glaube, dass diese Serie erst dieses Jahr herausgekommen ist und zu verschenken haben die Hersteller, wie Lenovo, auch nichts. Von daher schätze ich mal, dass es diese Serie noch recht lange auch noch danach zu kaufen geben wird. Das gleiche sehe ich auch beim DDR 5 RAM.

    Zitat von sirana

    Die Workstation wurde letztes Jahr im Juni raus gebracht, da sowas idr Jährlich kommt ist das ding also am ende des Zyklus...

    Laut dem Hersteller NVIDIA, unter der URL https://blogs.nvidia.com/blog/gtc-2026-news/#rtx-pro-4500, gibt es diese Grafikkarte NVIDIA RTX PRO 4500 Blackwell 32 GB, die in der oben beschriebenen Workstation Lenovo ThinkStation P3 Tower Gen2 verbaut ist, erst seit dem 16.03.2026. Also noch sehr neu. Mehr siehe hier.