Beiträge von Mikey

  • netcup Sicherheitstoken

    Ich hab bei mir seit Monaten / Jahren das normale 2FA aktiv, daher hab ich das wie einige andere gar nicht mitbekommen. Es gibt hier einige Punkte, welche ich nachvollziehen kann.


    Aber mal im Ernst, wenn ihr eh bereits Zugangsdaten von den "Kunden" habt, wo ist das Problem einfach das normale 2FA aktivieren und das 2FA Secret zu sharen? Ja ist nicht 100% sicher, aber ist doch genau wie ein Backup vom Secret eine Möglichkeit den Zugang ohne großes Drama zu erhalten. Dann hat man im Falle der Fälle auch keine Briefkosten und Wartezeiten.


    Klar, Backup Keys und SMS Reset wären toll. Außerdem eine frühere Ankündigung, damit sich diese Spezialfälle vorab um den Zugang kümmern können.

  • Für was sammeln manche kleine Server?

    Für mich sind die kleinen Server hauptsächlich für geringe Monitoring Aufgaben da.


    Teilweise skaliere ich damit auch Workloads. Meistens sind das "Aufgaben", welche asynchron sind und gut skalieren. Beispiel Dinge aus einer Datenbank ziehen und weitere Berechnungen darauf durchführen, welche jetzt nicht schnell sein müssen. Man kann sich kaum vorstellen, wie viel selbst ein Single Core auf 24h bringt, wenn man eine riesige Menge (zu einem kleinen Preis) bearbeiten möchte.


    Ich bin aktuell mit 17 Servern bei netcup, wobei davon 5 RootServer wegfallen, da alt und ich auf neue Umsteige, daher 3 neue, welche bleiben. Dann noch die kleinen Server 8 Stück an der Zahl und noch einen ARM VPS zum Testen, ob gewisse Workloads darauf besser laufen. Wird also stand jetzt auf 12 Server bzw. 11 nach dem ARM Test hinaus laufen.

  • Aktuelle Benchmarks RS / VPS Produkte

    Hier noch einmal von meiner Seite einen VPS 1000 ARM G11 NUE (also in DE-Nürnberg), wenn die Performance so bleibt, werde ich wohl einiges auf ARM64 migrieren. Geht dank gutem Docker Support meiner meisten Anwendungen dann ganz gut.

  • Unsere Aktionen zum Black Friday 2023

    Lob:

    Die diesjährigen BlackFriday und CyberMonday Angebote waren aus meiner Sicht sehr gut. Laufzeit und Preis fand ich für meine Anwendung sehr gut. Die vorherige Domain Week finde ich auch immer angenehm, da ich einfach abends im CCP bestellen kann, ohne auf die Uhrzeit achten zu müssen.


    Verbesserungen:

    - Durch mein CGNAT bei IPv4 werden auch IPv6 wichtiger, da bessere Latenz usw.. Da wäre eine Failover IPv6 im Angebot auch toll, verstehe nicht wieso die IPv6 so teuer sind. IPv4 sind doch knapp, dann sollte doch IPv6 günstiger sein? Plump gesagt: "Wo Angebot IPv6 Failover?"

    - Die Mail "A Server has been created" enthält nur die IPv4 und nicht die konfigurierte IPv6 des jeweiligen Servers, obwohl diese ja beim Debian12 minimal konfiguriert wird. Der DNS (z.B. v220XXXXXXXX.quicksrv.de) hat auch nur einen A Record und keinen AAAA Record.

    - (optional, da vermutlich so gewollt) Angebote länger in den Abend laufen lassen, bei mir komme ich frühstens gegen 17 Uhr dazu mir die Angebote anzuschauen. Dieses Mal war es schon deutlich angenehmer, nicht vor 18 Uhr (glaube letztes Jahr war es so) bestellen zu müssen.

  • Aktuelle Benchmarks RS / VPS Produkte

    Anbei 3 Benchmarks von meinen piko nano mikro Servern:

  • Halloween Aktionstag am 31.10.

    Zitat von [netcup] Alexander W.

    Du meinst damit die monatliche Laufzeit, sprich ohne Mindestlaufzeit?

    Ich meinte, ich möchte jeden Monat kündigen können, zum nächsten Monat reicht mir schon. Die letzten Angebote waren (sofern ich keins übersehen habe alle 12 Monate Laufzeit). Das ist für meinen Anwendungsfall kurzfristig Ressourcen für einen Monat zu holen und wieder abzugeben unattraktiv.


    Alternativ wäre ein Up/Downscaling von Servern interessant, konnte damit gestern für <1 € bei einem anderen Hoster aus der Nürnberger Ecke mal so eben alle ARM und AMD Cloud Instanzen durch testen. Davor mit der kleinsten Config jeweils ein kleiner Benchmark via Ansible aufgebaut, welcher meinen Anwendungsfall betrifft aufgesetzt. Nach <2 Stunden (Hab mir einen Film währenddessen angeschaut) hatte ich eine Tabelle mit den Werten und konnte so zum Beispiel feststellen, dass ARM bei meiner Anwendung einfach nicht so performant ist, wie ich es mir vorgestellt hätte.

  • Hostnames für Cluster

    Bei mir sind diese in diesem Schema


    prod-de-nbg-nc-69 .meine.domain


    Also prod/test + CountryCode + Ort/Stadt + Anbieter + Servernummer


    Hab damit etwa 30 Server im Betrieb und finde damit es gut auffindbar. Rest macht dann Ansible mit den Inventory's.

  • Halloween Aktionstag am 31.10.

    Ich hätte gerne Server mit 1 Monat Laufzeit und Abrechnung. Leider wieder nichts dabei. Bei einigen Mitbewerbern gibt es diese ohne Probleme, würde halt gerne meine Ressourcen über mehrere Anbieter verteilen.


    Gerade wenn man flexibel sein will, kann man seit etwa 2019 die Angebote in die Tonne klopfen.

  • Das längste Thema

    Also für alle mit Probleme bei Failover v6 ich hab gerade raus gefunden, dass zumindest meine Failover nach einem umhängen auf EGAL welchen Server komplett ins nirgendwo routet. Sobald ich die Failover auf der "alten" Server zurück gebe kommen Pings an. Heißt für mich die Failover macht kein Failover, obwohl alle Server via Ansible eingerichtet wurden und dass Failover mindestens 3 Mal ohne Probleme ging.


    Komischerweise ist die Failover v4 nicht betroffen bei mir. Naja morgen dann Server umziehen, ich tue mir das Debugging von komischen Routing verhalten nicht mehr an.


    Lustiger Fun Fact ist mir beim manuellen Pingen an verschiedene Hosts aufgefallen, kann jeder ja mal schauen. Die Server sind alles RS 1000 G9.5 a1 in Nürnberg (laut CCP) und wurden im Januar bestellt. Command:


    mtr speedtest.novoserve.com -w -c 10

    2 meiner aktuellen 3 produktiven Servern routen via Österreich, obwohl alle in Nürnberg stehen?

  • Das längste Thema

    Ja leider bringt mir der Swarm recht wenig, wenn alle Server gleichzeitig kein Netzwerk haben. Außerdem routet meine Failover v6 seit 23:15:44 nicht, heißt mein Cluster ist defacto nicht erreichbar. Kann die Failover umhängen, das ändert jedoch nichts an der Erreichbarkeit. Bin gerade echt unzufrieden.

  • Probleme beim Aktivieren von Python im Webhosting

    Hat sich erledigt.


    Problem ist die Kombination von Firefox und Plesk Optionsseite für Python (alles andere geht nur diese verdammte Python Seite mag er nicht). Ich habe keine Ahnung wieso (sehe auch keine Javascript Errors), aber via Chromium funktioniert es nun. Ich hätte gerne meine 3 verschwendeten Stunden zurück......

  • Probleme beim Aktivieren von Python im Webhosting

    Hallo zusammen,


    ich bin gerade etwas am verzweifeln, da meine django Python Anwendung nicht auf dem Webhosting läuft. Um genauer zu sein, gar nichts läuft.


    Ich bin bereits auf der Suche nach der Ursache auf folgenden Beitrag gestoßen: https://forum.netcup.de/netcup…bhosting-8000/#post156843


    An dem Punkt erst einmal danke für den tollen Beitrag :thumbup: conda und die Abhängigkeiten konnten via SSH/bash auch alle installiert werden. Nun jedoch zu meinem Problem.


    Im CCP hab ich bei meinem Webhosting EiWoMiSau gar keine Python Option, diese sehe ich nur wenn ich ins Plesk Frontend springe. Dort sehe ich auch, dass Python in meinem Produkt vorhanden und aktiviert ist (im Reiter Konto)


    Wenn ich nun auf meine Domain "beispiel.de" gehe und dort auf den Punkt Python gehe sehe ich folgendes:


    pasted-from-clipboard.png


    Wenn ich jetzt auf "Einschalten" klicke kommt folgende Meldung:


    pasted-from-clipboard.png


    Ich verstehe den Sinn der Meldung und hab dann auf "Ausschalten" gedrückt. Gebe in den Einstellungen das Verzeichnis an, wo meine passanger_wsgi.py liegt. Gehe auf "Einschalten" und alle Anpassungen werden verworfen. Sprich ich kann den Pfad, die Datei und die Python Version gar nicht anpassen. Egal in welcher Kombination wird alles was ich dort mache verworfen, sobald ich auf "Einschalten" klicke.


    Ist das normal, oder muss ich dort irgendetwas spezielles beachten. Oder ist einfach auf meinem Host (a2f24) das allgemein ein Problem. Vermutlich wird es nicht ohne der Support gehen aber ich finde das extrem komisch, da ja Plesk die Einstellungen nicht annimmt.


    Ein Hinweis auf die Richtung, in welcher ich noch schauen könnte wäre gut. Eventuell muss ich ja noch irgendwo in der Hosting oder Webserver Einstellungen etwas aktivieren? Die Frage ist nur was?

  • Das längste Thema

    Also der Server in VIE hat eine Latenz nach NBG von ca. 9,2 ms und die Performance von meinem alten G8 aus NBG ist nahe an den 1Gbit/s (mehr geht damit halt nicht) mit iperf3 gemessen.

  • Backbone / Routing Q&A

    Habe gerade ein "merkwürdiges" Routing in Richtung Telekom -> Nürnberg:

    Frankfurt -> Wien -> Nürnberg? Latenz ist normal bei ca. 9-12ms damit jetzt bei ca. 30ms


    Komischerweise ist das ganze aus dem in Interxion Madrid "direkt" aus Frankfurt -> Nürnberg (man beachte den "Umweg" über Amsterdam):

    Code
    traceroute to YYY.YYY.YYY.YYY (YYY.YYY.YYY.YYY), 30 hops max, 60 byte packets
