A single Debian upgrade (
apt-get upgrade) can be rolled back with the following command. The upgrade is identified by its date and time, which has to be looked up from
grep -A 2 'Start-Date: 2016-06-26 17:38:49' /var/log/apt/history.log | tail -1 | sed -r -e "s/Upgrade: //" -e "s/([^:]+):amd64 \(([^,]+), [^,]+\),?/\1=\2/g" | xargs apt-get install
Recently I have been implementing Rspamd for providing some automatic filtering for the emails hosted on my server, which are presently delivered by Exim to the Dovecot LDA.
For integrating Exim with Rspamd, I followed the Rspamd manual, but thing weren’t exactly working as expected.
I was frequently getting error messages such as:
Feb 7 11:10:44 stanke rspamd: (normal) <3a1c27>; task; accept_socket: accepted connection from 127.0.0.1 port 51289
Feb 7 11:10:44 stanke rspamd: (normal) <3a1c27>; task; rspamd_worker_error_handler: abnormally closing connection from: 127.0.0.1, error: IO timeout
with Exim at the same time reporting
2016-02-07 11:10:44 1aSMIm-0005QH-3P spam acl condition: Broken pipe on spamd socket
2016-02-07 11:10:44 1aSMIm-0005QH-3P H=mail1.mcsignup.com [126.96.36.199]:49767 Warning: ACL "warn" statement skipped: condition test deferred
In the majority of cases however the scan succeeded, so that a general misconfiguration could be ruled out. For some reason the socket connection between Exim and Rspamd seemed to break in some cases. I tried playing with the
spamd_address options of exim, in particular with
retry (see the Exim documentation on content scanning at ACL time), but to no avail.
What seems to have fixed the problem however was to define two entries for spam servers that Exim can connect to, despite the fact that they both refer to the same Rspamd instance. Exim seems to simply switch to the next (in fact same) server when seeing a „broken pipe“ and the reconnect seems to suffice to iron things out. Here is the relevant snippet to be inserted in
spamd_address = 127.0.0.1 11333 tmo=1m retry=10s variant=rspamd : \
127.0.0.1 11333 tmo=1m retry=10s variant=rspamd
rrsync (i.e. restricted
rsync) to work, the remote user must have a proper login shell specified (i.e. not
„rsync problem & solution“ weiterlesen
Endlich ein vernünftiges Backup für meinen Server: mit rsync auf den lokalen NAS.
Only recently I found out about the embedded Lua interpreter in Nginx and an immediate use came to my mind: why not use Lua to check validity of the Cachify harddisk (HDD) cache? Here is what I came up with. „Cachify HDD expiry“ weiterlesen
Jetzt fehlt nur noch eine Lösung, wie ich die externe IP Adresse ohne eine 3rd Party Service bekomme.
Lesson learned: to run Radicale behind Cherokee via uWSGI, one needs to add
--plugin python to the interpreter command line on the uWSGI source page of the Cherokee admin interface.
After my spam filter has been inactive for more than two weeks, I finally had the pleasure to investigate what went wrong during the upgrade of my system to Debian Wheezy. Back then I took the conservative approach and kept my old configs when in doubt, especially when they were personalized to my tastes. Unfortunately DSPAM wasn’t so nice as to pass Exim any meaningful error message.
Long story short, the DSPAM package changed the location of its storage drivers. Inserting „x86_64-linux-gnu“ in the StorageDriver entry in dspam.conf solved the problem. Wouldn’t this be the first thing to look for when reading „transport returned 1 from command: /usr/bin/dspam“ in the mainlog?!
For weeks I had the intention to use my Android phone with Zarafa and Z-Push. However, my phone always reported that protocol version provided by the server would not be supported. I had a day off today and dug into the code (first Z-Push, then CyanogenMod 10) to track down the problem. It seemed like there would be a problem with the OPTIONS request in ActiveSync and the headers sent by Z-Push. I ended up using Fiddler to inspect the HTTPS traffic, in particular the headers and it turned out that Z-Push did not send the headers to identify the ActiveSync protocol. But the PHP-code (already messed with debugging output of my own) did send the headers.
Surprisingly, a minimal PHP script that did nothing by sending headers also worked. After a while it seems like the PHP output buffering (ob_start) dropped the headers, but then ob_clean or _flush at before and/or after the header call didn’t change anything.
Staring at the Fiddler traffic of the working testing code brought the saving idea: I had mod_pagespeed enabled (which I noticed, because it also added a header of its own). Turning it off made everything work!
Conclusion: Z-Push is incompatible with mod_pagespeed!
If EGroupware is run via FastCGI under Apache, the authentication only works if the configuration file
/etc/apache2/mods-enabled/fcgid.conf contains the line