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.

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.

Rewrites unter Nginx loggen

In der Konfiguration für den Webserver Nginx bzw. dessen Seiten, ist es möglich Rewrite-Direktiven zu nutzen. Damit können URLs umgeschrieben werden. Ein Beispiel für eine solche Direktive wäre z.B.

try_files $uri $uri/ @rewrite;

location @rewrite {
  rewrite ^/(.*)$ /index.php?_url=/$1;
}

Wenn dieser Rewrite zur Anwendung kommt, erscheint leider keine Meldung in den Nginx-Logs access.log und error.log. Um das Logging für Rewrites zu aktivieren, muss die Option:

rewrite_log on;

im server-Block der Konfiguration, welche unter /etc/nginx/sites-available/ zu finden ist, aktiviert werden. Daneben muss die Logging-Severity, also die Schwere der Events die geloggt werden sollen, angepasst werden. Dazu wird folgende Option dem server-Block hinzugefügt:

error_log /var/log/nginx/error.log notice;

Wenn die Log-Datei nun angeschaut wird, so finden sich dort für jeden Rewrite entsprechende Meldungen:

2019/05/29 08:35:30 [notice] 16054#16054: *127817 “^/(.*)$” matches “/name/german”, client: 82.193.248.37, server: api.example.com, request: “GET /name/german HTTP/1.1”, host: “api.example.com”
2019/05/29 08:35:30 [notice] 16054#16054: *127817 rewritten data: “/index.php”, args: “_url=/name/german”, client: 82.193.248.37, server: api.example.com, request: “GET /name/german HTTP/1.1”, host: “api.example.com”

REST-APIs unter Apache und Nginx betreiben

Eine der wesentlichen Eigenschaften von REST-APIs bzw. RESTful-Webservices ist ihre Adressierbarkeit von Ressourcen. Wenn ich z.B. über eine API verfüge, welche mir Namen generiert, so kann es in dieser API unterschiedliche Ressourcen geben:

GET https://api.example.com/name/german/
GET https://api.example.com/name/polish/

Rufe ich nun eine der beiden Ressourcen mit dem HTTP-Verb GET auf so erhalte ich entweder einen deutschen oder einen polnischen Namen von dieser Beispiel-API. Für den Webserver ergibt sich allerdings das Problem, das der Ordner name und die entsprechenden Unterordner nicht existieren. Das einzige was in diesem Beispiel existiert ist eine index.php-Datei, welche unter der URL:

https://api.example.com/index.php

zu finden ist. Damit die REST-API ordnungsgemäß funktioniert, müssen die entsprechenden Aufrufe zur index.php-Datei umgebogen werden. Bei dem Webserver Apache kann dies über eine .htaccess-Datei mit folgendem Inhalt erledigt werden:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ index.php?_url=/$1 [QSA,L]
</IfModule>

Diese Datei sollte dabei im gleichen Verzeichnis wie die Datei index.php liegen. Bei Nginx muss stattdessen die Konfiguration der Domain bzw. der Seite angepasst werden. Diese Konfigurationen sind unter /etc/nginx/sites-available/ zu finden. Dort muss folgende Konfiguration hinzugefügt werden:

try_files $uri $uri/ @rewrite;

location @rewrite {
	   rewrite ^/(.*)$ /index.php?_url=/$1;
}

Hinterlegt werden muss die Konfiguration in einem server-Block derselben. In diesem Fall würde die URL bzw. der Aufruf:

GET https://api.example.com/name/german/

intern in die URL:

https://api.example.com/index.php?_url=name/german/

umgeschrieben und vom Webserver geladen. Dadurch landen die Aufrufe wieder bei der Datei index.php und können verarbeitet werden.

LanguageTool-Server unter Ubuntu aufsetzen

Für die freie Grammatik- und Rechtschreibprüfung LanguageTool existieren eine Reihe von Add-ons, unter anderem für den Browser Firefox.

Standardmäßig nutzen diese Add-ons den vom Projekt bereitgestellten Server unter languagetool.org. Nicht jeder möchte seine Daten zur Korrektur an Dritte schicken und so besteht die Möglichkeit einen eigenen Server aufzusetzen. Dieser kann lokal betrieben oder auf einem eigenen Server installiert werden. In diesem Artikel soll die Installation unter Ubuntu beschrieben werden. Im ersten Schritt muss sich auf dem Server eingeloggt und dort ein neuer Nutzer angelegt werden:

adduser languagetool
su languagetool
cd

Nachdem der Nutzer angelegt wurde und in das entsprechende Home-Verzeichnis des Nutzers gewechselt wurde, kann das LanguageTool heruntergeladen und entpackt werden:

wget https://languagetool.org/download/LanguageTool-4.5.zip
unzip LanguageTool-4.5.zip
mv LanguageTool-4.5 server
rm LanguageTool-4.5.zip

Neben dem LanguageTool, werden noch sogenannte N-Gramme heruntergeladen. Diese dienen der Verbesserung der Erkennungsleistung des LanguageTool. Sie belegen knapp 27 GiB auf der Festplatte, müssen aber nicht zwingend installiert werden:

mkdir ngrams

wget https://languagetool.org/download/ngram-data/ngrams-de-20150819.zip
wget https://languagetool.org/download/ngram-data/ngrams-en-20150817.zip
wget https://languagetool.org/download/ngram-data/ngrams-es-20150915.zip
wget https://languagetool.org/download/ngram-data/ngrams-fr-20150913.zip
wget https://languagetool.org/download/ngram-data/ngrams-nl-20181229.zip

