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.

Ausnahmen in der MediaWiki mit Details anzeigen

Unter Umständen kann es vorkommen, das die MediaWiki Software im Betrieb eine Ausnahme (Exception) wirft. Dann bekommt man eine Meldung nach dem Schema:

[6030c238] 2015-02-16 8:48:30: Fatal exception of type MWException

Diese Aussage ist natürlich zur Fehlerfindung nicht sehr aussagekräftig. Damit man eine ausführliche Ausgabe zur Exception bekommt, muss in der LocalSettings.php Datei folgende Option hinzugefügt werden:

$wgShowExceptionDetails=true;

Anschließend erhält man im Falle eine Exception einen sauberen Callstack, mit welchen man sich auf Fehlersuche begeben kann.

Probleme mit schwarzem Hintergrund im Watch-Fenster des Visual Studios

Beim Debuggen mit dem Visual Studio 2013 fiel mir ein Problem mit dem Watch-Fenster auf. Die Anzeige des Watch-Fensters bestand nur noch aus schwarzen Balken. Damit lässt sich natürlich schlecht debuggen, so das Abhilfe geschaffen werden musste.

Das Watch-Fenster zeigt nur noch schwarze Balken

Das Watch-Fenster zeigt nur noch schwarze Balken

Eine Umstellung der Farbschemas von Blue auf Dark oder Light brachte Besserung, allerdings betreibe ich mein Visual Studio lieber im Farbschema Blue. Doch nach dem Zurückschalten sind die schwarzen Balken im Watch-Fenster wieder da.

Nach der Umstellung funktioniert das Watch-Fenster wieder

Nach der Umstellung funktioniert das Watch-Fenster wieder

Bei diesem Problem scheint es sich um einen Fehler im Visual Studio zu handeln, welcher mit einem etwas kruden Workarround behoben werden kann. Dazu sucht man in den Optionen den Punkt Fonts and Colors und ändert dort die Farbe für den Punkt Merge – Block selection box auf White. Anschließend ist das Watch-Fenster wieder nutzbar.

IP-Adresse im Firefox und Chrome trotz WebRTC verstecken

Mittels WebRTC ist es mögliche Dinge wie Videokonferenzen mit einem Browsers durchzuführen. Allerdings gibt es dabei auch ein Problem – damit Rechner hinter einem NAT diese Funktionalität nutzen können, kann ein STUN-Server, nach der öffentlichen IP-Adresse befragt werden.

Die entsprechende Konfiguration

Die entsprechende Konfiguration

Nutzt man nun eine VPN-Verbindung, kann man mit Hilfe dieser STUN-Server, nach der Adresse fragen, welche das VPN aufgebaut hat. Das entsprechende Demo kann man sich auf GitHub ansehen. Um diese Verhalten zu deaktivieren, muss in der Adresszeile des Firefox about:config eingegeben werden und der Wert media.peerconnection.enabled auf false gesetzt werden.

Chrome Web Store
Preis: Kostenlos

Anschließend ist man gegen derartige Angriffe gewappnet. Für Chrome gibt es eine entsprechende Erweiterung, welche das gleiche bewirkt.

Probleme bei der Aktualisierung des Netzwerkes einer WordPress-Multisite-Installation

Bei einer WordPress Multisite-Installation gibt es unter Updates den Punkt Netzwerk aktualisieren. Wenn man seine Multisite-Installation mit selbstsignierten Zertifikaten betreibt, kann es dabei zu folgender Fehlermeldung kommen:

https://wordpress.example.com/mysite1

Warnung! Problem beim aktualisieren von https://wordpress.example.com/mysite1. Vermutlich gab es einen Zeitablauf. Die Fehlermeldung lautet: SSL certificate problem: self signed certificate

Um das Problem zu lösen packt man folgendes Plugin, in den WordPress-Plugin-Ordner:

<?php
/*
* Plugin Name: Deactivate SSL Verify
* Description: Deactivate SSL verification
* Author: seeseekey
* Author URI: https://seeseekey.net
* Plugin URI: https://seeseekey.net
*/
add_filter('https_ssl_verify', '__return_false');
add_filter('https_local_ssl_verify', '__return_false');

Nachdem das Plugin aktiviert wurde, kann die Aktualisierung des Netzwerkes durchgeführt werden. Anschließend kann das Plugin wieder deaktiviert werden.