Resolved: warning: request to update table btree:/var/run/smtp_tls_session_cache in non-postfix directory /var/run

There were a few warning popping up in my /var/log/mail.warn log for Postfix, like this:

Feb  4 09:16:15 sixsigma postfix/tlsmgr[3394]: warning: request to update table
btree:/var/run/smtpd_tls_session_cache in non-postfix directory /var/run
Feb  4 09:16:15 sixsigma postfix/tlsmgr[3394]: warning: redirecting the request
to postfix-owned data_directory /var/lib/postfix
Feb  4 09:16:15 sixsigma postfix/tlsmgr[3394]: warning: request to update table
btree:/var/run/smtp_tls_session_cache in non-postfix directory /var/run
Feb  4 09:16:15 sixsigma postfix/tlsmgr[3394]: warning: redirecting the request
to postfix-owned data_directory /var/lib/postfix

I fixed the problem by reconfiguring /etc/postfix/main.cf and changing this:

smtpd_tls_session_cache_database = btree:/var/run/smtpd_tls_session_cache
smtp_tls_session_cache_database = btree:/var/run/smtp_tls_session_cache

To this:

smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache

Configure fail2ban to use route instead of iptables to block connections

Today I read about how to configure fail2ban to use route instead of iptables to block connections. I’m not planning to switch to the route command just yet, because I think when fail2ban uses IP tables it only bans an IP address from accessing a particular port (or set of ports). Although maybe I don’t care about that and just banning the whole host altogether would be OK.

The reason I’ve been looking in to fail2ban is that I have a heap of errors in my logs from fail2ban trying to use iptables and failing, e.g.:

 2012-02-04 00:23:02,939 fail2ban.actions.action: ERROR  iptables -D fail2ban-ssh -s 125.211.221.117 -j DROP returned 100
 2012-02-04 00:59:12,456 fail2ban.actions.action: ERROR  iptables -I fail2ban-ssh 1 -s 50.30.33.90 -j DROP returned 100
 2012-02-04 01:59:12,930 fail2ban.actions.action: ERROR  iptables -D fail2ban-ssh -s 50.30.33.90 -j DROP returned 100
 2012-02-04 08:35:13,252 fail2ban.actions.action: ERROR  iptables -D INPUT -p tcp -m multiport --dports ssh -j fail2ban-ssh
 2012-02-04 08:35:36,688 fail2ban.actions.action: ERROR  iptables -N fail2ban-ssh-ddos
 2012-02-04 08:35:36,695 fail2ban.actions.action: ERROR  iptables -N fail2ban-apache-overflows
 2012-02-04 08:35:36,703 fail2ban.actions.action: ERROR  iptables -N fail2ban-postfix

Watching the web-logs on all of my servers in real time

I have a computer sitting on my desk that is always on (it’s my file server) and it has a monitor attached which is almost never in use (I ssh to that server if I want to do things so it’s hardly ever logged in).

I thought it would be cool if on that monitor the web-logs from all of the systems I manage were shown so I could keep an eye on things and maybe learn a thing or two about my web-sites and how people are using them.

So the first thing I did was write a script to grab any given web log:

root@orac:~# cat /root/get-web-log.sh
#!/bin/bash
echo Starting download of $3...
while : ; do
  su -c "ssh $1 tail -f /var/log/apache2/$2 < /dev/null" jj5 \
    | tee -a /var/log/web.log \
    | grep --line-buffered -v "Mozilla.5.0 .compatible. Googlebot.2.1. .http...www.google.com.bot.html." \
    | grep --line-buffered -v "Baiduspider...http...www.baidu.com.search.spider.htm." \
    | grep --line-buffered -v "Mozilla.5.0 .compatible. Baiduspider.2.0. .http...www.baidu.com.search.spider.html." \
    | grep --line-buffered -v "Mozilla.5.0 .compatible. Exabot.3.0. .http...www.exabot.com.go.robot." \
    | grep --line-buffered -v "Mozilla.5.0 .compatible. YandexBot.3.0. .http...yandex.com.bots." \
    > /var/log/web/$3
  sleep 60
  echo; echo; echo Restarting download of $3...; echo; echo;
done

Then I wrote a series of scripts which call the get-web-log.sh script for specific web-sites on specific servers, e.g.:

root@orac:~# cat /root/web-log/get-jsphp.co
#!/bin/bash
/root/get-web-log.sh honesty www.jsphp.co-access.log jsphp.co
exit

Then I wrote a main script, rather unoriginally called info.sh, that kicks off the web logs downloads and then monitors their progress as they come through:

root@orac:~# cat /root/info.sh
#!/bin/bash

# disable the screensaver
setterm -blank 0 -powersave off -powerdown 0

# start downloading the web-logs
cd /root/web-log
./get-jsphp.co &
sleep 1
#...all the other downloaders, one for each site

# watch the web-logs
cd /var/log/web
tail -f *

# stop downloading the web-logs
kill %1
#...all the other kills, one for each downloader

exit

Then I edited /etc/init/tty1.conf so that on tty1, instead of having a login console, I automatically ran my info.sh script:

root@orac:~# cat /etc/init/tty1.conf
# tty1 - getty
#
# This service maintains a getty on tty1 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]

respawn
#exec /sbin/getty -8 38400 tty1
exec /root/info.sh < /dev/tty1 > /dev/tty1 2>&1

And that was it. The only trick was that I needed to disable the screen saver (as shown in the info.sh script) so that the screen didn’t constantly blank.

And now I can watch the web activity on all of my sites in real time.

How do I permanently disable Linux’s console screen saver, system-wide?

