Matomo-Berichte per Cronjob generieren

Matomo ist eine freie Software zur Webanalytik. Früher war Matomo unter dem Namen Piwik bekannt. Wenn Matomo Berichte auf der Weboberfläche anzeigt, so werden diese vorher generiert. Geschieht dies beim Aufruf der Berichte, kann dies, vor allem bei größeren Berichten, zu Problemen führen, da der Server entsprechend viel Zeit für die Erstellung benötigt und dies sich auf die Ladezeit der Weboberfläche auswirkt.

Die Archivierung bei der Anzeige im Browser sollte deaktiviert werden

Als Lösung bietet es sich an die Aufgabe, der Berichterzeugung und Datenaggregierung, an einen Cronjob auszulagern. Dazu muss im ersten Schritt die Crontab-Datei geöffnet werden:

sudo -u www-data crontab -e

Ich die sich öffnende Crontab-Datei wird nun folgende Zeile eingetragen:

*/15 *    * * *   php /var/www/example/matomo/console core:archive > /dev/null

Nachdem die Crontab-Datei gespeichert wurde, wird der Task zur Archivierung und Erstellung der Berichte alle 15 Minuten automatisch gestartet. In den Matomo-Einstellungen unter System -> Allgemeine Einstellungen findet sich der Punkt Archivierungseinstellungen. Hier muss die Archivierung im Browser deaktiviert werden. Damit werden Berichte in Matomo nun per Cronjob erzeugt und beeinflussen die Ladezeiten der Weboberfläche nicht mehr.

Cachify-Cache per Cronjob bereinigen

Cachify ist ein WordPress-Plugin zum einfachen und effektiven Cachen der eigenen WordPress-Instanz. Das Plugin bietet unterschiedliche Methoden für das Caching an. So kann der Cache z.B. in der Datenbank oder auf der Festplatte angelegt werden. Meine bevorzugte Methode ist die Ablage des Caches auf der Festplatte.

Cachify
Preis: Kostenlos

Dies hat einige Vorteile. So kann der Cache, wenn vorhanden, direkt über den Webserver ausgeliefert werden. Die Ausführung von PHP oder die Anfrage auf der Datenbank entfällt. Dies wirkt sich extrem positiv auf die Geschwindigkeit aus. Allerdings funktioniert der automatische Ablauf des Caches bei der Festplatten-Methode leider nicht. Hier muss stattdessen ein Cronjob eingerichtet werden:

sudo -u www-data crontab -e

Im Cronjob soll einmal der Cache bereinigt werden und anschließend die Hauptseite geöffnet werden, damit für diese wieder ein Objekt im Cache angelegt wird:

rm -rf /var/www/example/main/wp-content/cache/cachify/*
curl --silent https://example.net > /dev/null

Beim ersten Befehl wird der Ordner, in welchem der Cache liegt, gelöscht. Anschließend wird mit cURL die Hauptseite aufgerufen, um den Cache wieder aufzufüllen. In der Crontab-Datei sieht dies wie folgt aus:

0    *    * * *   rm -rf /var/www/blankensee/main/wp-content/cache/cachify/* & curl --silent https://blankensee.net > /dev/null

Damit wird der Cache einmal in der Stunde gelöscht und der Cache der Hauptseite wieder neu aufgebaut.

MQTT Explorer

Für die unterschiedlichsten Betriebssysteme existieren eine Reihe von Clients für MQTT. MQTT Explorer ist einer dieser Clients, welcher plattformübergreifend (Linux, macOS, Windows) verfügbar ist. Der MQTT Exporer ist auf Performanz optimiert und kommt mühelos mit mehreren tausend Nachrichten pro Minute zurecht. Damit eignet er sich unter anderem für das Debugging größerer Installationen, in welchen unterschiedlichste Topics definiert sind.

Der MQTT Explorer unter macOS

Bezogen werden kann der Client über die Projektseite unter mqtt-explorer.com. Der Quellcode dies Clients kann über GitHub bezogen werden. Lizenziert ist der Quellcode unter der Creative Commons-Lizenz CC-BY-ND und damit keine freie Software.

Zeit unter Linux manuell synchronisieren

Unter Umständen kann es passieren, dass ein Linux-System mit der falschen Uhrzeit läuft. Soll ein solches System manuell die aktuelle Uhrzeit gebracht werden, so kann hierfür der Befehl ntpdate genutzt werden. Dazu muss im ersten Schritt das passende Paket installiert werden:

apt install ntpdate

Anschließend kann der Befehl genutzt werden. Er muss hierbei mit einem NTP-Server aufgerufen werden:

ntpdate pool.ntp.org

Damit wurde die Zeit anhand des NTP-Servers neu gesetzt. Wichtig ist es das der Befehl mit administrativen Rechten ausgeführt wird.

Reverse Proxy für Gitea konfigurieren

Ein Reverse Proxy liefert eine Ressource, welche er von einem oder mehreren Servern holt, an einen Client aus. Bei Gitea kann es durchaus sinnvoll sein, dieses hinter einem Reverse Proxy zu betreiben. Standardmäßig läuft der Dienst auf dem Port 3000. Möchte der Nutzer ihn über die normalen Ports für HTTP (80) bzw. HTTPS (443) erreichbar machen, könnte das Ganze durchaus über die Konfiguration von Gitea in Verbindung mit der systemd-Unit geschehen.

Allerdings ist ein weiterer Vorteil bei einem Reverse Proxy, das die angefragte Infrastruktur aus der Sicht der Clients versteckt wird. Mittels Nginx kann es solcher Reverse Proxy realisiert werden. Dazu muss die Nginx-Konfiguration für die Domain angepasst werden:

nano /etc/nginx/sites-available/example

In diesem Fall befasst sich die Konfiguration mit der verschlüsselten Kommunikation per HTTPS und der Weiterleitung von unverschlüsselten Verbindung in Richtung der verschlüsselten Verbindung.

server {
  listen 80;
  listen [::]:80;

  server_name example.org;

  return 301 https://$host$request_uri$is_args$args;
}

server {
  listen 443;
  listen [::]:443 default_server;

  ssl on;
  ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
  ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

    server_name org;

    location / {
        proxy_pass http://localhost:3000;
    }
}

Anhand der Konfiguration wird ersichtlich das Gitea auf dem Server unverschlüsselt betrieben werden kann, da die eigentliche Verschlüsselung über HTTPS vom Reverse Proxy, in diesem Fall Nginx, übernommen wird. Nachdem die Konfiguration gespeichert wurde, muss Nginx neugestartet werden:

service nginx restart

Anschließend muss die Gitea-Konfiguration nochmals angepasst werden:

nano /home/git/gitea/custom/conf/app.ini

Dort muss die ROOT_URL nun so definiert werden, wie der Client sie nun sieht. Die ROOT_URL kann von:

ROOT_URL         = https://example.org:3000/

zu:

ROOT_URL         = http://example.org/

geändert werden. Die Werte PROTOCOL, CERT_FILE und KEY_FILE können entfernt werden, da die Verschlüsslung nun von Nginx übernommen wird. Nach der Änderung der Konfiguration muss Gitea ebenfalls neugestartet werden:

service gitea restart

Nachdem die Konfiguration durch geführt wurde, ist Gitea unter zwei URLs erreichbar:

http://example.org:3000/
https://example.org/

Intern läuft Gitea auf dem Port 3000. Damit dieser nicht von außen erreichbar ist, sollte eine entsprechende Firewall-Regel konfiguriert werden.