unzip ngrams-de-20150819.zip
unzip ngrams-en-20150817.zip
unzip ngrams-es-20150915.zip
unzip ngrams-fr-20150913.zip
unzip ngrams-nl-20181229.zip

rm ngrams-de-20150819.zip
rm ngrams-en-20150817.zip
rm ngrams-es-20150915.zip
rm ngrams-fr-20150913.zip
rm ngrams-nl-20181229.zip

Damit ist das LanguageTool installiert. Ein erster Test kann erfolgen, indem der Server mittels:

java -cp languagetool-server.jar org.languagetool.server.HTTPServer --port 8081

gestartet wird. Über Curl können erste Testdaten an den Server gesendet werden:

curl --data "language=en-US&text=a first test" http://localhost:8081/v2/check

In meinem Setup wird der Server auf dem Port 8081 (oder einem beliebigen anderen Port betrieben) und ist über einen Reverse Proxy, in diesem Fall Nginx, erreichbar. Dazu muss die Konfiguration angepasst werden:

nano /etc/nginx/sites-available/example

In der Nginx-Konfigurationsdatei wird nun folgende Konfiguration hinterlegt:

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

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

        root /var/www/example/api;
        index index.php index.html index.htm;

        server_name api.example.org;

        # proxy for languagetool
        location /languagetool/ {
                proxy_pass http://localhost:8081/v2/;
        }
}

Nachdem die Konfiguration für Nginx hinterlegt wurde, wird Nginx neugestartet:

nginx restart

Über den Browser kann die API nun getestet werden:

https://api.example.org/languagetool/check?language=en-US&text=Wong wong wong

Damit ist die Konfiguration des LanguageTool allerdings noch nicht abgeschlossen. Für den produktiven Betrieb wird eine Konfigurationsdatei unter /home/languagetool/server/ erstellt:

nano languagetool.cfg

Diese Datei wird mit folgendem Inhalt befüllt:

languageModel=/home/languagetool/ngrams

Damit der Service automatisch startet, wird eine systemd-Unit angelegt:

nano /etc/systemd/system/languagetool.service

Diese Datei wird mit folgendem Inhalt befüllt:

[Unit]
Description=LanguageTool
After=syslog.target
After=network.target

[Service]
Type=simple
User=languagetool
Group=languagetool
WorkingDirectory=/home/languagetool/server
ExecStart=/usr/bin/java -cp /home/languagetool/server/languagetool-server.jar org.languagetool.server.HTTPServer --config languagetool.cfg --port 3001 --allow-origin "*"
Restart=always
Environment=USER=git HOME=/home/languagetool

[Install]
WantedBy=multi-user.target

Nachdem die Datei angelegt wurde, wird sie aktiviert und anschließend der Service gestartet:

systemctl enable languagetool
service languagetool start

Zum Test der N-Gramme kann folgende URL aufgerufen:

https://api.example.org/languagetool/check?language=en-US&text=I%20want%20to%20go%20their.

werden. Wenn keine N-Gramme installiert oder konfiguriert sind, kommt ein relativ kurzes JSON als Antwort zurück:

{“software”:{“name”:”LanguageTool”,”version”:”4.5″,”buildDate”:”2019-03-26 11:37″,”apiVersion”:1,”premium”:false,”premiumHint”:”You might be missing errors only the Premium version can find. Contact us at supportlanguagetoolplus.com.”,”status”:””},”warnings”:{“incompleteResults”:false},”language”:{“name”:”English (US)”,”code”:”en-US”,”detectedLanguage”:{“name”:”English (US)”,”code”:”en-US”,”confidence”:0.9999997}},”matches”:[]}

Sind die N-Gramme erfolgreich installiert und konfiguriert, wird das LanguageTool mit einem längeren Response antworten:

{“software”:{“name”:”LanguageTool”,”version”:”4.5″,”buildDate”:”2019-03-26 11:37″,”apiVersion”:1,”premium”:false,”premiumHint”:”You might be missing errors only the Premium version can find. Contact us at supportlanguagetoolplus.com.”,”status”:””},”warnings”:{“incompleteResults”:false},”language”:{“name”:”English (US)”,”code”:”en-US”,”detectedLanguage”:{“name”:”English (US)”,”code”:”en-US”,”confidence”:0.9999997}},”matches”:[{“message”:”Statistics suggests that ‘there’ (as in ‘Is there an answer?’) might be the correct word here, not ‘their’ (as in ‘It’s not their fault.’). Please check.”,”shortMessage”:””,”replacements”:[{“value”:”there”,”shortDescription”:”as in ‘Is there an answer?'”}],”offset”:13,”length”:5,”context”:{“text”:”I want to go their.”,”offset”:13,”length”:5},”sentence”:”I want to go their.”,”type”:{“typeName”:”Other”},”rule”:{“id”:”CONFUSION_RULE”,”description”:”Statistically detect wrong use of words that are easily confused”,”issueType”:”non-conformance”,”category”:{“id”:”TYPOS”,”name”:”Possible Typo”}},”ignoreForIncompleteSentence”:false,”contextForSureMatch”:3}]}

Damit ist der Server komplett eingerichtet. Nun kann der eigene Server bei entsprechenden Add-ons eingerichtet und genutzt werden.

Nachdem der Server aufgesetzt wurde, können entsprechende Add-ons umgestellt werden

Das gleiche Setup kann natürlich genutzt werden, einen solchen Server lokal auf dem eigenen Ubuntu-Rechner zu installieren.