Bei Netzwerkproblemen: Hat das Rescue-System Netz? Dann liegt es am Image. Wenn nicht, dann beim Support anfragen. Wenn das Rescue-System noch nicht auf IPv6-only Server angepasst ist, dann beim Support anfragen. Du hast ein IPv6-only System bestellt, kein VLAN-only System, ja?
Beiträge von NaN
-
-
IPv6 hat mehrere Designfehler, die daraus entstanden sind, dass die Hauptakteure auf Biegen und Brechen ein Netz haben wollen, in dem alle Endgeräte nach außen sichtbare öffentliche Adressen haben. Diese Fehler gehen nicht mehr weg und sie produzieren andere Fehler, weil es Protokolldesigner gibt, die diese Erwartung zum Anlass nehmen, nicht für fehlende Ende-zu-Ende-Konnektivität zu planen, wenn IPv6 im Spiel ist. Es ist nicht verkehrt, genug Adressen zu haben, dass jedes Gerät, das eine braucht, eine eigene öffentliche bekommen kann, aber dass es eine haben muss, macht unnötig viele Probleme.
IPv6-only Server sind auf absehbare Zeit akademisches Spielzeug, Nerdpuzzles, Proof-of-Concepts oder wie auch immer man etwas bezeichnen möchte, das keinen produktiven Einsatzzweck erfüllen kann. Deswegen werden die angeboten wie sauer Bier. Es gibt sehr viele Clients, die nur IPv4-Server erreichen können, aber nahezu keine, die nur IPv6-Server erreichen können. Ein IPv6-only Server erfüllt deswegen für einen nicht vernachlässigbaren Teil der Clients seinen Zweck nicht, und das heißt er erfüllt für den Serverbetreiber den Zweck nicht. Ein IPv4-erreichbarer Server braucht dagegen keine IPv6-Adresse, denn er ist ja schon von praktisch allen erreichbar, und damit ist IPv4 völlig ausreichend.
Der wichtigste Zweck von IPv6 ist, dass es den Anschein einer Alternative zu IPv4 gibt, so dass man IPv4 bepreisen kann. Ohne IPv6 wäre eine IPv4-Adresse nicht auf dem Papier verzichtbar sondern einfach eine Voraussetzung, um einen Server anbieten zu können. Das ist so, als würde man einen Lenker als aufpreispflichtige Option anbieten, weil man das Fahrrad auch durch Gewichtsverlagerung steuern kann, nur dass lenkerlose Fahrräder nicht so eine lautstarke Fanbasis haben.
-
Die Preise wurden nicht wirklich erhöht.
Das ist eine eigenwillige Interpretation der verwendeten Worte. Erst Shrinkflation und dann "jetzt mit 60% mehr Inhalt zum 60% höheren Preis". Wenigstens ist der Preis von IPv6 erkennbar: Kostet das gleiche wie gar keine Adresse, also nichts wert. (Eigentlich ist der Wert negativ, denn mit den Cloud-VLAN-only Varianten bekommt man keinen externen Traffic. Der ist bei IPv6 dabei und nicht wertlos, also muss das IPv6-Gedöns weniger als nichts wert sein.)
-
Cronjob? Es ist leider nicht möglich, ein Webhosting-Paket auf den Anfangszustand zurückzusetzen. Das wäre wirklich hilfreich, Netcup.
-
Die Bezeichnung Konzern hat erstmal nichts mit Größe zu tun sondern mit der wirtschaftlichen Struktur. Insofern ist "Konzernchen" schon richtig: Das ist ein kleiner Konzern, erfüllt also die Kriterien für den Begriff und ergänzt ihn um eine Größeneinordnung.
-
Wenn das ginge, wäre das ja alles kein Problem. qemu-img kann aber nicht aus Streams lesen, weil es random-access auf das Source-Image braucht.
-
Ich hatte hier schonmal einen Trick aufgezeigt, wie man ohne Sparse-Dateien zstd platzsparend entpacken kann, so dass man das Ergebnis mit qemu-img in eine qcow2-Datei umwandeln kann. Zstd on-the-fly zu entpacken und unkomprimiert hochzuladen bietet sich bei einem Image von einer 512GB-Platte eher nicht an.
-
Das eigentliche Geschenk ist in dem goldenen Umschlag: Wenn drei der zehn aktivsten Forenteilnehmer ihre Keycard zeigen, öffnet sich der Zugang
zur Schokoladenfabrikzum Netcup-Rechenzentrum. Natürlich muss man dabei hellwach sein. Dafür ist der Rest. -
-
Ländersperren kann man sich auch für .htaccess klicken. Im Interesse aller würde ich dich aber bitten, den Webserver nicht bei jedem Request z.B. 300KB Text für China IPv4 durcharbeiten zu lassen.
-
am 24.12 für die Spendenaktion
Sollte es da nicht einen VPS mit 128MB RAM, 1GB Storage, 1Mbit/s, einem Zehntelcore (1 Vcore mit bis zu 90% Steal) und einer IPv6 Adresse (/128) für 2€/Jahr geben oder habe ich das nur geträumt?
-
Na dann warte ich mal, bis das auch in Deutschland aufschlägt.
Hier ist das schon zweimal vorbeigekommen, einmal vom selben Hoster wie oben, davor am 19.12. von einem Hoster in den Niederlanden. Offensichtlich die gleiche Kampagne, aber mit leicht anderen Subjects. Mit einem leicht anderen Ansatz aber verdächtig ähnlicher Struktur wurde ich am 11.12. schon mit einer "ablaufenden Domain" aufgefordert, meine Netcup Zugangsdaten zu verraten. Das kam von einer IP, die einem Konkurrenzhoster in Düsseldorf gehört. Aber das sind nur die Netcup-Vortäuscher: Solche "irgendwas läuft ab, geben sie uns ihre Zugangsdaten" Mails sind für mich Grundrauschen geworden. Es trifft einfach alles, nicht nur Netcup.
-
Die Netcup Firewall ist stateful (mit Connection-Tracking) für TCP aber nicht für UDP. Das heißt, die Pakete in der anderen Richtung einer TCP-Verbindung sind automatisch auch freigegeben, aber für eine UDP "Verbindung" musst du die ausgehenden Pakete ausdrücklich in einer separaten Regel durchlassen. Debugging-Tipp: Du kannst mit tcpdump sehen, ob Pakete deinen Server erreichen, unabhängig davon ob eine Firewall auf dem Server sie verwirft, ein Programm sie entgegennimmt oder nicht oder ob die Verbindung sonst funktioniert.
-
AI-Firmen schauen längst normalen Nutzern beim Surfen über die Schulter. Dafür gibt es Plugins und ganze Browser. Nein, Logins halten die Daten nicht aus den AIs heraus. Das ist das selbe Problem wie mit Telefonbuchdaten: Du speicherst das vielleicht nur auf deinem Telefon, aber alle anderen laden ihre (und damit auch deine) Daten in die Cloud hoch.
-
Ich bin hellwach. Oui oui. Merci.
-
Ich hätte an eurer Stelle längst den regulären Support angeschrieben. Wenn es etwas ist, das ihr verkehrt macht, lernt Netcup, was man abfangen oder vielleicht besser beschreiben kann. Wenn es etwas ist, das Netcup verkehrt macht, kann Netcup das korrigieren. Wenn es ein systematischer Fehler ist, profitieren auch alle anderen davon, die sich nicht beim Support oder im Forum melden.
-
Weder das eine noch das andere ist dokumentiert, und DAS würde ich zuerst ändern. Ich fände es besser, wenn man eine gewisse Kontrolle über das Produkt behielte, das "gesperrt" wird, egal ob es nur eins ist oder alle. Dass man da nur über den Support überhaupt zum Aufräumen rankommt, finde ich schlecht, besonders am WE. Ich habe das glücklicherweise noch nicht ausgelöst, aber wer will sich davon freisprechen, dass einem das passieren könnte.
-
Ich dachte, wir hätten uns auf ein Bonsai-Kälbchen geeinigt? ("µ")
-
nach einer gewissen Zeit
Eine andere denkbare Ursache für erst später greifende Firewalls ist, dass trackende Firewalls nur die ersten Pakete der Verbindungen filtern. Alle weiteren Pakete werden als zur bestehenden Verbindung gehörend erkannt und genau so behandelt wie das erste Paket der Verbindung. Damit bleibt eine getrackte Verbindung auch nach einer Regeländerung bestehen, die die Verbindung verbieten würde. Erst wenn die Verbindung beendet ist und neu aufgebaut wird, geht sie dann nicht mehr durch. Man kann sich z.B. "problemlos" über eine SSH-Verbindung den SSH-Port sperren und trotzdem über SSH verbunden bleiben. Auch eine Neuverbindung vom selben Client kann mit SSH Multiplexing während der bestehenden Verbindung noch funktionieren, aber wenn die TCP-Verbindung beendet wird, kommt man nicht mehr rein.
(Vielleicht spinnt aber auch die Firewall. Nur ein Hinweis zu allgemeinen Fallstricken von Firewalls.)
-
Du wirfst Domainprovider, also Registrar und DNS Provider durcheinander.
Die Registry, der Registrar, der Domainprovider, und der DNS Provider haben alle Anteil daran, dass eine Domain korrekt funktioniert. Beispiel: Mit DNSSEC muss die Registry Schlüsseldaten in der Parent Zone hinterlegen, was der Domainprovider über den Registrar anstoßen muss. Wenn Netcup DNSSEC beim eigenen DNS-Hosting zerschießt und du daraufhin einen anderen DNS-Provider nutzen möchtest, bist du darauf angewiesen, dass Netcup (Domainprovider) es schafft, über den Registrar die Schlüssel deines anderen DNS-Hosters (oder der von dir signierten Zone) bei der Registry einzutragen. Das sind alles Dinge, die in der ein oder anderen Situation wirklich funktionieren müssen, weil es keine Ausweichmöglichkeit gibt. Entsprechend wichtig ist gute Vorbereitung auf Probleme, und diese Vorbereitung kannst du den anderen Beteiligten nicht vollständig abnehmen. DNS ist ein hierarchisches System. Die höheren Hierarchiestufen kann man gar nicht oder nicht schnell umgehen.
