Mysqldump - trotz Exitcode 0 keine Daten im Dumpfile
Ich verwende diesen Aufruf, um Schemata auf dem Mysql Server zu dumpen:
mysqldump --opt --default-character-set=utf8 --flush-logs --single-transaction --no-autocommit --result-file="$_dumpfile" "$_dbname" 2>&1 $myrc=$?
… und stand vor dem Phänomen, dass der Exitcode 0 war - also eigentlich den Erfolg meldet - aber es keinerlei Daten im Dump gab.
Das Betriebssystem war ein Centos8 Stream. Das Problem lag in der Option –flush-logs, die nicht ausgeführt werden konnte, da das Verzeichnis /var/log/mysql/ (warum auch immer) nicht mehr vorhanden war. Dass ein leerer Dump ohne Daten erzeugt wird und kein Exitcode > 0, ist m.E. ein Fehler im mysqldump. Und den versuche ich, zu umschiffen.
Ich habe nach dem Dump noch einen Check hinzugefügt, der das Vorhandensein auf mind. ein CREATE oder aber INSERT Statements prüft. Oder anders: wenn man eine (korrekte) leere Datenbank ohne einzige Tabelle oder auch nur 1 einzigem gesicherten Datensatz hat, würde ein Fehler beim Backup gemeldet. Ich meine, damit lässt es sich leben.
mysqldump --opt --default-character-set=utf8 --flush-logs --single-transaction --no-autocommit --result-file="$_dumpfile" "$_dbname" 2>&1 $myrc=$? if [ $myrc -eq 0 ]; then if ! zgrep -iE "(CREATE|INSERT)" "$_dumpfile" >/dev/null then typeset -i local _iTables _iTables=$( mysql --skip-column-names --batch -e "use $_dbname; show tables ;" | wc -l ) if [ $_iTables -eq 0 ]; then echo "EMPTY DATABASE: $_dbname" else echo "ERROR: no data - the dump doesn't contain any CREATE or INSERT statement." # force an error $myrc=1 fi fi fi if [ $myrc -eq 0 ]; then echo "OK" # Und dann hier noch komprimieren... # gzip $_dumpfile" # ... und Erfolg der Kompression auswerten else echo "ERROR: mysqldump failed." fi
Update:
- 24.03.2022 - eine leere Datenbank würde als Fehler gemeldet - daher zähle ich mal noch die Tabellen
weiterführende Links:
- mysql.com: mysqldump
- mariadb.com: mysqldump
- IML open source: IML-Backup (mein Backup Tool an unserem Institut zum lokalen Dumpen div. DBs und Backup mit Restic/ Duplicity)
- DOCs: os-docs.iml.unibe.ch/iml-backup/
20 Jahre Axels Cron-wrapper
Ich habe grad in die History geschaut: 20 Jahre (!!!) nutze ich schon den meinigen Cronwrapper auf Linux/ Unix-Systemen.
Und ich bin noch immer am Aktualisieren und Verfeinern von dessen Skripten oder Dokumentation. Auch weil ich dessen Idee so mag. Alles ist OpenSource - GNU GPL 3.0.
Das Repository [1] enthält
- cronwrapper.sh - ein Wrapper - wenn man Cronjobs hat, dann stellt man den einfach mal vorn dran
- cronstatus.sh - das Skript zeigt den Status aller auf dem System befindlichen Cronjobs
- inc_cronfunctions.sh - ein Script, dass in Bash geschriebene Cronjobs gesourct werden kann, um div. nützliche Funktionen zu nutzen.
- Dokumentation im Markdown Format zur Installation und allen Features.
Der einfachste Einstieg ist, den Wrapper cronwrapper.sh zu verwenden: mit allen bestehenden Cronjobs, egal welcher Programmiersprache jene sind, lässt sich dieser ergänzen. Und man erhält out-of-the-box kleine nette Features.
- STDOUT und STDERR werden eingefangen und in ein normiertes Logfile geschrieben (ohne jenes explizit angeben zu müssen)
- Das Logfile wird normiert und ist mit grep nach Output oder Metadaten durchsuchbar
Alle Cronjobs, die den Wrapper verwenden, werden mit dem Skript cronstatus.sh aufgelistet und bewertet:
- weisen sie exitcode 0 auf?
- sind sie in der vorgegebenen Frist gestartet worden?
Diese Ausgabe kann man auch in einem Monitoring Script für die Überwachng aller Cronjobs auf seinen Systemen einbinden.
Und als Goodie gibt es ein Include file inc_cronfunctions.sh,welches hilfreich sein kann, sofern die Cronjobs in Bash geschrieben sind: eine Reihe nützlicher Funktionen werden darin bereitgestellt, um das Schreiben von “sicheren” und lesbaren Conjobs zu erleichtern.
weiterführende Links: (en)
- Github: cronwrapper
- Docs auf axel-hahn.de
IML Appmonitor ist nun PHP 8.1 kompatibel
Der Appmonitor ist eine PHP-Applikation mit geringstmöglichen Anforderungen. Mit dieser lassen sich andere (Web-)Applikationen in einem Webfrontend überwachen und bei Statuswechsel Notifikationen per E-Mail und Slack an die am Projekt beteiligten Personen auslösen.
Das Applikationsmonitoring ergänzt unser System-Monitoring, weil es die applikationsseitigen Checks aus Sicht der Applikation und mit den Rechten der Applikation ausführt.
Der Appmonitor ist Freie Software, Opensource und untersteht der GNU GPL 3.0.
Nach gefühlt 2 Jahren habe ich am IML Appmonitor weitergecodet. Es sollte PHP 8 kompatibel werden. Und weil soeben PHP 8.1 erschienen ist, wurde es nun auch für ebenjene Version 8.1 fit gemacht:
Tadaaa: der Appmonitor ist die erste PHP 8.1 kompatible Opensource Applikation unseres Instituts :-)
Zudem wird die Plugin-Unterstützung vorangetrieben, es kam eine grafische Darstellung der Checks in einem ersten Wurf hinzu und die Möglichkeit, die Checks nach vorgegebenen Gruppen zu clustern. Die Notifikation eines Fehlers erfolgt nicht beim ersten Auftreten, sondern wird erst bei der 3. Wiederholung ausgelöst.
Ich bin gerade motiviert, weitere Updates einzubringen und nachzuliefern. Es gibt beispielsweise vorgefertigte Checks für einige PHP-Applikationen, wie Wordpress, Ilias LMS, Concrete5 und Matomo. Diese befinden sich in einem separaten Repository und werden in Kürze in das Repo integriert.
weiterführende Links:
Mysql Replikation neu aufsetzen als Bash Skript
Wenn eine bestehende Mysql Replikation nicht mehr funktioniert, so half mir etliche Male im Laufe der Berufszeit als Webmaster beim Schweizer Radio DRS / Sysadmin Daseins an der Uni Bern ein top-down-Skript weiter. Wenn gerade Stress ist und man in der Situation nicht erst alle Kommandos zur Wiederinbetriebnahme des Slave nachschlagen mag, dann ist ist man froh, wenn man ein Skript dafür parat liegen hat.
reinit_mysql_replication.sh
Es gibt keine Parameter.
Installation:
Man benötigt einen Mysql Client. Ich hatte daher die Skripte am Mysql-Slave unterhalb /root zu liegen. Daher ist die Verbindung zum Slave ohne Passwort (wird aus der /root/.my.cnf gelesen).
Es wird auch vom eigenen Rechner aus funktionieren, der die Mysql-Ports von Master und Slave erreichen kann. Es ist nur “einen Tick” langsamer (sprich: bei vielen und/ oder grossen Datenbanken > 1 GB Gesamtgrösse nicht zu empfehlen).
Konfiguration:
Die *dist Datei ist umzukopieren und die Hostnamen und Root-Passwörter für Master + Slave sind zu setzen.
Start:
Das Skript reinit_mysql_replication.sh führt der Reihe nach folgende Aktionen aus: es …
- zeigt aktuellen Slave Status
- wartet dann auf ein RETURN, bevor die Replikation neu aufgesetzt wird
Aktionen zum Neuaufsetzen der Replikation: das Skript …
- liest die Position des Binlog am Master (per SQL “SHOW MASTER STATUS G;”)
- sperrt den Master für Schreibaktionen (”FLUSH TABLES WITH READ LOCK;”)
- holt aktuelle Datenbank-Dumps vom Master (mysqldump –all-databases –lock-all-tables …)
- hebt Schreibsperre am Master auf (”UNLOCK TABLES;”)
- stoppt den Slave (”STOP SLAVE G;”)
- importiert Dumps des Master auf dem Slave (cat $dumpMaster | mysql $paramdbSlave)
- setzt am Slave binfile und Position (”CHANGE MASTER TO MASTER_LOG_FILE = …” ; “CHANGE MASTER TO MASTER_LOG_POS = …”)
- startet den Slave (”START SLAVE G;”)
weiterführende Links:
Restic client auf 64 Bit Linux installieren
Restic [1] ist ein in Go geschriebenes Backup-Tool für die Kommandozeile … oder zum Skripten. Es besteht aus einem einzigen Binary und hat keinerlei Abhängigkeiten zu Libs, Paketen oder irgendwas. Es erzeugt dedulizierte Backups: initial wird ein Vollbackup gemacht und dann nie wieder - es braucht dann nur noch inkrementelle Backups. Restic gibt es für Windows/ Mac/ Linux und diverse Plattformen (BSD, Solaris, Mips, … - siehe Releases (dort etwas scrollen :-) [2]).
Das hat was.
Daheim werfe ich gerade einen Http-Server als Backup-Endpoint auf die Synology [3].
Auf Systeme am Institut habe ich grob 150 Linux-Systeme - mit altem und neuen Linux Varianten verschiedener Distributionen. Ich habe ein Bash Skript geschrieben, das mit wget das Binary des Restic Client holt, entpackt und ins /usr/bin legt. Wer es für ein anderes OS oder Architektur braucht, müsste den Suffix “_linux_amd64” ersetzen … oder aber auch dynamisch machen (mit
uname -a
könnte man hinkommen).
#!/usr/bin/env bash
# ------------------------------------------------------
# CONFIG
# ------------------------------------------------------
resticversion=0.12.0
doLink=0
installdir=/usr/bin
resticfile=restic_${resticversion}_linux_amd64
downloadfile=${resticfile}.bz2
downloadurl=https://github.com/restic/restic/releases/download/v${resticversion}/${downloadfile}
# ------------------------------------------------------
# MAIN
# ------------------------------------------------------
echo
echo "##### INSTALL RESTIC CLIENT into $installdir #####"
echo
echo ----- DOWNLOAD
if [ ! -f "${downloadfile}" ]; then
wget -O "${downloadfile}.running" -S "${downloadurl}"
&& mv "${downloadfile}.running" "${downloadfile}"
else
echo SKIP download
fi
echo
echo ----- UNCOMPRESS
bzip2 -d "${downloadfile}"
echo
echo ----- INSTALL
mv "${resticfile}" "${installdir}"
chmod 755 "${installdir}/${resticfile}"
rm -f "${installdir}/restic" 2>/dev/null
test $doLink -eq 0 || ln -s "${installdir}/${resticfile}" "${installdir}/restic"
test $doLink -eq 0 && mv "${installdir}/${resticfile}" "${installdir}/restic"
echo
echo ----- SELF-UPDATE
restic self-update
echo
echo ----- RESULT:
test $doLink -eq 0 || ls -l "${installdir}/${resticfile}"
ls -l "${installdir}/restic"
echo
echo ----- CURRENT VERSION:
restic version
echo
echo ----- DONE
weiterführende Links:
AhCrawler läuft mit PHP8
Der AhCrawler ist ein PHP Open Source Projekt, das für den Einbau einer Suche auf der eigenen Webseite enststand. Im Backend kann man den Suchindex wie auch die von Besuchern eingegebenen Suchbegriffe analysieren. Hinzu kommen Werkzeuge, wie Linkchecker, Http-Header-Analyse, SSL-Check und Annehmlichkeiten, wie der integrierte webbasierte Updater oder die Verwaltungsmöglichkeit mehrerer Webseiten.
Nachdem PHP in Version 8 erschien, kam Anfang Dezember 2020 eine Version heraus, die offensichtliche Fehler in der WebGUI unter PHP8 bereinigte. Der Crawler zeigte hingegen bei Http Head Requests mit Curl “irgendwann” ein komisches Verhalten und brach mit einem “Segmentation Fault” ab.
Mit dem heutigen Release des AhCrawler ist aber auch das Geschichte. Ich bezeichne die Software nunmehr als PHP8 kompatibel! Tusch :-)
weiterführende Links:
- AhCrawler (de)
- DOCs: AhCrawler (en)
Flatpress - sichere Passwortfunktion statt MD5 Hash
Ich hatte es es ja genauso in mein meinen Webtools mit Login gern gemacht: neben dem Admin User wurde das Passwort als MD5 Hash in einer Config-Datei hinterlegt.
Die Hashfunktion MD5 ist nach IT Masstäben nicht mehr wirklich sicher - heisst: man kann mit einem zeitlich vertretbaren Aufwand aus dem Hash das (oder ein) Passwort ermitteln, dass auf den Hash matcht. Verzichtet man gar auf Salts, ist der Angreifer mit Rainbow Tables gar in Sekundenbruchteilen am Ziel. Das ist gar nicht gut. Auf MD5 sollte man heutzutage beim Hashing von Passwörtern - egal ob in einer Konfigurationsdatei oder Datenbank-Feld - komplett verzichten.
Ich will es keineswegs verdammen: als reine Hash Funktion zum Bilden von Prüfsummen von nicht-sensiblen Daten, wie Prüfsummen von Download-Dateien, ist es bedenkenlos einsetzbar.
Aber zurück zum Speichern von Passwörtern. PHP bietet seit einiger Zeit von Haus sichere Funktionen an, sichere Passwort-Hashes zu generieren [2] wie auch eine Check-Funktion [3]. Auf dieses Paar habe ich meine Tools umgestellt und kannte das Prozedere der Umstellung bereits.
Da ich hier als “mein” Blogtool Flatpress seit gefühlten Äonen selbst verwende, hab ich mich gern auch an jenem Tool drangesetzt, und dessen md5 Passwort-Hash durch eine sicherere Variante ersetzt - und eine Lösung für den Issue #59 [4] als Pull Request eingereicht.
Das gilt nicht nur für die neu angelegten Passwörter - auch die Migration ist berücksichtigt: bestehende mit md5 Hash gespeicherte Passwörter werden on the fly beim nächsten Login umgeschrieben.
Arvid, danke und merci für den Merge und Erwähnung auf Twitter [1] für die kommende Version 1.2!
I love OpenSource :-)
weiterführende Links:
Matomo-Javascript Tracking Code auslagern
Matomo empfiehlt zum Tracken einer Webseite den Einbau des Codeschnipsels innerhalb des HTML Dokuments … im Head Bereich. [1]
Aber: das Hineinschreiben von Javascript Code in das HTML Dokument ist nicht so recht günstig, wenn man im CSP Security Header das Attribut script-src sicher und ohne unsafe-inline konfigurieren will. [3]
Die Abhilfe besteht darin, dass man [2]
- das Snippet in eine Javascript Datei auslagert.
- den Aufruf des Trackens im Onload Event einfügt - der ebenfalls in der Javascript-Datei ist und nicht im HTML-Code einer Webseite.
Hier einmal ist die Funktion embedTrackingCode benannt:
function embedTrackingCode() {
var _paq = window._paq = window._paq || [];
_paq.push(["trackPageView"]);
_paq.push(["enableLinkTracking"]);
var u="/matomo/";
_paq.push(['setTrackerUrl', u+'matomo.php']);
_paq.push(['setSiteId', 1]);
var d=document, g=d.createElement("script"), s=d.getElementsByTagName("script")[0]; g.type="text/javascript";
g.defer=true; g.async=true; g.src=u+"matomo.js"; s.parentNode.insertBefore(g,s);
}
… welche bei Abschluss des Ladevorgangs initialisiert wird:
window.onload = (event) => {
embedTrackingCode();
};
Hinweis:
Wenn der Tracking Code in einer Javascript-Datei ist, muss man das Http-Caching der JS Datei bei einem expires= im Http Response Header beachten. Man ist u.U. nicht mehr so flexibel, wenn man den Code anpassen wollte, weil Browser das Javascript aus dem Cache nehmen, statt frisch vom Server die angepasste Version zu holen. Man kann per ETag cachen lassen … oder kann die JS-Datei mit Versionsnummer benennen.
weiterführende Links:
Sourcen für Icinga Checks und Graphen mit Graphite
An “meinem” Institut geht ohne Open Source eigentlich nichts. Damit wir nicht nur nehmen, geben wir an und wann auch etwas als Open Source zurück. Für dieses Thema wird auf unserer Instituts-Webseite kein Platz eingeräumt, daher publiziere ich es hier in meinem privaten Blog.
Ich habe seit Anfang des Jahres eine Icinga Instanz bei uns aufgebaut. Als Icinga-Client auf unseren Servern verwenden wir ein Bash-Skript, das die REST API des Icinga-Servers als auch des Directors anspricht.
Es gibt es diverse mit Bash geschriebene Checks, die die Standard-Nagios Checks ergänzen (und nur teilw. ersetzen). Zur Abstraktion diverser Funktionen, wie z.B.
- Prüfung auf notwendige Binaries im Check
- Schreiben von Performance-Daten
- Handhabe von Exitcodes
… gibt es eine Include Datei, die gemeinsame Funktionen beherbergt. Oder anders: wer einen der Checks verwenden möchte, muss neben dem Check auch einmal die Include-Datei übernehmen.
Die Sourcecodes der Checks sind nun publiziert in [1].
Viele Plugins schreiben Performance-Daten, die wir mit dem Icinga-Graphite-Modul visualisieren. Die unsrigen Ini-Dateien der Graph-Templates liegen in einem separaten Repository [2]. Beim Schreiben der Ini-Dateien der Graph-Templates kam ich immer wieder ans Limit und es gibt (noch?) nicht so wirklich viele dokumentierte Vorlagen. Und so manche in Graphite dokumentierte Funktionen greifen (scheinbar?) nicht in den Inis für Icinga Graphite.
Ich hoffe, dass trotz ausbaufähiger Dokumentation der ein oder andere doch entwas mitnehmen kann.
Ich kann mir gut vorstellen, den ein oder anderen Check noch einmal im Detail hier im Blog vorzustellen.
weiterführende Links: (en)
Bash Rest API Client
Ich bin an unserem Institut am Neuaufbau des Monitorings mit ICINGA dran. Weil es so empfohlen wird, kommt das Director Modul zum Einsatz. Ach so, bereut habe ich dies nicht.
Das Monitoring funktioniert über passive Checks: jeder Server meldet sich selbst an und sendet seine Monitoring Daten zu Icinga ein.
Jeder unserer Server soll ein Host Objekt anlegen, die bemötigten Service-Objekte und und die Services mit dem Host-Objekt verknüpfen. Dazu “spricht” jeder Server per REST API mit dem Director. Der muss die Konfiguration zum Icinga-Server deployen.
Zum Einsenden der Daten braucht es den bereitgestellten Slot für den Host+Service auf dem Icinga-Service. Der Client spricht zum Einliefern der Monitoring-Daten ebenfalls mit einer REST-API - aber dann mit der des Icinga Daemons.
Zum Abstrahieren der REST-API Zugriffe auf verschiedene APIs habe ich alles rund um Http abstrahiert und eine Bash-Komponente geschrieben, die diverse Funktionen für Http-Zugriffe und Abfragen in Skripten einfacher verfügbar macht. Die Verwendbarkeit in Skripten war der Fokus. Die Funktionen ähneln vom Aussehen Methoden einer Klasse: “http.[Funktion]”.
Macht man einen Http-Request, so bleibt dessen Antwort im RAM. Bis man den nächsten Request macht - oder die Shell / das Skript beendet.
Weil es ein Wrapper von Curl ist, kann man alle Http-Methoden, wie GET, HEAD, POST, PUT, DELETE verwenden.
Um einen ersten Eindruck zu vermitteln:
http.makeRequest GET https://www.axel-hahn.de/
Diese Aktion erzeugt keine Ausgabe.
Man kann dann mit Funktionen den Statuscode abfragen, den Http Response Header, den Body oder aber die Curl Daten (darin sind z.B. Upload- und Download-Speed und Verbindungszeiten).
http.getResponseHeader
… gibt alle Http-Response-Headerzeilen aus.
http.getStatuscode
… zeigt den Statuscode
http.isOk
… testet, ob die Anfrage mit einem 2xx Code zurückkam.
Für Icinga wurde der Zugriff mit Basic Authentication umgesetzt.
GET Abfragen lassen sich für N Sekunden cachen. Darüber hinaus kann man den Response exportieren und wieder importieren. Nach dem Import kann man wiederum den Response mit allen Funktionen erfragen - mit http.getRequestAge holt man sich das Alter der Ausführungszeit des Requests. Man kann ein Debugging aktivieren, um die interne Verarbeitung offenzulegen und nachzuvollziehen.
Und Einiges mehr.
Falls das für euch interessant klingt, schaut euch das Bash-Skript doch einmal an.
weiterführende Links:
- Gitlab: iml-open-source/bash-rest-api-client
- Icinga Open Source Monitoring Tool
- Icingaweb - Director REST API
- Icinga: REST API