Beiträge von Paul

Bei den Ultra (Angeboten) fehlt wohl einfach der Rabatt, kommt es mir vor. Denn die Ultra Reihe gab es ja jetzt schon ein paar Mal und da lag der 1000 Ultra immer so um die 12 €, also genau zwischen dem 1000 und dem 2000 - was ja auch irgendwie Sinn ergeben würde. Mit den aktuellen Preisen sind die ja völlig unnötig und viel zu teuer. Kann mir gut vorstellen, dass das Netcup im Laufe des Tages nochmal korrigiert. Aber eigentlich müsste das doch vorher auch schon mal jemanden auffallen. Man wird die sich doch vorher hoffentlich nochmal irgendwie durchlesen, bevor man so etwas online stellt...

Zitat von aRaphael

Hm. So ganz klar ist mir das noch nicht.

Hier mal ein Screenshot aus dem SCP, der das bildlich etwas besser beschreibt. Du kannst dort ja ein Failover IPv6 Subnet (oder auch ein zusätzliches) einem Server zuweisen (im Netzwerk Tab). Nachdem du das gemacht hast, sieht das dann so aus:

ipv6-failover.png

Das links ist ein IPv6 Failover Subnet, Das rechts ist die (vorkonfigurierte) IPv6 Adresse, auf die das Failover Prefix geroutet wird. Damit also das Failover Subnet überhaupt funktionieren kann, muss diese eine Adresse auf deinem Server konfiguriert sein. Entweder ist sie das bereits (wenn man z.B. einfach ein Netcup Image installiert hat) oder man muss das eben selbst manuell erledigen. Anliegen muss sie aber, damit das Routing auch am Ziel ankommt.

Zitat von aRaphael

WIe ist das dann, wenn ich von Live-CD installiere?

Diese eine ipv6 ist ja nur im Image vorkonfiguriert. Wenn ich selbst installiere dann nicht, oder?

Ja. In diesem Fall musst du sie selbst konfigurieren, falls du ein zusätzliches IPv6 Subnet nutzen willst. Wenn du dieses im SCP zuweist, wird dir aber auch genau die Adresse angezeigt, auf die das geroutet wird. Daher siehst du die dort auch nochmal. Im Zweifel muss man einmal kurz ins Rettungssystem booten. Auch dort wird sie dir angezeigt.

Zitat von Bud

Erstmal danke für die zahlreichen Antworten – offensichtlich hatte ich das falsch im Kopf...

Paul Heißt das, dass eine FailoverIPv6 nur auf diese eine vorkonfigurierte IPv6 zeigen würde?

Korrekt. So kann man das deuten. Während eine IPv4 ja einfach auf deine bestehende IPv4 geroutet wird, hast du ja bei IPv6 keine einzelne IPv6 Failover Adresse, sondern ein ganzes /64 Prefix. Das aber zeigt trotzdem auf eine einzelne Adresse, in diesem Fall deine aus der MAC Adresse generierte (und vorkonfigurierte) IPv6 Adresse aus deinem schon bestehenden Prefix. Du hast natürlich weiterhin die Freiheit, das ganze /64 aus dem Failover IPv6 Prefix als auch aus dem mitgelieferten zu nutzen. Nur muss eben, damit das Failover IPv6 Subnet funktioniert, diese eine Adresse mindestens auch konfiguriert sein.

Zitat von Bud

Ich bin ein wenig verwirrt. Ich bin gerade darüber einen neuen Server (inkl. IPv6) einzurichten, aber er hat bereits eine IPv6 vorkonfiguriert... Ist das neu unter Debian 13? Kann ich diese IPv6 problemlos verwenden oder ist sie für einen bestimmten Dienst in Benutzung?

Die vorkonfigurierte IPv6 Adresse (basierend auf der MAC Adresse) wird genau dann wichtig, wenn du ein zusätzliches IPv6 Subnet auf dem Server nutzen willst, da dieses auf genau diese eine vorkonfigurierte Adresse geroutet wird. In diesem Fall muss diese auf jeden Fall auf dem NIC anliegen. Natürlich sind auch noch beliebig viele andere Adressen aus dem Prefix möglich. Aber wenn du nur das beiliegende Prefix nutzen willst, ist es völlig egal, welche Adressen du daraus konfigurierst und nutzen willst.

Zitat von ASS

Was macht man denn mit ner Domain für ein Jahr?

Wenn ich mir ne Domain hole, will ich die doch dauerhaft behalten.

Spam, Phishing, andere Betrügereien So eine Domain ist halt schnell mal verbrannt. Da braucht man regelmäßig Nachschub.