I was wondering how I could disable the console screen saver on my server (so I can watch progress of stuff in the background) and I found this article, How do I permanently disable Linux’s console screen saver, system-wide?

One of the solutions suggests installing the console-tools package, but there is another solution that looks like it doesn’t need any package installed, so I’m gonna give that a try first. The solution is to edit /etc/kbd/config and specify:

BLANK_TIME=0
POWERDOWN_TIME=0

I’ve configured that now but won’t be able to test for a while as I can’t reboot my server just at the moment.

While I was at it I figured I’d have num lock enabled by default too:

LEDS=+num

Update: I was finally able to reboot my system and test that config, and: it didn’t work.

I tried to apt-get install console-tools, but that make things even worse! I recommend that you don’t try and install console-tools on Ubuntu Lucid, if my experience is anything to go by. Lucky I could still SSH to my server, because there was no console!

In the end I settled on a solution I found over here, being to add the following to /etc/rc.local:

setterm -blank 0 -powersave off -powerdown 0

Postfix header checks

I wanted to do something about the fact that I get a lot of spam where the date is substantially in the past, that is, months or years ago.

I figure I’ll never get any mail that I care about where the date is set that far back so what I wanted was a way to filter out such email.

There didn’t seem to be any suitable option in Thunderbird, and I’d rather have this done on the server than the client anyway, so I started fishing around for options in Postfix.

I found out about header checks.

To enable I had to add a file to the header_checks configuration option in /etc/postfix/main.cf:

header_checks =
  regexp:/etc/postfix/header_filter_map
  regexp:/etc/postfix/spamheadercheck

Then I created a header_filter_map file with some regexes for the date:

/^Date: .* [JFMASOND][aepuco][nbrynlgptvc] 1\d\d\d/ DISCARD Date 1
/^Date: .* [JFMASOND][aepuco][nbrynlgptvc] 200\d/ DISCARD Date 2
/^Date: .* [JFMASOND][aepuco][nbrynlgptvc] 201[0-1]/ DISCARD Date 3
/^Date: .* Jan 2012/ DISCARD Date Jan
/^Date: .* Feb 2011/ DISCARD Date Feb
/^Date: .* Mar 2011/ DISCARD Date Mar
/^Date: .* Apr 2011/ DISCARD Date Apr
/^Date: .* May 2011/ DISCARD Date May
/^Date: .* Jun 2011/ DISCARD Date Jun
/^Date: .* Jul 2011/ DISCARD Date Jul
/^Date: .* Aug 2011/ DISCARD Date Aug
/^Date: .* Sep 2011/ DISCARD Date Sep
/^Date: .* Oct 2011/ DISCARD Date Oct
/^Date: .* Nov 2011/ DISCARD Date Nov
/^Date: .* Dec 2011/ DISCARD Date Dec

I also found this file so I added some rules for the X-Mailer header, like this:

/^X-Mailer: 0001/                               DISCARD Mailer 1
/^X-Mailer: Avalanche/                          DISCARD Mailer 2
/^X-Mailer: Crescent Internet Tool/             DISCARD Mailer 3
/^X-Mailer: DiffondiCool/                       DISCARD Mailer 4
/^X-Mailer: E-Mail Delivery Agent/              DISCARD Mailer 5
/^X-Mailer: Emailer Platinum/                   DISCARD Mailer 6
/^X-Mailer: Entity/                             DISCARD Mailer 7
/^X-Mailer: Extractor/                          DISCARD Mailer 8
/^X-Mailer: Floodgate/                          DISCARD Mailer 9
/^X-Mailer: GOTO Software Sarbacane/            DISCARD Mailer 10
/^X-Mailer: MailWorkz/                          DISCARD Mailer 11
/^X-Mailer: MassE-Mail/                         DISCARD Mailer 12
/^X-Mailer: MaxBulk.Mailer/                     DISCARD Mailer 13
/^X-Mailer: News Breaker Pro/                   DISCARD Mailer 14
/^X-Mailer: SmartMailer/                        DISCARD Mailer 15
/^X-Mailer: StormPort/                          DISCARD Mailer 16
/^X-Mailer: SuperMail-2/                        DISCARD Mailer 17

Now that I know how to do this I’ll start adding rules for particular spam that I seem to get a lot of.

I’m not sure if I made the best decision, but I decided to silently discard email rather than reject it.

Slowing down fail2ban

I had some messages from my fail2ban log like this:

 2012-02-03 00:59:33,810 fail2ban.actions.action: ERROR  iptables -N fail2ban-apache
 2012-02-03 00:59:33,838 fail2ban.actions.action: ERROR  iptables -N fail2ban-apache-overflows
 2012-02-03 03:42:49,355 fail2ban.actions.action: ERROR  iptables -D INPUT -p tcp -m multiport --dports http,https -j fail2ban-apache-overflows
 2012-02-03 03:43:04,998 fail2ban.actions.action: ERROR  iptables -N fail2ban-ssh-ddos
 2012-02-03 03:43:05,035 fail2ban.actions.action: ERROR  iptables -N fail2ban-apache-overflows
 2012-02-03 07:13:04,720 fail2ban.actions.action: ERROR  iptables -D INPUT -p tcp -m multiport --dports http,https -j fail2ban-apache-overflows
 2012-02-03 07:13:20,154 fail2ban.actions.action: ERROR  iptables -N fail2ban-ssh-ddos

I read over here about a workaround that goes like this:

Edit /usr/bin/fail2ban-client and add a call to time.sleep to mitigate a race condition:

def __processCmd(self, cmd, showRet = True):
    beautifier = Beautifier()
    for c in cmd:
        time.sleep(0.1)
        beautifier.setInputCmd(c)