Vorhin das erste mal eine pfSense bei Netcup installiert und ich finde schon ziemlich cool wie das Produkt angezeigt wird
Das Release Date ist auch Bestelldatum
Kannst du auch selber auslesen auf Linux:
cat /sys/devices/virtual/dmi/id/bios_date
Vorhin das erste mal eine pfSense bei Netcup installiert und ich finde schon ziemlich cool wie das Produkt angezeigt wird
Das Release Date ist auch Bestelldatum
Kannst du auch selber auslesen auf Linux:
cat /sys/devices/virtual/dmi/id/bios_date
Sorry, falls der Text was kurz ist ( Hab nen Gipsarm ). Kann deine Beobachtungen teilweise bestätigen
- RS4000 G9 mit Debian 12 über Preseed + Ansible, nicht Netcup Imge
- Ich nutze Calico nur mit BGP und dem CloudVLAN, da DualStack
- In den Etcd Logs sehe ich Meldung, dass Requests länger gebraucht haben, dass sind immer nur so sporadisch ~5 Sekunden
Alles anzeigenThema Monitoring:
Szenario:
- Cluster Instanzen A,B,C
- FailoverIP
- Seite X zeigt auf FailoverIP, die normalerweise Instanz A gehört- Sofern Seite X erreichbar ist, reduziert das die Priorität von B und C, sodass diese sich nicht die FailoverIP schnappen
Ich habe mir derzeit was zusammengehackt um mit Curl und JQ über mein externes Monitoring abfragen zu können für den letzten Punkt. Das ist allerdings recht träge und fragt nur einen vorher ermittelten Wert ab. Kennt da jemand einen Dienst oder ähnliches womit ich das einfacher realisieren könnte? Quasi nen CURL Proxy oder so.
Wie schwenkst du die IP denn? Prinzipiell habe ich für solche Szenarien keepalived im Einsatz. Das kann entsprechende Healthchecks und über hinterlegte Skripte direkt mittels Netcup API die Failover switchen. Die Healthchecks sorgen dann dafür, dass die Gewichtung entsprechend hoch oder runter gesetzt wird. Oder geht es jetzt eher darum, dass du die passiven Hosts ebenfalls im Monitoring haben willst?
Hab das nun "erstmal" per Socat gelöst, da shadowsdocks und dante aus Gründen X mit dem Dualstack nicht so wollten bisher.
Socat macht den Redirect auf den Ingress Healthchecks per Failover IP und somit kann ich nun den eigenen Status über remote abfragen:
Socat Kommandos (habs mit SystemD verpackt):
socat TCP4-LISTEN:8080,fork,reuseaddr openssl:example.com.443,verify=0,pf=ip4
socat TCP6-LISTEN:8080,fork,reuseaddr,ipv6only openssl:example.com:443,verify=0,pf=ip6
Lokal kann ich dann:
und kriege was ich brauche, ohne API Limits oder so.
PS: Das CloudVLAN Problem ist auch gelöst.
Da gab's vor einigen Monaten aber einen Bug:
https://forum.netcup.de/sonstiges/smalltalk/p198769-das-längste-thema/#post198769
Das könnte natürlich sein, dass ich das nicht gemerkt habe und jetzt erst beim Umbau aufgefallen ist (hatte es sehr wohl mitbekommen, Danke)
Positiv: Nach 1 Stunde Antwort auf Ticket bekommen
Negativ: Antwort sah nach Textbaustein aus und das Wort "SCP" wurde wohl übersehen und der Sachverhalt war nicht verstanden worden.
Beim Anruf der Hotline danach war der Kollege sehr bemüht den Sachverhalt richtig zu formulieren und musste es nochmals schriftlich bestätigen. Bin mal gespannt was bei raus kommt.
Hast du evtl. vor kurzem einen deiner Server per Inhaberwechsel übertragen.
Ja, aber ich hänge die VLANs immer vorher aus und auf den RootServer ist das noch aktiv.
Sicher, dass das noch dein VLAN ist? (Duck und weg)
Immerhin bezahlen muss er es noch.
So siehts laut CCP aus und laut nmap läuft sonst auch nichts dort aktuell.
Ist das eigentlich eine technische Neuerung, dass man CloudVLANs mit 2,5Gbit nicht in der Netzwerkliste der VPS sieht, oder ist das nen Bug? Das Free VLAN sehe ich.
Wie schwenkst du die IP denn? Prinzipiell habe ich für solche Szenarien keepalived im Einsatz. Das kann entsprechende Healthchecks und über hinterlegte Skripte direkt mittels Netcup API die Failover switchen. Die Healthchecks sorgen dann dafür, dass die Gewichtung entsprechend hoch oder runter gesetzt wird. Oder geht es jetzt eher darum, dass du die passiven Hosts ebenfalls im Monitoring haben willst?
Wie schwenkst du die IP denn? => keepalived
Genau, ich habe bereits Healthchecks im Einsatz die auf Dinge reagieren ( HAProxy nicht erreichbar, Storage nicht Healthy etc.) Die passiven Nodes fragen ab, ob der Webseiten Healthcheck grün ist, oder sie übernehmen müssen, weil was auf der aktiven Node passiert ist, was sie nicht mitbekommen haben. Wenn alle Checks grün sind, wird immer Instanz A die Failover IP haben.
Auf der aktiven Node nimmt CURL dann über den lokalen Shortcut, da die FailoverIP ja auf dem Interface anliegt und der Check deswegen immer grün ist, auch wenn die IP im Netcup Backend nicht auf den Server zeigt. Und für diesen Fall will ich eine Verbesserung.
Thema Monitoring:
Szenario:
- Cluster Instanzen A,B,C
- FailoverIP
- Seite X zeigt auf FailoverIP, die normalerweise Instanz A gehört
- Sofern Seite X erreichbar ist, reduziert das die Priorität von B und C, sodass diese sich nicht die FailoverIP schnappen
Ich habe mir derzeit was zusammengehackt um mit Curl und JQ über mein externes Monitoring abfragen zu können für den letzten Punkt. Das ist allerdings recht träge und fragt nur einen vorher ermittelten Wert ab. Kennt da jemand einen Dienst oder ähnliches womit ich das einfacher realisieren könnte? Quasi nen CURL Proxy oder so.
Das ging schnell:
Du meinst über dnscontrol? Da sah der Export bei meinem Test am WE eigentlich ganz brauchbar aus.
Ich finde es allerdings auch etwas schade, dass es bei netcup keine offizielle Exportfunktion über die API gibt. Bei I**X und deSEC ist das kein Problem
Ja, das war aber auch nur ein ganz kurzer Test und hab die Warnungen in der Ausgabe gelesen. Wenns funktioniert, umso besser. Ich mische aktuell meine DNS Provider und probiere noch Sachen aus, vorzugsweise HE.
Das ist spitze. Kommt bei dir direkt ein brauchbarer Export im bind Format heraus, oder arbeitest du noch nach?
Das kann ich dir nicht sagen, da ich nur die andere Richtung nutze und DNS als IaC pflege damit.
Hab aber gerade bei einem kurzen Test feststellen müssen, dass der Export auf den ersten Blick beim Netcup Provider etwas eingeschränkt ist im Vergleich zu he.
Netcup ist supported, nutze es auch dafür
Option 1.1 ( Falls unbound laufen hast), legst eine local-zone an => https://nlnetlabs.nl/documentation/unbound/unbound.conf/ . Beispielsweise:
local-zone: "infra.local." static
local-data: "k8s-master-1.infra.local A 172.16.0.11"
local-data: "k8s-master-2.infra.local A 172.16.0.12"
local-data: "k8s-master-3.infra.local A 172.16.0.13"
local-data: "k8s-master-1.infra.local AAAA fd72:16::11"
local-data: "k8s-master-2.infra.local AAAA fd72:16::12"
local-data: "k8s-master-3.infra.local AAAA fd72:16::13"
Eventuell so etwas?: https://docs.dnscontrol.org/commands/get-zones
Damit könntest du die auch in DNS Control verwalten.
Jupp, die ersten container werden grad neu gebaut // adduser ist in bookworm-slim nicht mehr dabei
Das einzig "nervige" was ich bisher gefunden habe sind fehlschlagende PIP Installationen wegen Python 3.11 und deswegen Ansible Tasks anpassen musste: https://pythonspeed.com/articl…aged-environment-pep-668/
Vielen Dank an [netcup] Claudia H. und alle Beteiligten für den herzlichen Empfang. Es gab viele technisch interessante Gespräche und informativ. Auch war es nett zu sehen, was andere Leute so bei Netcup "sammeln".
Falls jemand bei der automatischen Standortauswahl Wien erwischt hat, würde ich tauschen
Ich verabschiede mich ins Bett
Die Netcup Enten im Schlossgarten dösen vor sich hin
I don't think they offer Backups/Restore for vServer or RootServer, only for Webhostings => https://www.netcup-wiki.de/wik…ges_Backup_zurueckspielen
For a RootServer you have to do this on your own, so in your case i would guess it's bad luck.
Einen wichtigen Aspekt finde ich, ist die Containersicherheit, insbesondere bei privilegierten Containern
Dazu gucke ich mir die Dockerfiles an, wie werden diese zusammengesetzt
Über welche Zahl sprechen wir hier, nur als grobe Einschätzung?
Ich gucke mir die auch sporadisch an, für alle fehlt mir einfach die Zeit.
ContainerD + NFtables:
Das Kubernetes Setup ist so eingerichtet, dass es das sekundäre Interface nutzt und lauscht + Cloud VLAN. Nur der Ingress lauscht dann auf der Public IP und nimmt die Verbindungen an, sofern der Port in Nftables freigegeben ist. Aktuell sind das nur 5 Stück.
Ich habe tatsächlich nur noch einen Host auf dem Docker selbst läuft und denn ich deswegen nicht venrünftig auf Nftables bekommen ( habe ). Dort darf Docker aber nicht die vorher gesetzten Regeln in Iptables modifizieren "iptables": false
Da dass sowieso eine Build Node ist und nichts anderes außer einem DNS Server dort läuft, kann ich das aber verschmerzen.
Uff, das ist das erste Mal, dass ich vor dem Release "Testing" nicht einmal angeschaut habe. Normalerweise mache ich mich schon monatelang vorher damit vertraut
Same here, werde das heute mal nachholen. Bin mal gespannt ob meine Ansible Playbooks direkt durchlaufen.