apt vs. apt-get

Wurde früher unter Debian oder Ubuntu ein Paket installiert, so wurde das Kommando apt-get dazu genutzt:

apt-get install mc

Seit Ubuntu 14.04 gibt es neben den Kommandos rund um apt-get, das Kommando apt. Ab Ubuntu 16.04 wurde offiziell empfohlen apt anstatt von apt-get und apt-cache zu nutzen. Da stellt sich natürlich die Frage wie sich die Kommandos voneinander unterscheiden? Bei den alten Kommandos musste für die Paketverwaltung mit apt-get und apt-cache gearbeitet werden, je nachdem welche Operation benötigt wurde. Die Installation wurde mit apt-get install vorgenommen. Für eine Suche über die Pakete wurde stattdessen apt-cache benötigt:

apt-cache search mc

Mit dem damals neu eingeführten Kommando apt gibt es nun ein einheitliches Interface für die Paketverwaltung:

apt install mc
apt search mc

Neben der Vereinheitlichung, bietet apt einige weitere Vorteile, so kann unter anderem der Fortschritt einer Operation angezeigt werden.

apt zeigt unter anderem den Fortschritt der Operation an

Im Grunde ist apt eine Zusammenführung der am häufigsten genutzten Kommandos zur Paketverwaltung unter einem Kommando. Bestimmte obskure Low-Level-Operationen, welche bei apt-get und apt-cache noch zu finden waren, wurden bei apt zugunsten der Benutzbarkeit weggelassen. Zusätzlich dazu sind die Standardeinstellungen von apt sinnvoller gesetzt.

Laufenden Prozess zu screen überführen

Das Kommandzeilentool screen ist praktisch, da Prozesse, welche mittels screen gestartet wurden, auch nach dem Logout weiter laufen. Problematisch ist es, wenn ein Prozess ohne screen gestartet wurde und er nachträglich in screen überführt werden soll. Hierfür wird das Tool reptyr benötigt:

apt install reptyr

Mithilfe von reptyr ist es möglich eine Anwendung an ein neues Terminal zu binden. Um nun einen Prozess zu screen zu überführen, muss erst einmal eine neue screen-Instanz gestartet werden:

screen bash

Sobald die Instanz geöffnet wurde, kann der eigentliche Prozess neu zugewiesen werden:

reptyr PID

PID ist hierbei die Prozess-ID, welche sich mittels des ps-Kommandos ermitteln lässt. Alternativ kann dafür auch top oder htop genutzt werden. Damit wurde die Terminalsitzung und mit ihr der laufende Prozess in die screen-Sitzung überführt.

Archivierung im Thunderbird funktioniert nicht

In der freien Mailsoftware Thunderbird können Mails archiviert werden. Damit landen diese Mails in einem Archivordner. Innerhalb dieses Ordners sind die Mails in einer Struktur hinterlegt, welche über die Einstellungen des Kontos, unter Kopien & Ordner, konfigurierbar sind. So können alle Mails im Archivordner hinterlegt werden oder in einer Jahres- und oder Monatsstruktur hinterlegt werden.

Die Optionen für die Archivierung

Ich habe diese Struktur vor ein paar Tagen umgestellt. Allerdings nutzte Thunderbird weiterhin die alte Struktur und archivierte die Mails in die falschen Ordner. Die Änderung wurde zwar gespeichert und auch in den Einstellungen angezeigt, allerdings wurden immer noch die alten Einstellungen angewendet. Nach einigem hin und her habe ich das Problem durch das komplette neu aufsetzen des Profils gelöst.

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
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.