Beiträge von Paul

Zitat von michaeleifel

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.

Alles anzeigen

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?

Beliebt war der Mailprovider vor allem in der Piraten Branche. Da hat man gerne solche Mail Adressen genutzt um sich in diversen Foren anzumelden.

Bin heute auf ein interessantes Tool aufmerksam geworden: https://github.com/jtesta/ssh-audit

Da wir es hier ja schon öfter mit dem Thema "Absicherung eines Linux Servers" hatten, ist das vielleicht für den ein oder anderen auch interessant. Gerade den SSH Zugriff will man ja entsprechend abgesichert haben. Beim Thema Ciphers & Co gibt es da einige nützliche Tipps.

Edit: Sehe gerade, es gibt auch ein Online Scan Tool dafür: https://www.ssh-audit.com (ähnlich dem SSL Check von SSL Labs)

Zitat von aRaphael

Wie machen die das eigentlich mit "Redundante Strom- und Netzwerkanbindung", wenn ich jetzt ein SLA+ ordere? Das gilt ja für alle meine RS. Werden die dann alle auf andere Hosts gezogen?

Alle aktuellen Server dürften bereits eine redundante Strom- und Netzwerkverbindung haben. Fokussiert euch bitte nicht auf so sehr auf die Details. Anhand der ID sieht man ja schon, dass es sich hier um ein sehr altes Produkt handelt, was so eigentlich schon längst nicht mehr der aktuellen Zeit entspricht bzw. als Zusatz für alte Produkte entworfen wurde, die eben noch nicht die Features hatten, die mittlerweile einfach zum Standard geworden sind. Die Hardware Garantien machen für neue Server sicherlich keinen Unterschied.

Zitat von hamilrat

Ist man mit diesem SLA Level nicht sogar auf einer hochverfügbaren Hardware?

Es steht folgendes dabei:

Weitere Informationen

Kann auch für bestehende Root-Server gebucht werden. Es kann passieren, dass bestehende Root-Server in dem Fall neu gestartet werden müssen.

Spricht für mich dafür das, der/die Server dann auf einen anderen Host verschoben werden.

Alles anzeigen

Das dürfte vermutlich nur für sehr alte Server bzw. Verträge zutreffen. Die Root Server der letzten Generationen haben ja sowieso schon alle 99,9% garantierte Mindestverfügbarkeit. Wenn man einen aktuellen RS Server hat, wird der sicherlich nicht verschoben. Hier dürfte das höhere SLA Level höchsens im Support Fall eine Rolle spielen - wenn man Glück hat

Ist das mit dem aktiven DNSSEC eine spezielle Anforderung des neuen Registrars? Generell dürfte es ja eigentlich nicht nötig sein, dass vorher zu deaktivieren. Ich meine ich hätte auch schon einige Domains mit aktivem DNSSEC erfolgreich innerhalb weniger Minuten transferiert (ok, waren jetzt keine .me Domains, sondern .org bzw. .com), aber eine allgemeine Anforderung scheint es mir jetzt nicht zu sein. Der neue Registrar könnte das ja auch einfach selbst überschreiben.

Zitat von ASS

Sagst du da wirklich gerade "selbst schuld, wenn du zu einem scheiss Provider gehst"?

Irgendwie schon. Die Funktionalität von Netcup bzw. was möglich ist, ist ja eigentlich bekannt. Dass DNS funktionieren soll, ist natürlich ein anderes Thema. Keine Frage. Das sollte ohne solche Probleme funktionieren. Das will ich nicht schön reden. Es geht ja eigentlich eher darum, dass wir den Eindruck haben, dass du das Problem von der falschen Seite aus betrachtest. Ich hatte auch schon Probleme mit dem Netcup DNS. Es wurden "custom" Nameserver eingetragen, im CCP auch sichtbar, aber die Änderungen wurden nie umgesetzt. Daher muss man das immer von extern her aus testen und verifizieren. Die Angabe im CCP muss nicht zwingend die sein, die tatsächlich nach außen hin sichtbar ist. Und darum geht es ja eigentlich. Wenn du mit dem DNS Feature von Netcup Probleme hast, bringt es dir ja wenig, wenn dir Netcup ein CSV mit evtl. falschen Daten zum Download anbietet und du dich in falscher Sicherheit wiegst. Kontrollieren musst du das immer extern, ob die Daten tatsächlich denen entsprechen, die du gerne hättest. Du hast ja schon klar erklärt, dass du dem Netcup DNS nicht mehr zu 100% vertraust. Aber dann darfst du auch einem angebotenen Download von Netcup nicht zu 100% vertrauen.

