Beiträge von NaN

Zitat von CUPPY1089

„Wenn der durchschnittliche Datenverkehr in den letzten 24 Stunden über 100 MBit/s liegt, erfolgt eine vorübergehende Drosselung auf 100 MBit/s“

Verstehe ich nicht so ganz. Ich wüsste nicht, wie man über einen VPS 100MBit/s im Downstream erreichen sollte, da die meisten Downloadserver sowieso keine höhere Übertragungsrate bieten, dennoch kann es mal sein, das wenn ich mich in ein Projekt stürze, einen Download starte, der mehrere Gigabyte Datengröße beträgt.

Wie die Drosselgrenzen beschrieben werden, variiert bei Netcup, aber die Werte kommen immer praktisch auf das selbe Konzept raus: Die Drosselbandbreite ist die, die im Mittel nicht überschritten werden darf, sonst wird gedrosselt.

Aktuell wird das mit einem 24-Stunden-Zeitfenster angegeben. 24 Stunden lang 100Mbit/s entspricht ungefähr 1TB an übertragenen Daten, 200Mbit/s~2TB/24h, usw.. Solange dein Datenverkehr unter 1TB/2TB/etc. in jedem beliebigen 24h Zeitraum bleibt, wird nicht gedrosselt.

Du kannst aber nicht am Abend 600GB übertragen und am nächsten Morgen wieder 600GB, weil dann innerhalb von 24h mehr als 1TB übertragen würden und deshalb gedrosselt würde. Das Datenvolumen wird nicht an einem bestimmten Zeitpunkt des Tages zurückgesetzt. Es zählt immer, was du in den letzten 24h übertragen hast.

Früher(tm) wurde die Grenze für den Kalendermonat statt für 24h angegeben. Das Monatsdatenvolumen entsprach ebenfalls der Drosselbandbreite, aber eben einen Monat lang. Wenn du dieses Datenvolumen vor Ende des Monats erreicht hattest, wurde für den Rest des Monats gedrosselt. Das ist subtil anders als ein gleitendes Zeitfenster. Der Hauptunterschied zu früher ist aber das jetzt kürzere Zeitfenster: Die Drossel schlägt früher zu, wird aber auch früher wieder gelöst.

Mit dieser Trafficregelung nähert sich Netcup halbwegs verständlich dem im Netzwerkbereich üblichen "burstable billing" mit percentile Angabe an, das noch eine Ecke schwieriger zu verstehen ist.

Zitat von fvbor

Eigentlich ganz gut, bis auf zwo der Maschinen die in der Orakelnden Cloud sind. Aber die Viecher kosten mich auch nichts.
21% im Durchschnitt, 63% Maximum

FYI: Das ist so wie versprochen. Die immer kostenlosen Instanzen sind nur Viertelcores. Sobald dein Scheduler versucht, mehr zu nutzen, wird dir alles über 25% "geklaut", was dann eben bis zu 75% Steal bedeutet.

Zitat von finnvweiss

Wann hat man sowas bekommen?

mitohnepapier.de und wozupapier.de sind noch frei.

Zitat von h725rk

ich habe gestern folgende Mail von reminder@ascio.com bekommen:

Wenn die Daten stimmen, ist das wahrscheinlich eine legitime Erinnerungsmail. Basis ist diese Regelung: https://www.icann.org/en/contracted-…y-21-02-2024-en. Besser wäre es, wenn solche Emails überhaupt keine Links oder kopierbaren Adressen enthalten würden, aber diese Erkenntnis will sich einfach nicht durchsetzen.

Nur kurz zur Bestätigung deiner Vermutung: Das geht nicht, weil der SSH-Server keine Portweiterleitungen zulässt. Das kannst du bei einem Webhostingpaket nicht ändern.

Ziemlich sicher hast du dich mit gescheiterten SSH-Logins selbst blockiert. Fail2ban. Wenn es wieder auftritt: Nicht neu installieren oder Snapshot drüberbügeln, sondern mit tcpdump nachsehen, ob die Pakete bis zu deinem Server kommen (werden sie) und dann die Firewall ausfindig machen, mit der du dich selbst ausgesperrt hast.

Fail2Ban? Schau mal nach, ob Pakete ankommen: Mit tcpdump -n -i eth0 "tcp[tcpflags] & (tcp-syn) != 0 and port 22" kannst du dir ein- und ausgehende TCP-SYN- und TCP-SYN-ACK Pakete auf Port 22 (SSH) anzeigen lassen, bevor sie irgendeine Firewall auf deinem Server verwirft. Wenn du die Pakete da siehst, aber trotzdem keine Verbindungen ankommen, kannst du suchen, wo du dir ein Bein gestellt hast. Nur wenn nicht, dann kommen sie möglicherweise gar nicht bis zu deinem Server.

(Mit Bezug zum alten Thema: Wenn du immer einfach neu installierst, anstatt deine Fehler zu suchen und zu beheben, wird es nicht auf Dauer funktionieren.)

Es gibt eine Kernelkonfigurationsoption config_ip6_nf_nat, aber das zugehörige Modul heißt ip6table_nat und ist ohne weiteres in Debian verfügbar.

Du versuchst (mit -l) eine Funktion aufzurufen, die für dich, als nicht-Reseller, nicht verfügbar ist. Für Dynamic DNS per Netcup API brauchst du diese Funktion nicht. Auch in Zeiten von Textgeneratoren muss trotzdem noch jemand lesen und verstehen, was auf dem Bildschirm steht. Bitte erwarte nicht, dass dir irgendjemand etwas noch fertigeres als ein ausgetestes Skript auf dem Silbertablett serviert.

Zitat von ASS

Erstaunlich.

Dass die nicht von denic ist und zu einer "bösen Seite" führt weißt du aber?

Klick dich mal bei Denic zu der Kontaktmöglichkeit durch. Da wirst du zu Netcup weitergeleitet. Auch trotz "Whois-Privacy" kann man also leicht herausfinden, wer der Registrar oder Tech-C (nicht Holder oder Admin-C) einer Domain ist, selbst wenn die Nameserver nicht die von Netcup sind. Dass die Spammer sich diese Mühe machen und die zentrale Instanz immer wieder befragen, glaube ich allerdings auch nicht. Sie machen sich nichtmal die Mühe, halbwegs glaubwürdige Emailadressen zu fälschen, weil etliche Clients sowieso nur den vom Absender frei wählbaren Namen anzeigen. Die werden einfach schauen, auf welche Adresse die Domain auflöst. Das kann man ganz anonym und ohne Risiko einer Sperre in großen Mengen abfragen.

Beim Anbieter gibt es einen Screenshot von der Konfigurationsseite des "BasisScript". Man beachte den Hinweis mit Ausrufezeichen: "Projekt URL (ohne / am Ende!):" Dieser Hinweis wird schon einen Grund haben. Sagt das etwas über die Qualität des Scripts aus, wenn so ein Hinweis offenbar nötig ist, aber ein derart trivial zu behebender Eingabe-"fehler" nicht automatisch korrigiert oder abgefangen wird? Muss jeder selbst entscheiden.

pasted-from-clipboard.png

Ich habe die Single-Core-Leistung hervorgehoben, weil NodeJS grundsätzlich nicht multithreaded ist. Die zusätzlichen Cores können sich also bei einem Test mit einer einzelnen Anfrage höchstens um losgelöste Aufgaben kümmern und beeinflussen das Ergebnis wenig. Sonst würde der Vorteil des Ryzen noch viel größer ausfallen. Parallelverarbeitung mit NodeJS ist möglich, aber wahrscheinlich nicht umgesetzt. Sonderlich performant scheint die Software ja nicht zu sein, wenn sie für weniger als 2MB Output länger als eine Sekunde braucht. Wenn die Verarbeitung nicht oft von mehreren Clients parallel genutzt wird, langweilen sich die anderen Cores wahrscheinlich und könnten die Datenbank ohne Einbußen für die NodeJS-Anwendung übernehmen. Schau dir die CPU-Auslastung genauer an, dann weißt du mehr.

Die Ryzen 7 5700X3D CPU hat eine 50% höhere Single-Core Leistung als die EPYC 7702P CPU und du hast 8 Cores / 16 Threads in deinem Computer, aber nur 4 Cores in deiner Root-Server-VM. Das Ergebnis kann also nicht wirklich überraschen.

