Zugriff auf MAMP-Logs

MAMP (Mac, Apache, MySQL und PHP) ist ein Paket zum lokalen Betrieb eines Webservers für Test- und Entwicklungszwecke. Neben der ursprünglichen Version für macOS, existiert mittlerweile auch eine Version für Windows. Bei der Entwicklung von Software z.B. einer PHP-Anwendung ist es hilfreich die Logs der einzelnen Bestandteile von MAMP nutzen zu können. Unter macOS befinden sich die Logs in dem Ordner:

/Applications/MAMP/logs/

In diesem Ordner sind eine Reihe von Dateien zu finden. Die einzelnen Logdateien tragen folgende Dateinamen:

/Applications/MAMP/logs/apache_error.log 
/Applications/MAMP/logs/mysql_error_log.err
/Applications/MAMP/logs/nginx_access.log 
/Applications/MAMP/logs/nginx_error.log 
/Applications/MAMP/logs/php_error.log

Die Nginx-Log-Dateien tauchen nur auf, wenn Nginx als Webserver in den Einstellungen von MAMP verwendet wurde. In der Windows-Version befinden sich die Log-Dateien ebenfalls im log-Ordner, welcher sich wiederum im MAMP-Installationsordner befindet.

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“

Garbage Collection Log erstellen und auswerten

In regelmäßigen Abstand führen Java-Applikationen eine sogenannte Garbage Collection durch. Dabei werden Objekte welche nicht mehr benötigt werden entfernt und somit der Speicher der Anwendung bereinigt. Die Ausführung der Garbage Collection kann während der Ausführung der Applikation mitgeloggt werden:

java -Xloggc:garbage.log -jar application.jar

Der Parameter -Xloggc spezifiziert die Datei in welche das Log geschrieben wird. Mit Hilfe dieses Logs können Probleme der Applikationen analysiert werden. Ein Beispiel für ein solches Log könnte z.B. so aussehen:

Java HotSpot(TM) 64-Bit Server VM (25.144-b01) for bsd-amd64 JRE (1.8.0_144-b01), built on Jul 21 2017 22:07:42 by "java_re" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Memory: 4k page, physical 8388608k(122952k free)

/proc/meminfo:

CommandLine flags: -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=2147483648 -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC 
4,347: [GC (Allocation Failure)  33280K->8385K(125952K), 0,0125825 secs]
4,475: [GC (Metadata GC Threshold)  12196K->8961K(125952K), 0,0061766 secs]
4,481: [Full GC (Metadata GC Threshold)  8961K->6026K(87552K), 0,0206784 secs]
16,232: [GC (Allocation Failure)  39306K->15981K(87552K), 0,0095999 secs]

Zur Auswertung kann, neben vielen anderen Tools, der Webdienst GCeasy, welcher sich selbst als Universal GC Log Analyzer bezeichnet, genutzt werden.

Die Analyse des Garbage Collection Logs

Mit Hilfe der Auswertung können eventuelle Probleme im Zusammenhang mit der Garbage Collection besser eingegrenzt und analysiert werden. Zu finden ist der Dienst unter gceasy.io.

Invalid user settings unter Dovecot

Vor einigen Tagen ist mir ein Mailserver (bestehend aus Postfix und Dovecot) begegnet, welcher in der mail.err regelmäßig folgende Ausgabe wiederholte:

Apr 2 13:16:35 service dovecot: lda(root): Error: chdir(/root/) failed: Permission denied (euid=65534(nobody) egid=65534(nogroup) missing +x perm: /root, dir owned by 0:0 mode=0700)
Apr 2 13:16:35 service dovecot: lda(root): Error: chdir(/root) failed: Permission denied
Apr 2 13:16:35 service dovecot: lda(root): Error: user root: Initialization failed: Namespace '': stat(/root/Maildir) failed: Permission denied (euid=65534(nobody) egid=65534(nogroup) missing +x perm: /root, dir owned by 0:0 mode=0700)
Apr 2 13:16:35 service dovecot: lda(root): Fatal: Invalid user settings. Refer to server log for more information.

Der Dovecot-Service versucht auf einen Maildir-Ordner im Nutzerverzeichnis des Nutzers root zuzugreifen, was allerdings nicht gelingt. Einfach lösen lässt sich dieses Problem in dem man einen Alias für die Mailzustellung zum Nutzer root anlegt. Dazu wird im ersten Schritt die Datei /etc/aliases bearbeitet. In dieser Datei kann der entsprechende Alias eingetragen werden:

root:

Nachdem die Datei gespeichert wurde, muss die Datei in ihre binäre Form überführt werden und die entsprechenden Services neugestartet werden:

newaliases
service dovecot restart
service postfix restart

Damit werden die Mails von root im entsprechenden Postfach hinterlegt und die Fehlermeldung gehört der Vergangenheit an.

Wo sind die OpenVPN Logs zu finden?

Wenn man einen OpenVPN-Server in der Standardkonfiguration betreibt, wird man sich unter Umständen wundern, an welcher Stelle ist das OpenVPN Log zu finden ist. Das liegt daran das der OpenVPN-Server das ganze in /var/log/syslog speichert. Möchte man nun die OpenVPN betreffenden Punkte filtern so sollte man auf der Konsole folgendes eingeben:

grep VPN /var/log/syslog

Alternativ kann man auch die OpenVPN-Konfiguration anpassen. Dazu muss die Datei /etc/openvpn/server.conf bearbeitet werden. Dort gibt es eine Option log-append, welche wie folgt angepasst wird:

log-append /var/log/openvpn.log

Nach einem Neustart des Service mittels:

service openvpn restart

wird die neu eingestellte Logdatei genutzt.