Was macht man denn privat mit 1000 Domains? Das sind ja auch entsprechende Kosten, die ebenfalls allein für die Domains im vierstelligen Bereich liegen dürften. Es gibt ja gerade für DNS einige Provider, die hier etwas mehr an API Funktionalitäten bieten. So ein bisschen klingt das schon nach selbstgewähltem Schicksal.

Da fehlt der Doppelpunkt, der sich in meinem Telnet Beispiel verlaufen hat. Nehme ich auf meine Kappe

Ich hatte im telnet Beispiel oben leider einen kleinen Fehler. Dort bitte keinen Doppelpunkt zwischen Host und Port nutzen. (Leider durch C&P nicht gesehen). Das war auch mehr als Hinweis gedacht, nicht um es 1:1 einfach so zu kopieren.

telnet HOST PORT

Der Rest sieht etwas verstörend aus. Du musst die Platzhalter schon noch durch die richtige IP ersetzen. im curl Befehl darf dann natürlich kein telnet mehr vorkommen, sondern schon das richtige Protokoll:

curl -k https://127.0.0.1:9443

Teste auch mal, ob du auf dem Server selbst auf Portainer zugreifen kannst, z.B. mit telnet

$ telnet SERVER_IP:9443
$ telnet 127.0.0.1:9443

Danach auch mal direkt mit curl. Um sicher zu stellen, dass die App überhaupt richtig läuft und die Docker iptables Regeln richtig funktionieren. Danach kannst du den Zugriff von extern debuggen.

Zitat von KosMos

Kann man ja über VPN schützen. Mit ner fritzbox und wireguard oder halt einer

Zusatzsoftware z.B. Openvpn aufm PC.

Könnte ich evtl. machen, Firewall evtl auch.

Reicht der Speicher für den desktop Kram?

Was hast du denn mit dem Server vor? Generell ist zu beachten, dass solche VPS keine GPU Beschleunigung haben. Dadurch fallen eigentlich schon mal alle "modernen" Desktop Oberflächen raus (wie z.B. KDE, Gnome, Cinnamon). Das muss man allerdings dann auch für alle Applikationen beachten. Wenn es ein Desktop OS sein soll, dann werden vermutlich auch Desktop Apps zum Einsatz kommen. Die werden dann allerdings auch mehr oder weniger gut oder schlecht laufen. Muss man mal testen. Generell halte ich einen VPS 200 für ungeeignet für ein Desktop OS. Mit 2 GB RAM kommt man heutzutage nicht weit. Du willst ihn ja auch für was benutzen.

Als ersten Schritt kann man auch einfach ein Git Repo mit Markdown Files pflegen. Falls man dann doch lokal eine "hübsche" Oberfläche möchte, könnte man auf ein Tool wie https://www.mkdocs.org/ zurückgreifen. Es muss ja nicht immer direkt eine gehostete Software sein. Oft reicht ja auch ein einfacher Sync (über Git). Wikis, Dokumentationen, etc. willst du zur Not auch offline zur Verfügung haben. Wenn du das auf deinem Webhosting laufen lässt und irgendwann einen Fehler machst, deine Doku nicht mehr erreicht ist, du aber in der Doku nachschauen willst, wie oder was du gemachst hast, ist das etwas blöd .