1  10.77.13.1 (10.77.13.1)  1.372 ms 
2  10.60.44.5 (10.60.44.5)  1.725 ms 
3  10.50.110.67 (10.50.110.67)  31.419 ms 
4  ae3-1337.bbr02.anx63.ams.nl.anexia-it.net (80.249.213.102)  32.219 ms 
5  ae2-0.bbr02.anx84.nue.de.anexia-it.net (144.208.208.213)  53.839 ms 
6  netcup-gw.bbr02.anx84.nue.de.anexia-it.net (144.208.211.11)  53.453 ms 
7  YYYYYYYYYYYY (91.204.45.100)  53.775 ms

  • Das längste Thema

    Ja ist bei mir auch kaputt alle "Tabs" gehen nur bei Netzwerk kommt ein Fehler. Die normalen IP's scheinen noch zu gehen nur Failover scheint betroffen zu sein.


    Edit: Bei mir genau seit 20:01 Uhr kaputt - noch nicht behoben/gelöst. Hatte aber gestern und vorgestern Probleme, dass die Failover einfach nicht mehr auf einen Server gezeigt hat. Dann musste ich diese einfach neu zuweisen, dass geht jetzt natürlich nicht mehr aufgrund der Fehlermeldung. pasted-from-clipboard.png

  • IPv6 Failover Probleme mit dem Routing

    Sorry für den Doppelpost.

    Das Problem ist behoben. An für sich war der Fehler auf meiner Seite, jedoch auch ein "komisches" verhalten von Debian.


    Lösung:


    Es müssen auf dem Server:

    - Die eigentliche IPv6 (Server eigene) als network Interface angelegt werden

    - Die Failover IPv6 (die man sich aussucht z.B. für DNS) angelegt werden

    - UND die IPv6, welche die Failover IPv6 im SCP anzeigt, angelegt werden. (also IPv6 Failover + Link Local vom jeweiligen Server)


    Der letzte Punkt war mein Problem und ich konnte ihn auch nachstellen. Ich habe damals 2019 mit Ansible die Netzwerk Konfiguration erstellt. Dann ging einmal alles und ich habe geschaut, was denn "überflüssiger" Ballast darin ist. Dabei konnte ich (geht immer noch) die oben letzte genannte IPv6 entfernen und das networking restarten, ohne dass es irgendeinen Impact zu Schein hatte. Großer Fehler, denn irgendwo scheint Debian für 1800 Sekunden alle Routen nochmals zu "cachen". Danach funktioniert das ganze via Failover IPv6 einfach nicht mehr.

  • IPv6 Failover Probleme mit dem Routing

    Zu den sysctl Einträgen: Habe ich auch bereits getestet, dass war gestern (ja apply und reboot brachten dort auch nichts). Die Einträge sind laut Commands aktiv und werden soweit korrekt genutzt.


    Das mit dem erst Pakete von meinem Server los senden: Müsste das nicht durch die Pings bereits erledigt sein (sofern ich als Absender die Failover IPv6 nutze?), oder muss ich da etwas weiteres beachten?

    Habe gerade via mtr nochmal geschaut, jetzt bekomme ich von der Failover v6 gar keinen Host in Richtung extern mehr angezeigt?!? (Wenn ich eine falsche Absender IPv6 angebe bekomme ich korrekterweise "mtr: Address not available")


    Failover v6 nach netcup.de:

    Code
    Start: 2021-02-27T20:52:57+0100
