Category: Tips

Configure Thunderbird 3’s indexing behaviour

The current version of Thunderbird comes with a terrific global search functionality, but sometimes its cumbersome to watch it reindex the email history if something corrupted the database or to get emails in the search results which you’re absolutely not interested in (commit messages, f.e.).

Unfortunately Thunderbird 3 has only a global option to enable / disable the search database and the indexer, but a smart guy has filled this gap with his extension GlodaQuilla. After you’ve installed it you can configure so-called “inherited properties” for every account

… and every folder, easily overridable simply by toggling the “inherit” option:

I’d prefer that the Thunderbird guys would build this right into the product itself, but until that has been done this add-on is a life saver!

Quick Tip: NetworkManager and /etc/resolv.conf

If you have trouble with NetworkManager overwriting your `search` and `domain` configuration after every startup and you’re using DHCP, add the following line to your `/etc/dhclient.conf`:

append domain-name " company.local other.company.local";

So whenever your DHCP server doesn’t provide these information (the one in my company does not), it’ll add this

domain company.local
search company.local other.company.local

to your `/etc/resolv.conf`.

Useful Gotcha #27

If you get this error ssl_error_rx_record_too_long when browsing an SSL-secured virtual host and wonder what the heck is going on (hey, it worked the day before), ensure that you’ve noticed that your admins have changed the IP address of the machine and that you have to adapt the IP-based VHost configuration accordingly… not that this SSL error wouldn’t have said that in first place!

Enable more locales in stock Debian installations

If you wonder why

 $ php -r "setlocale(LC_TIME, 'de_DE.UTF-8'); echo strftime ('%A %e %B %Y', mktime (0, 0, 0, 12, 22, 1978));"

gives you Freitag 22 Dezember 1978 on most systems like f.e. openSuSE and Ubuntu, but Friday 22 December 1978 on Debian, you need to remember that the Debian guys outsmart everything and everybody with a shell script and a configuration file, just to keep your installation lean and clean.

In this particular example, edit /etc/locale.gen and add de_DE.UTF-8 UTF-8 (or anything else listed in /usr/share/i18n/SUPPORTED), hit save and then execute

 $ sudo /usr/sbin/locale-gen

and voila, the above PHP call (and everything else which requests a German locale) works!

If you’re setting up exim from scratch…

…and you’re a bloody novice like me, you’ll probably stumble upon Marc Merlin’s “Very detailled and featureful configuration example”. If you use that one and you wonder why on earth people can’t authenticate against your local SMTP via PAM, you seek hours and hours in different places, forums, IRC and whatnot, and all you get in /var/log/exim4/mainlog is a couple of these:

2008-09-26 22:35:15 svr_auth_login authenticator failed for <hostname> [<clientip>]:61588 I=[<serverip>]:25: 535 Incorrect authentication data (set_id=<login>)

make sure /etc/shadow is actually readable by Debian-exim, the exim4 user, f.e. by adding him to the shadow group… D’oh!

Don’t ask me how this worked in the original debian configuration (which unfortunately did not work for me in a couple of other places, otherwise I’d have stuck to it) – from what I’ve seen I believe it somehow used the courier installed on the same machine to do the authentification.

Kudos to this page which made me find the problem.

$_POST empty?!

So I was about to SSL-secure my new webmail setup, created a new cert on CAcert, installed it, configured my vhost accordingly, went to the webmail login page and… boom. Login was not possible. No error message, no log message, nothing.

What happened?

To make a long story short, the PHP superglobal $_POST which stores data from POST requests was completly empty, though a valid POST request has been triggered. Not even $HTTP_RAW_POST_DATA was set and a hint I found on the net about a not set content-type didn’t help either.

So I went back to my vhost configuration again, where I configured a simple redirect for the *:80 vhost to the *:443 vhost. I copied over my original configuration (PHP FCGI) from the SSL one over to the non-ssl one to check if the problem also persists on non-SSL connections. And apparently it did not! Weird enough, now it even worked when doing the request over SSL…! Even weirder was, as soon as I commented out certain (uneccessary) options like ErrorLog from the SSL one, it broke again…

Something must have been messed with my FastCGI php processes – since I only did a reload after each configuration change before, I decided to make a hard apache restart – and voila! The problem was gone completly!

Hrm… this reminds me that there was this one operating system which could also be fixed by a restart. If I could only remember its name…