Fabian Stanke

Improved logwatch html output

The tables, colors and fonts of the default logwatch html mails looks terrible in Mail.app. Here’s how to patch your `/usr/share/logwatch/default.conf/html/header.html`:

--- header.html    2013-06-30 14:45:00.000000000 +0200
+++ header.html 2013-06-30 15:00:00.000000000 +0200
@@ -5,10 +5,12 @@
 <meta name="generator" content="Logwatch  $Version ( $VDate )">
 <style type="text/css">
   h1 {color: gray; border-bottom: 3px double silver; font-family: sans-serif; }
-  h2 {color: white; border-bottom: 1px solid silver; font-family: sans-serif; }
-  h3 {color: white; border-bottom: 1px solid silver; font-family: sans-serif; }
-  th {background: #6D88AD; text-align: left; font-family: sans-serif; }
-  td {background: #EFEFEF; text-align: left; font-family: courier,serif; font-size: 10px; }
+  h2 {border-bottom: 1px solid silver; font-family: sans-serif; }
+  h3 {border-bottom: 1px solid silver; font-family: sans-serif; }
+  table {border-collapse: collapse; }
+  table,th, td {border: 1px solid white; }
+  th {background: #F8F8F8; text-align: left; font-family: sans-serif; }
+  td {background: #F8F8F8; text-align: left; font-family: courier,serif; }
   li { font-family: sans-serif; }
   .ref {padding-left: 1%; }
   .service {padding-left: 1%; }

Much better!

Contrary to what I noted earlier http fmos…

Contrary to what I noted earlier, `mod_pagespeed` may be used together with Z-Push (thanks to Grayson Peddie for the hint). Any interference with the relevant parts can be prevented by the following lines in the module configuration: 

    ModPagespeedDisallow */z-push*
    ModPagespeedDisallow */Microsoft-Server-ActiveSync*

source: Z-Push forum thread

After my spam filter has been inactive for…

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?!