HOST: rcluster2 Loss%   Snt   Last   Avg  Best  Wrst StDev

    Servereigene IPv6 nach netcup.de:

    Code
    Start: 2021-02-27T20:56:45+0100
HOST: rcluster2            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a03:4000:2b:1000::2  0.0%     1    0.6   0.6   0.6   0.6   0.0
  2.|-- 2a03:4000::e01e       0.0%     1    0.4   0.4   0.4   0.4   0.0


    Wie schon beschrieben die servereigene IPv6 funktioniert genau so wie ich es auch von der Failover IPv6 erwarten würde. Habe auch nochmal via "ip a" und "ip -6 r" geprüft, dort ist nichts auffälliges von meiner Seite aus.

  • IPv6 Failover Probleme mit dem Routing

    Sorry für den doppelt Post aber das hier ist mir auch noch aufgefallen, war aber für das Erstellen zu lange:



    Was ich komisch finde, sind die letzen beiden MTRs von extern nach Failover v6 vs. direkte IPv6 man sieht, dass vor meinem Server noch die "2a00:11c0:47:3::21" kommt. Diese IP ist bei der Failover nicht erreichbar?


    Bin gerade etwas ratlos, ob ich hier etwas nicht verstehe, oder ob die FailoverIPv6 einfach nicht sauber auf meinen Server zeigt. Ich weiß auf jeden Fall, dass die Failover IPv6 damals als ich sie initial via Ansible eingerichtet hatte ohne Probleme erreichbar war.



    So nachdem dieses Buch geschrieben ist, hoffe ich auf konstruktives Feedback. Echt nervig, wenn etwas nicht so tut, wie man es gerne hätte....