Cronjobs sind praktisch und fast jeder Admin nutzt sie. Leider finden sich häufig auch Jobs in der Liste, die sehr häufig ausgeführt werden (z.B. jede Minute), weil der Admin nicht weiß, wann es tatsächlich nötig wäre, den Job zu starten. Häufig kann hier incron helfen.
Welch sperriger Titel. Aber das Problem kennt wahrscheinlich jeder. Man hat z.B. einen Haufen von Configdateien in einer ggf. verschachtelten Verzeichnisstruktur und will in diese einen neuen Parameter einbauen. Als guter Admin hat man natürlich vorab getestet, wie sich dieser neue Parameter auswirkt. Also gibt es ein paar Configdateien die den Parameter bereits enthalten, andere enthalten ihn noch nicht.
Mittlerweile haben sich auf meinem Server einige Domains und Subdomains angesammelt. Und spätestens seit ich die meisten Dienste über Docker-Container bereitstelle ist meine Nginx-Konfiguration relativ üppig geworden.
Vor einiger Zeit habe ich mir daher ein Ansible-Playbook erstellt, welches mir die Konfiguration etwas vereinfacht.
Ich erstelle gerade noch einen weiteren Bereich für das Blog, um Artikel zu sammeln, die als Nachschlagewerk für häufig von mir erwähnte Anwendungen/Techniken dienen sollen (z.B. SaltStack). So muss ich die dann nicht immer im eigentlich Blogpost erklären oder auf uralte Postings verlinken. Der Bereich wird essentials heißen.
Ich möchte auf den entsprechenden Seiten immer eine Sidebar haben, sowie ein paar wiederkehrende Infos, wie z.B. die Projektseite der erwähnten Anwendung, und/oder das GitHub-Repo. Das Standardtemplate hat zwar eine Sidebar, aber die ist natürlich schon für mein Blog konfiguriert. Außerdem nutze ich das Admin-Plugin für Grav und möchte die Felder für die URL der Projekt-/GitHub-Seite auch dort komfortabel befüllen können.
Wenn man seine Blogsoftware wechselt, möchte man natürlich seine alten Postings in das neue System übernehmen. Viele Bloglösungen bieten daher entsprechende Import/Export-Funktionen an. Grav ist aber in erster Linie ein CMS und keine Blogsoftware. Dementsprechend fehlte eine solche Möglichkeit. Die aktuelleren Artikel habe ich, auch um die Funktionen von Grav auszuprobieren, per Hand übernommen und teilweise Artikelserien zu einzelnen Postings zusammengefasst.
Es sind aber noch etwa 60 ältere Artikel übriggeblieben. Alles per Hand zu übernehmen hätte schon einige Zeit gekostet. Daher habe ich mich für eine automatisierte Lösung entschieden.
Searx ist eine Metasuchmaschine, die jeder auf seinem eigenen Server selbst betreiben kann. Tut man dies öffentlich, sollte man jedoch noch ein paar zusätzliche Vorkehrungen treffen und z.B. Suchanfragen mittels Filtron filtern. Sonst wird man von den angefragten Suchmaschinen schnell ausgesperrt.
Eine regelmäßige Änderung von Kennwörtern ist unter gängigen Betriebssystemen kein Problem. Aber da gibt es ja auch noch SSH-Keys um sich an Servern anzumelden. Auch ein SSH-Key kann natürlich mit einem Kennwort geschützt werden. Der Server an dem man sich damit anmeldet kann aber weder prüfen ob der Key mit einem Kennwort geschützt ist, noch wann dieses gesetzt wurde. Es mag eine Spitzfindigkeit sein, aber gerade die machen ja oft besonders Spaß. In vielen Dokumenten zum Datenschutz wird eine regelmäßige Änderung von Kennwörtern gefordert, ist das bei einem SSH-Key der Fall? Und wie stellt der Admin das sicher?
Amazon Glacier ein Dienst für langfristige Backups. Die Daten werden auf Tapes archiviert, was beim Abruf zu einer etwas längeren Wartezeit führt, da die Daten zunächst vom Band auf eine Festplatte kopiert werden. Dafür ist Glacier geradezu spottbillig (etwa $0.0045 pro GB, bei S3 wären es etwa $0.0245). Hinzu kommen, ebenfalls geringe, Kosten für bestimmte Operationen. Die konkreten Preise unterscheiden sich je nach AWS-Region, eine Übersicht findet sich unter: https://aws.amazon.com/de/glacier/pricing/
Google bietet im Rahmen der Google Cloud Storage zwei Tarife (Coldline und Nearline) speziell für Backups an. Coldline ist für langfristige Backups gedacht auf die weniger als einmal im Jahr zugegriffen wird. Nearline für Daten die seltener als einmal im Monat gebraucht werden.
Die Überwachung von Diensten ist häufig fest in der Hand von Icinga oder Nagios. Aber neben dieser Überwachung ist es oft praktisch auch historische Daten zur Auslastung von Ressourcen zu haben, z.B. um neue Anschaffungen anschaulich rechtfertigen zu können. Aber auch bei der Fehlersuche sind solche Daten mitunter hilfreich. Warum ist der Datenbankserver immer Freitags zwischen 10:00 und 11:00 Uhr so langsam? Wieviel Speicherplatz wird im Schnitt pro Woche zusätzlich belegt und wann sind die Laufwerke voll? Wieviel Traffic verursachen wir eigentlich im Monat? Wieviele Datenbankabfragen verarbeiten wir eigentlich täglich?