Kannst du die Meldung ignorieren und es trotzdem versuchen? Oder lässt er dich erst gar nicht?

Zitat von finnvweiss

Laut der PHP Info Page sollten auch alle Werte ausreichen.
Bekomme aber trotzdem den Fehler von All in One WP Migartion das irgendwas nicht ausreicht

Welche Fehlermeldung wird denn genau angezeigt? Es gibt ja nicht nur PHP Settings, die die Upload-Größe beschränken. Auch ein nginx hat hier Limits (z.B. client_max_body_size), welche man ggfs. erhöhen müsste.

Zitat von Bud

Also… Ich weiß ja nicht… Meint ihr nicht wir müssen die Kirche irgendwann auch mal im Dorf lassen? Wie hoch ist denn die Wahrscheinlichkeit wirklich, dass netcup krepiert?

Das Risiko ist mit Sicherheit überschaubar und nicht wirklich relevant. Aber was ist z.B. in dem Fall, dass dein Kundenaccount plötzlich (verschuldet oder unverschuldet) gesperrt wird? Ein Backup der Daten hat man sicherlich bei einem anderen Provider. Die Server / Apps sind auch in vertretbarem Aufwand woanders hochgezogen. Aber was machst du mit deiner Domain? Das ist definitiv ein Risiko, dessen man sich bewusst sein sollte. Du kannst zwar jederzeit rechtliche Schritte einleiten, aber das dauert dann halt.

Zitat von webdesignheld

Die Sites sind ja nur rsync oder push main - aber was ist mit den domains wenn eine hosting firma auf die art untergeht?

Definitiv ein wichtiger Punkt. Domains sind immer ein Single Point of Failure, weil die ja grundsätzlich nur bei einem einzigen Provider liegen können. Also die einzelne Domain jetzt. Natürlich kann man seine Domains auch auf verschiedene Provider verteilen. Aber wenn wirklich gerade dieser eine Provider hops geht, bei dem diese eine wichtige Domain liegt, dann hat man wirklich ein Problem. Prinzipiell lohnt es sich dann schon, wenn man hier einen entsprechenden großen Domain Provider wählt, wo die Gefahr eines plötzlichen Shutdowns sehr gering ist. Ich würde jetzt deswegen nicht unbedingt schlecht schlafen, aber das ist sicher gut mal gehört zu haben. Aber auch in diesem Fall kann man im Zweifel direkt mit der TLD Stelle sprechen. Das kann vermutlich etwas Zeit in Anspruch nehmen. Das Risiko ist aber vertretbar.

Zitat von KB19

Aha

Definitiv ein interessantes "Netzwerk"

Bildschirmfoto vom 2025-11-13 15-49-14.png

Link: https://www.northdata.de/netcup%20GmbH,…%20HRB%20705547

Ich würde das im E-Mail Umfeld auch etwas relativieren. Wenn 80% deiner Kontakte bei Microsoft, Google & Go. sind, liegen die Mails am Ende trotzdem bei einem US Anbieter auf dem Server. Da kann man sich auf der eigenen Seite noch so viel Mühe geben, aber gerade bei E-Mails braucht es ja immer 2 und die Gegenstelle hat man eben nicht unter Kontrolle. Daher kann man hier schon die einfachste Lösung wählen, die einem den wenigsten Ärger bereitet.

Zitat von Dragon

Das kann nicht bestätigen, bei meinem vServer läuft das Routing immer noch über Arelion/Telia.

Ok, zumindest nicht alle. Habe hier auch Server, die noch über twelve99.net geroutet werden, obwohl das Ziel das gleiche ist (Nürnberg). Hatte es zunächst nur mit meinem Jumphost getestet, weil es da am meisten auffällt.

Server 1 (Nürnberg)

  4. AS3209        145.253.52.12                                  0.0%     5   10.8  11.4  10.4  13.4   1.2
  5. AS9002        ae6-210.rt.irx.fkt.de.retn.net                40.0%     5    8.4   8.6   8.4   9.0   0.3
  6. AS9002        ae0-7.rt.nbg.nue.de.retn.net                   0.0%     5   11.3  12.0  11.0  13.4   1.2
  7. AS9002        gw-as47147.retn.net                            0.0%     5   14.0  12.8  11.2  14.1   1.3
  8. AS47147       94.16.25.155                                   0.0%     5   23.2  24.5  16.6  40.3   9.6