Dann schau dir mal an, wie das auf deinem System bisher aussieht. Ist natürlich von Distribution zu Distribution leicht unterschiedlich. Würde jetzt mal auf Debian/Ubuntu tippen. Daher dürfte das wohl in

/etc/nginx/sites-available
/etc/nginx/sites-enabled

sein. Also genauso wie auch bei Apache in Debian/Ubuntu. Schaue dir mal die bestehende vHost Konfiguration von deinem Mastodon an. Dann sollte klar sein wie du das anlegen musst.

Wenn du dem Tutorial gefolgt bist, hast du bereits eine laufende nginx Instanz. Dann geht es nur darum, einen weiteren vHost einzurichten, der Ziel bzw. Cache für die Medien sein soll. Die entsprechende vHost Konfig ist ja in dem Blog Artikel bereits mitgeliefert. Du müsstest da jetzt nur die entsprechenden Daten ändern (S3 URL, Credentials, deine eigene Domain, ...).

Um da helfen zu können, müssten wir schon wissen, wo es da genau scheitert. Hast du denn bereits einen S3 Provider und ein entsprechendes Bucket? Das wäre ja der 1. Schritt.

Was genau verstehst du denn nicht? Welchen Reverse Proxy, Webserver hast du denn bisher im Einsatz? Falls es nicht nginx ist, kannst du das ganze auch erst einmal ohne nginx proxy cache machen und den S3 Storage direkt anbinden. Die verlinkte nginx Config ist im Grunde nur ein zusätzlicher lokaler Cache. Vermutlich auf Dauer schon nützlich, aber erst einmal nicht zwingend, wenn es nur darum geht, mal einen externen S3 Storage zu testen.

Signaturen erlauben ist wie ohne Adblocker surfen! Macht man nicht

Bildschirmfoto vom 2023-05-02 16-02-01.png

Zitat von Interessent

Ist ein kompletter Snapshot über das Netcup SCP.

Ja, aber auch dieser lässt sich ja "online" erstellen ohne dass das System vorher einen sauberen Neustart getestet hat. Wenn du Änderungen am System vornimmst und alles noch läuft, muss das nicht zwangsläufig heißen, dass das nach einem Neustart immer noch der Fall ist. Ein Zurückspielen des Snapshot erzeugt aber in jedem Fall einen (neuen) Start des Systems, weswegen Probleme durchaus auch durch das Zurückspielen des Snapshots auftreten können. Das wäre im Moment nämlich auch mein Verdacht, weswegen ich dazu raten würde, das ganze nochmal sauber neu aufzusetzen. Du willst ja wissen wie dein System funktioniert. Daher ist diese Flickerei jetzt nicht wirklich auf Dauer sinnvoll.

Zitat von Interessent

ISt wirklich sehr merkwürdig, denn der Snapshot wurde ja abgelegt, nachdem geprüft wurde, ob alles geht. Das ist ja schon ein Wireguard Container enthalten der auch läuft...

Hattest du denn vorher auch mal einen Neustart getestet? Oft zeigen sich gerade solche Netzwerk Probleme erst nach einem Neustart des Systems. Wenn der Snapshot "online" erstellt wurde, stellt er zwar alle Dateien wieder her, aber nicht zwangsläufig den vorherigen Zustand. Mit den gelieferten Informationen ist das auch alles etwas mühsam. Ich würde wirklich empfehlen einfach mal alle Daten zu sichern und nochmal neu anzufangen. Das System sauber aufsetzen und dann mal nach und nach die Konfigurationen und Daten wieder einspielen.

Zitat von Interessent

telnet 52.1.184.176:443
telnet: could not resolve 52.1.184.176:443/telnet: Name or service not known

telnet registry-1.docker.io:443
telnet: could not resolve registry-1.docker.io:443/telnet: Name or service not known

Bitte genau hinschauen. Der Doppelpunkt darf da nicht hin. Domain/IP und Port müssen durch ein Leerzeichen getrennt werden. Führe das bitte nochmal ohne Doppelpunkt aus.