Die Kernel Panic ist exakt identisch mit der in deinem Screenshot und sie wird in dem Thread für Debian 9 auf einer VM bei Google beschrieben. Auch Installer kann man mit Kerneloptionen booten. Wenn das installierte System läuft, verwendet es wahrscheinlich einen anderen Kernel als der Installer. Aber ich nehme an, es ist einfacher, auf alle anderen zu schimpfen, als tatsächlich zu debuggen.

In dem oben verlinkten Thread wird in einem späteren Kommentar beschrieben, dass der Kernelparameter pci=on das Problem umgeht, weil dann der fehlerhafte Codepfad im Kernel nicht genutzt wird. Vielleicht kann das mal jemand mit einem solchen System ausprobieren.

(Workaround in https://lkml.iu.edu/hypermail/linux/kernel/2103.3/01883.html, Ausführliche Fehleranalyse in https://lkml.iu.edu/hypermail/linux/kernel/2103.3/01919.html)

Was ist denn die Erwartung an der Stelle? Wenn du einen neuen Computer kaufst und das alte Betriebssystem lässt sich nicht installieren, weil es die Hardware nicht unterstützt, beschwerst du dich dann auch über den Computerhersteller?

Zitat von Olivetti

Kann man das als Kunde selbst feststellen, z.b. via dmidecode etc.?

Ich würde mir /proc/cpuinfo anschauen, aber dmidecode liefert vielleicht auch Hinweise, wenn man VPS vergleichen kann, wo's geht und wo nicht. Am Ende ist das aber nur Neugier, weil es auch dann nicht laufen wird, wenn man weiß, warum nicht. Da ich keinen VPS in der IP-Range habe, bin ich raus.

Ziemlich sicher, dass es das ist:

https://lkml.iu.edu/hypermail/linux/kernel/2103.3/01220.html

(Der Kernel macht einen Fehler auf einer bestimmten Hardwarekonstellation, in dem Fall eine Google Compute VM, weil wegen der unterschiedlichen Behandlung verschiedener CPUs in dem Fall die Invalidierung eines Translation Lookaside Buffer Eintrags fehlt. Das führt zu einem fehlerhaften Speicherzugriff. Mit anderen Worten: Alte fehlerhafte Software kommt nicht mit bestimmter neuerer "Hardware" klar. Ich vermute, dass für die VMs, wo der Fehler des Linuxkernels zum Tragen kommt, die virtuellen CPUs anders konfiguriert sind.)

Man hat bei der Konfiguration einer KVM-VM eine Menge Freiheitsgrade. Die VMs in dem IP-Adressbereich sind wahrscheinlich in irgendeiner Weise anders konfiguriert, aber das heißt nicht, dass sie defekt oder grundsätzlich problematisch sein müssen. Auch auf echter Hardware läuft nicht immer jedes System auf Anhieb. Ich habe hochmoderne Distributionen, die sich auf an sich äußerst solider Hardware nicht ohne manuellen Eingriff in den Installationsprozess zum laufen bringen lassen, weil eine Annahme über das UEFI nicht zutrifft. Und dann kommt jemand mit einem fossilen System und will das auf einer 8 Jahre neueren Maschine starten...

Die Möglichkeiten, die ich da sehe, sind: Phänomenologisch ist ein Merkmal identifiziert, anhand dessen sich VMs, die für dieses alte System ein Problem darstellen, erkennen lassen. Dann vermeidet man diese VMs eben. Bei der Bestellung kann Netcup Wünsche zur Platzierung der VMs berücksichtigen. Eine andere Möglichkeit ist, die Ursache herauszufinden. Das macht man sich einfacher, wenn man nicht direkt "Fehler bei Netcup" ruft. Linux hat eine Reihe von Möglichkeiten, die Kernelkompatibilität zu erhöhen, weil es in der Vergangenheit absolut üblich war, dass Linux nur mit "Tweaks" startete. Wer sich softwaretechnisch fast ein Jahrzehnt in die Vergangenheit begibt, sollte sich auch an vergangene Debugging-Methoden erinnern. Möglichkeit Nummer drei ist, die Systeme selbst zu hosten. Da die ja angeblich ohne Updates sicher zu betreiben sind, weil sie keinen Internetkontakt benötigen, muss man die nicht in einem Rechenzentrum laufen lassen. Die vierte Möglichkeit ist, und das erlaube ich mir trotzdem anzubringen, die Softwarefossilien auf den aktuellen Stand zu bringen. Ich bin Kunde bei euch. Was zum Henker habt ihr da am Laufen?