Server 2 (Nürnberg)

  4. AS3209        145.253.52.12                                  0.0%     5    9.8  11.1   9.8  13.3   1.5
  5. AS1273        ae32-100-pcr1.fnt.cw.net                       0.0%     5   11.7  10.3   9.7  11.7   0.8
  6. AS1273        telia-gw.fnt.cw.net                            0.0%     5   10.4   9.6   8.7  10.4   0.6
  7. AS1299        ffm-bb1-link.ip.twelve99.net                   0.0%     5    7.8   9.1   7.7  11.0   1.4
  8. AS1299        nug-b2-link.ip.twelve99.net                    0.0%     5   21.7  20.9  20.2  21.7   0.7
  9. AS1299        anexia-ic-373322.ip.twelve99-cust.net          0.0%     5   11.7  14.7  11.7  23.1   4.8
 10. AS47147       94.16.25.155                                   0.0%     5   13.3  14.2  11.7  18.1   2.7

Zitat von TBT

Update zu meinem Vodafone-Packetloss Problem: heute ist der erste Tag ohne Packetloss von VF aus. Yay.

Kann ich bestätigen (ebenfalls Vodafone). Die Verbindungen werden neuerdings über retn.net geroutet (das war vorher nicht der Fall). Das hat allerdings den Nachteil, dass die Latenz nun mehr als doppelt so hoch ist (22ms statt 10ms vorher). Ist mir aber immer noch lieber als der Paket Loss.

In einer shared Umgebung ist diese Option wohl generell nicht mehr verfügbar. Ändere die obigen genannte Option in der .htaccess mal in

Options +SymLinksIfOwnerMatch

Das sollte eigentlich noch funktionieren.

Du kannst für jede zusätzliche IP Adresse einen weiteren Block (ohne Gateway, nur mit der Adresse konfigurieren), z.B.

iface eth0 inet6 static
    address 2a0a:4cc0:c1:3af3::2/64

iface eth0 inet6 static
    address 2a03:4000:20:316::3/64

Siehe auch: https://wiki.debian.org/NetworkConfigu…erface_manually (Abschnitt Multiple IP addresses on one Interface)

Da sind ein paar Dinge nicht ganz korrekt

1. Lass die Gateways auf dem eth0:1 weg. Die braucht es nicht.
2. Die IPv6 Hauptadresse 2a0a:4cc0:c1:3af3:68ac:c4ff:fea8:91db musst du auf deinem eth0 Interface konfigurieren. Das ist die, worauf dein zusätzlichen IPv6 Subnet geroutet ist. Daher muss die zwingend auch auf dem Server konfiguriert sein.
3. /etc/network/interfaces.de/50-cloud-init.cfg solltest du löschen, wenn du die Konfiguration in /etc/network/interfaces vorgenommen hast.
4. Nach solchen Änderungen ist auch ein kompletter Reboot hilfreich. Der Netzwerk Dienst in Debian ist manchmal etwas zickig, wenn man größere Änderungen vornimmt.

Zitat von Mike0185

Nun laufen nach den Mahnungen auch noch die Zertifikate aus.... OHMAN !!!

Bei aller Kritik an uceprotect, aber deren Level 1 Liste ist wirklich nicht schlecht. Die blockt solchen Spam relativ zuverlässig

client [85.202.163.57] blocked using dnsbl-1.uceprotect.net; from=<updateservice@roddeln.de.com>

Das IPv6 Packet Loss Problem ist auch mal wieder da. Da war es die vergangenen Tage recht ruhig gewesen. Habe das auch nur gemerkt, weil ich auf einem Server per SSH unterwegs war und alles irgendwie gestottert hat.

  [...]
  6. AS47147       2a00:11c0:47:1:47::140                         6.7%    30   13.6  13.0   8.9  19.5   2.2
  7. AS47147       2a00:11c0:47:3::121                            0.0%    30   12.2  18.2  11.4  41.5   7.7
  8. AS197540      forum.netcup.de                               10.0%    30   11.3  10.7   9.6  11.9   0.6

Das serverseitige Setzen von Passwörtern kann zwar dafür sorgen, dass gewisse Richtlinien eingehalten werden, hat aber den eklatanten Nachteil, dass dieses Passwort auch wieder irgendwie zu dem Nutzer kommen muss. So viel Mühe man sich dann beim Erstellen gibt, beim Transportweg sind dann Richtlinien meist schon wieder egal und sie landen im Klartext in irgendwelchen E-Mails. SMS ist auch nicht besser. Prinzipiell ist es nie gut, wenn ein Passwort von mehr als einer Person gesehen wird. Das Passwort an sich ist in den wenigstens Fällen das Problem (Ausnahmen bestätigen bekanntlich die Regel). Je restriktiver der Admin die Passwort Erstellung macht - desto sorgloser ist meist der Umgang der User mit diesem - vor allem wenn es nicht einmal selbst gesetzt wurde.