Gibt`s eigentlich irgendwo ein Statement seitens Netcup wieso in den letzten Tagen so viele DNSSEC Domains plötzlich nicht mehr funktioniert haben? Finde da aktuell nichts.
Die Häufung war aus meiner Sicht dann doch eklatant im Vergleich zu vorher. Ob das eventuell mit dem Beta Test zu tun hat? Zum Glück hat's Monitoring bei mir gefunden.
Hey,
vielen Dank für diese ausführliche Rückmeldung!
Bitte sehr.
| Das ist ein guter Tipp, danke dafür. Darf ich fragen, was du daran abgeändert/abgewandelt hast?
Habe noch ein bisschen Debug drum rum gebaut , dass ich den ausgeführten Befehl / Argumente sehe und der aktuelle Workspace bei default immer mit gemounted wird im Container.
Ich deploye den Forgejo Runner auch per Ansible.
Guten Abend,
ich war früher auch bei Gitlab, nach den groben Einscrhänkungen im Free Tier, und bin über Gitea auf Forgejo gewechselt. Alle meine Repos sind gespiegelt. Zuerst hatte ich Drone CI sowohl mit Gitlab als auch mit Gitea im Einsatz. Letztendlich war es aber immer ein "externes" System und die Entwicklung ist auch etwas eingeschlafen. Woodpecker ist ein Fork von Drone.
Die derzeitige CI Situation sieht schon wesentlich besser aus als es noch vor kurzem der Fall war. Da ich auf der Arbeit auch Github Actions nutze, sind die Synergie Effekte sehr groß. Ich nutze teils öffentliche Actions, teils hab ich mir mittlerweile aber auch welche selber geschrieben für Tasks, welche ich in jedem Repo habe.
Quote
Hier ist mein Docker Image und da sind meine Befehle zum Ausführen
Ja, ein sehr leidiges Thema in Actions. Und nein, ich will nicht nodejs in allen meinen Containern installieren... Als "Workaround" hab ich ne Abwandlung von https://github.com/addnab/docker-run-action im Einsatz. Was ich mag, ich kann als Backup System einfach die offiziellen Github Runner missbrauchen, ohne viel neuen Code zu schreiben. Das mache ich bspw. bei Cross Architecture Builds mit Rust so.
Warum ich nicht "nur" Github nutze: Es gibt gewisse Einschränkungen wie dass die CI sich nach 60 Tagen ohne Commit deaktiviert und so. Diese "Empty" Commit Bots dagegen als Lösung finde ich nicht prickelnd...
Gruß
Ich wollte gerade ISPConfig auf meinem Root Server installieren, da bekomme ich folgende Fehlermeldung:
Code[ERROR] Exception occurred: ISPConfigOSException -> Installing packages failed. (/ispconfig.ai.php:15)
Auf meinem alten Cont*bo Server ebenfalls mit Ubuntu 22.04 klappt es einwandfrei.
Kennt jemand das Problem bzw. den Fehler?
Doofe Frage: Hast du das Skript als normaler Nutzer ohne sudo ausgeführt?
Recht kurz. Hast du da nicht manchmal unnötige Schwenks drin?
Ich bin da etwas großzügiger und prüfe sowieso nur alle 5 Minuten. Außerdem restarte ich zunächst den Stack und wenn das nicht hilft den Server, bevor ich umschwenke, weil das ja nicht selten (nach meiner Erfahrung) ein Problem schon behebt. Aber bei mir ist das alles auch nicht allzu zeitkritisch.
Ich will halt erst dann auf den Failover umschalten, wenn alles andere versagt hat, weil der keine echte Spiegelung ist, sondern da tatsächlich nur das abgespeckte Notfallprogramm drauf ist.
Außer wenn bei Netcup Land unter ist: Nein
Die Failover IP zeigt aber auch auf den HAProxy vor dem Kubernetes Cluster und der kann Cross Node gehen. Services werden größtenteils automatisch restarted, wenn deren Healthcheck nicht grün ist und sie können auf andere Nodes verlagert werden, wenn aus Gründen ( Wartung, Ausfall ) mit 1 was nicht stimmt.
Außer zu Wartungszwecken hab ich mit dem Cluster dann eigentlich keine Berührungspunkte und es läuft munter vor sich hin.
So wie ich es hier im Forum schon mitbekommen habe, geht es den meisten Nutzern eher darum, sehr viele Kosten einzusparen, deswegen habe ich mich dazu unter anderem auch wie folgt geäußert:
Das von mir hier im Forum reingestellte Beispiel sollte kein fertiges System sein, sondern nur als Anregung für eigene Failover-Systeme sein. Denn jeder hat andere Bedürfnisse und wird diese eventuell auch anders lösen wollen.
Verstehe. Das war eine konzeptionelle Frage um zu verstehen, was die Gründe dafür sind. Kostengünstigste Variante ist DNS Failover mit geringer TTL und das beste hoffen 
Ansonsten gibt es natürlich immer folgende Option:
| Es ist leichter, um Vergebung zu bitten, als eine Genehmigung zu bekommen.
Spoiler: Sie werben mit "Unser Object Storage läuft standardmäßig im Hochverfügbarkeitsmodus und wir nutzen die lokale Replikation."
QuoteWir haben derzeit ein Hardwareproblem mit unserem Object Storage – Europäische Union. Unser technisches Team arbeitet aktiv an der Lösung des Problems, wir können jedoch keine voraussichtliche Ankunftszeit angeben. Wir bitten Sie, den Object Storage in den nächsten Stunden noch einmal zu überprüfen.
Display MoreIch habe mehr als nur 2 Failover-IPv4-Adressen und ein Failover-IPv6-Netz, die derzeit auf einem GW-Server geschaltet sind.
Was hältst du oder ihr von zwei GW-Servern, die im Master- Slave-Betrieb laufen würden und auf denen die Failover IPv4-Adressen und das Failover-IPv6-Netz im Störungsfall vollautomatisiert über einen zusätzlichen externen Monitoringdienst, der eventuell auch aus Kostengründen zuhause läuft, umgeschwenkt werden?
Am 21.12.2024 hatte ich aufgrund meiner Antwort #15 hier unter der Überschrift Failover IPv4- oder IPv6-Adresse aus der Ferne von Server A auf B umschwenken auch ein entsprechendes Beispiel abgelegt, mit dem z.B. sowas auch realisiert werden könnte.
Weil sich aber in der Vergangenheit gezeigt hat, dass die Verfügbarkeit bezüglich der Netzanbindung bei Netcup sehr hoch ist, kann ich auch mit meiner derzeitigen Konfiguration recht gut leben.
https://de.wikipedia.org/wiki/Murphys_Gesetz
Ich saß im Auto auf den Weg zum Bodensee, noch 4 Stunden Fahrzeit, als mein Monitoring mich darüber informierte, dass die Failover IP geschwenkt wurde und 1 Server weg ist. Ich konnte dann den Notfall Support erreichen und der konnte mir dann nach späteren Rückruf bestätigen, dass der Wirt ausgefallen war. 10 Minuten später kam dann auch die Meldung vom Support über den Ausfall. Ohne Automatisierung hätte ich den Rest des Tages mit Anrufen und Schlichtungen verbracht.
| über einen zusätzlichen externen Monitoringdienst,
Warum eine weitere Single Point of Failure Komponente dazufügen, wenn man genug Server hat und die API direkt vom Server erreicht?
| Failover IPv4- oder IPv6-Adresse aus der Ferne von Server A auf B umschwenken
Ich mache dir mal einen Gegenvorschlag:
Bei mir sind das 3 Server mit Keepalived Konfiguration, die dann über die API Schnittstelle vollautomatisiert schwenken ( Skript sind ähnlich deinen geposteten, weil gleicher Mechanismus). Diese stehen die ganze Zeit im Kontakt zueinander und prüfen verschiedenste Dienste lokal und nicht nur ob der Webserver selbst bspw läuft.
Auch gibt es Abstufungen / Unterschiede in der Gewichtung. Wenn die Gesamtpunktzahl nicht mehr stimmt und nicht innerhalb 1 Minute wieder healthy ist, wird geschwenkt. Es gibt auch einen Check der von außen mit in die Gewichtung fließt und prüft ob die externe Kommunikation wie erwartet funktioniert. Der lokale Check gegen die FailoverIP ist nicht ohne.
Vorteil ist auch, dass du die ganzen variablen Informationen aus dem Skript nicht erst selbst zusammen suchen muss, sondern diese auf dem System automatisiert abgreifen kannst oder per Ansible ausrollst.
Das ist dann für mich keine praktikable Lösung, da muss ich ja doch wieder um 3 nachts aufstehen oder mich Beamen, wenn was los ist. Da kann ich dann mit den Ungereimtheiten von oben sehr gut leben und Nodes rebooten, bis der Kunde mit dem Schlagstock vor der Tür steht.
In deinem Fall würde ich dann eher die TTL auf 5 Minuten stellen und mir die 10€ für die beiden IPs sparen. Oder einen externen Loadbalancer anbinden.
aber gerade wenn das Umschalten parallel [im Sinne von gleichzeitig] erfolgt wäre ja genau der von Dir erwähnte Effekt ausgeschlossen;
[Blocked Image: https://i.imgur.com/fxSy8lT.jpeg]
Dachte ich auch. Aber "Effekte" im Backend haben dann doch manchmal dazu geführt. Muss dazu aber auch sagen, dass mein Monitoring weit engmaschiger als jede Minute prüft und es daher unter normalen Umständen außer nen kurzen Schluckauf gar nicht merkt. Lustig wird es aber, wenn das Failover Backend Probleme hat oder im VLAN Dinge verrückt laufen. Alles schon erlebt, leider.
Ich nutze meine FaiOverIP´s (IPv4 und IPv6) in der Form, dass ich Diese auf einem vServer als Gateway schalte und den eigentlichen Servern (LXC´s) oder auch weitere vServer von Netcup, die die jeweilige FailOverIP (IPv4 und IPv6) aufgeschaltet haben sollen, über das vLAN zur Verfügung stelle. Somit umgehe ich die damit vom Nutzer michaeleifel angesprochene Wartezeit und eventuell auch weitere Probleme.
Das funktioniert seit ca. einem Jahr ausgesprochen gut.
Die Infrastruktur von Netcup brauche ich nur dann zu bemühen, wenn ich mal von einem alten auf einen neuen vServer als Gateway wechsle.
Was passiert wenn das Gateway ausfällt? Händischer Eingriff?
das vermeidest mit einer Kombination aus echtem Failover und DNS-CNAME-Records
Das Umschalten der IPv4/v6 erfolgt parallel, nicht sequentiell. Trotzdem kam es bei mir manchmal zu diesen Effekten. Deine Lösung dafür hab noch nicht ganz verstanden.
Das Thema Failover ist neben dem "shared Storage" eines meiner Probleme bei Netcup.
Ebenso wie Paul hab ich schlechte Erfahrungen mit DNS Failover, wenn man nicht alle Resolver in der Kette unter Kontrolle hat. Es gibt verschiedene Payment Dienste die bspw einen DNS TTL von 10 Sekunden haben und das versuchen.
Bei der FailoverIP gibt es noch bei DualStack die Situation, dass diese im Falle des Wechsels eventuell auf 2 unterschiedliche Systeme zeigt und dadurch die Antworten nicht konsistent sind. Meiner Erfahrung nach waren es ~20 Sekunden nach dem Auslösen, bis die IP dann auf dem anderen System lag.
Deswegen bevorzuge ich prinzipiell Loadbalancer mit Healthchecks oder bspw HAProxy als ReverseProxy der dann auch bei Bedarf im Hintergrund auf eine andere Node zurückgreift, wenn die lokale nicht antwortet.
Effektiv wird das aber z.B. bei AWS ELB gemacht. Wenn dort eine eine von den 3 Endpunkten für maintenance rausgenommen wird, kommt eine neue IP dazu. Deswegen soll man da mit einen CNAME arbeiten statt die A Records vom LB zu setzen. Aber wahrscheinlich sperrt man dann alle mit den faulty DNS resolvern aus.
Standardmäßig sind es nur 2, können aber X Adressen werden. Und die IPs wechseln in unregelmäßigen Abständen trotzdem durch, daher wollen sie nicht, dass man A records setzt. Die Zeiten für die DNS Auflösung sind dementsprechend nicht prickelnd.
Ich will ja nicht sagen das ich ungeduldig bin, aber… Hat jemand von euch Kontakt zu michaeleifel ?
War mit dem Rad im Training unterwegs und da im Monitoring nichts rot war auch nicht ins Forum geschaut
[Blocked Image: https://photos.fife.usercontent.google.com/pw/AP1GczM_p6d8YPAx4AW96XRmVXVjodYPF2w33euFgWNcEcszWsOeTf0z4L0ahw=w2708-h2031-s-no?authuser=0]
… und richte schöne grüße aus.
Grüße zurück!
Ich glaube ja dass er schon DuckDNS betreibt mit der Infrastruktur
Für mich war es das zweite Event. Bud hat schon vieles geschrieben dem ich zustimmen kann.
Eventuell macht es bei der Menge an Leuten auch Sinn verschiedene Tracks anzubieten mit unterschiedlichem Fokus wo man dann fachsimpeln kann. Bei dem Foreninternen Treffen bin ich sehr gerne dabei.
Gruß,
Michael
Möchte mich nicht beschweren, aber könnte schwören, dass der Serverstandort Nürnberg entsprochen hatte, jetzt geändert worden, auf Europa?
Falls jemand einen "Österreicher" oder in "Amsterdam" loswerden will, würde Nürnberg im Gegenzug anbieten.
Soeben kam nochmal eine Mail zum Event:
So lange auf meinem Namensschild nicht auch "[First Name]" steht, will ich mich nicht beschweren
Kein Problem, ich nehme das gerne
Noch mal, vielleicht hast du es übersehen: Deine Upstream Einträge oben sind falsch, vor allem der arpa Eintrag. Was passiert, wenn du den korrigierst?
Sehe ich ähnlich:
https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#specifying-upstreams-for-domains
Die Domain ist ja nicht fritz.box, sondern der FQDN.
Hallo,
ich kann aus der Beschreibung nicht verstehen, was genau das Problem ist. Möchtest du, dass statt fritz.box => 192.168.178.1 in der Adresszeile vom Browser steht oder was ist das Ziel?
Gruß
Is eigentlich schade, dass es bisher immer noch keine Anleitung zum Einrichten des VLANs zwischen 2. Servern gibt
Das hängt doch auch sehr davon ab, welches OS du nutzt, oder nicht?
Nach einem halben Kasten Fürstenberg Pils (10 Flaschen a 0,5 l) schreibst Du nicht viel. Denn wenn Du nach 5 Litter Bier nicht schläfst rennst Du zumindest viel zur Toilette.
Das Hacke-Peter-Prinzip: Wer mehr isst, als er trinken kann, kann öfter auf die Toilette, als er muss!
https://www.amazon.de/Prof-Dr-Peter-Hacke-Hacke-Peter-Prinzip/dp/3499629992
Natürlich nicht, da es ein Fjord und kein See ist.
Spaß beiseite - ich habe noch nicht herausgefunden, wie ich unter Ubuntu bzw. Gnome ein Panorama-Hintergrundbild über alle drei Bildschirme strecken kann. Wenn jemand weiß, wie das geht, würde ich mich über eine Erleuchtung diesbezüglich freuen.
Nutze Plasma. Der einfachste Ansatz ist selber ein Bild zu "zerschneiden". Mit GIMP geht das in < 2 Minuten und einzeln zuzuweisen.
So sieht's bei mir gerade aus:
