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.

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.

Maximale Größe von Mails unter Postfix konfigurieren

Standardmäßig ist die maximale Größe von Mails beim MTA Postfix auf 10240000 Byte, knapp 10 MiB, beschränkt. Soll diese Einstellung bearbeitet werden, so muss die entsprechende Konfigurationsdatei von Postfix bearbeitet werden:

nano /etc/postfix/main.cf

In der Datei muss die Option message_size_limit hinzugefügt werden:

message_size_limit = 40960000

In diesem Fall wurde die maximale Größe von Mails auf knapp 40 MiB gesetzt. Nach einem Neustart von Postfix:

service postfix restart

ist die neue Obergrenze gesetzt und Mails können bis zur entsprechenden Größe versendet werden.

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.