Seit Freitag, dem 30. Juni ist metalhead.club online - meine eigene Mastodon-Instanz speziell (aber nicht nur!) für Metal-Fans. Zuvor hatte ich meinen Mastodon-Account auf dem Server von Milan. Aus einem spontanen Impuls heraus habe ich mich entschieden, zur Dezentralisierung des Netzwerks beizutragen und ab sofort eine eigene Instanz zu betreiben.
Einige Professoren an meiner Hochschule schützen ihre PDF Skripte mit einem Passwort, sodass sie von fremden Usern nicht geöffnet oder bearbeitet werden können. Da die ständige Passworteingabe im Alltag lästig ist, habe ich mich nach einer Möglichkeit umgesehen, den Passwortschutz zu entfernen - am besten direkt über die Kommandozeile.
Vor kurzem wurde ich via E-Mail auf den Serverhoster FarnoX.de aufmerksam gemacht. Aus eigenem Interesse habe ich ihn mir einmal genauer angesehen und einige Tests auf einem zur Verfügung gestellten Testserver durchgeführt. Kann sich der Hoster gegenüber der Konkurrenz behaupten?
“Kein Backup - kein Mitleid” - ein Motto, das auch ich mir mittlerweile zu eigen mache. Nach einigen Pannen mit fälschlicherweise unwiderruflich gelöschten Dateien musste ich vor einigen Jahren auf schmerzhafte Art und Weise lernen, dass regelmäßige Backups wichtiger Daten nicht ein nettes Feature sind, sondern die Pflicht eines verantwortungsvollen Admins. Das schließt nicht nur Desktop-Rechner ein, sondern vor allem auch Server, die zentrale Dienste bereitstellen, ohne die jeder einzelne User möglicherweise nicht arbeiten kann.
Im Laufe der Jahre habe ich verschiedenste Backup-Lösungen auf meinen Server eingesetzt - Meine aktuelle Lösung gefällt mir aber am besten, daher will ich sie euch in diesem Beitrag kurz vorstellen.
Für meine Statusseite https://status.trashserver.net setze ich aus verschiedenen Gründen einen eigenen Reverse Proxy ein, um auf der Übersichtsseite von Uptimerobot.com HTTPS TLS-Verschlüsselung anbieten zu können. Nach der Einrichtung meines Nginx Webproxies war die Statusseite jedoch regelmäßig nicht mehr erreichbar (“502 - Bad Gateway”). Erst nach einem Neustart von Nginx konnte die Seite wieder aufgerufen werden. Die Ursache für die regelmäßigen Unterbrechungen war eine dynamische IP-Adresse hinter dem Zielhost “stats.uptimerobot.com”. Mit folgender, klassischer Konfiguration wird der Zielhost nur ein Mal beim Start von Nginx aufgelöst: