HomeHome ArchiveArchive

Vortrag FOSSGIS 09

Sourcepole war an der FOSSGIS vom 17.-19. März 2009 an der Leibniz-Universität in Hannover mit dem Vortrag “Kartenaufbereitung für Tile Map Services mit Cloud Computing” vertreten. Die Folien stehen hier zum Download zur Verfügung.

Exim4 and Spamassassin - which user to run as?

Some of the more or less officially recommended documents describing how to set up SMTP time spam scanning suggests calling (?) Spamassasin from Exim as user “nobody”.

However under Debian the User nobody intentionally has no home directory and thus, depending on how you’ve set up Exim4 and Spamassassin, Spamassassin will try to save its settings in its $HOME, resulting in the following error (visible in /var/log/mail.log):

Mar 2 09:55:59 mail spamd[4896]: config: cannot write to /nonexistent/.spamassassin/user_prefs: No such file or directory

A posting in a often referred to thread has a few suggestions for setup. The problem there however is that they are mutually exclusive in that you get either scanning at SMTP time or scanning for each user individually.

I do want individual users to be able fine tune Spamassassin for their needs but I also want the main bulk of spam rejected at the SMTP connection.

Thus, as suggested in the posting above I did create a special spamd user:

adduser --disabled-password spamd

which is not used for running spamd. but only used by Exim4’s exiscan patch to check for spam. Therefore I replaced all the following lines from the howto:

spam = nobody:true


spam = spamd:true

Seems to work.


The reason I dropped sendmail 15 years ago was that the configuration was way more complex than learning a new computer language. Exim4 has got to the exact same point by now: Debian’s variant of Exim4 has dozens of interdependent config files, partially created from templates and being rebuild by generators with half-standardized variables etc. It’s a pain. Maybe I should have upgraded to postfix from exim3 instead.

Evidently the Mail community needs a variation of Greenspun’s Tenth Rule Of Programming:

“Any sufficiently advanced MTA program contains an ad-hoc, informally-specified reimplementation of sendmail’s configuration system”

Openoffice: Replace <13><10> in CSV

After importing a CSV document (comma separated table) there were sequences of litteral “<13><10>” text in some of the cells in Openoffice.

What you need to do is to replace them by a newline with a text editor, before importing them n Openoffice.

In vim you do that by opening the file, marking the whole document with “V0G”, and then replacing all the occurences of “<13><10>” with a newline by issuing “:s/<13><10>/Ctrl-VEnter/a”, where Ctrl-V is pressing down the Ctrl key and then the ‘v’ key and Enter is pressing the “Enter” key.

Tomáš Pospíšek

Deploying Mephisto with Capistrano

load 'deploy'
require 'mongrel_cluster/recipes'

set :application, "mysite"
set :deploy_to, "/var/www/#{application}"

set :scm, :git
set :repository, "git://github.com/emk/mephisto.git"
set :branch, "v0.8-stable"
set :deploy_via, :remote_cache

set :user, "www-data"
set :use_sudo, false
set :mongrel_conf, "#{current_path}/config/mongrel_cluster.yml"

role :app, "myserver"
#role :web, "myserver"
role :db, "myserver", :primary => true

after 'deploy:update_code', 'deploy:finalize_update_code'
after 'deploy:rollback:revision', 'deploy:finalize_update_code'

desc "Finalize update_code"
deploy.task :finalize_update_code do
  run "cp -rf #{shared_path}/config/* #{current_release}/config/"
  run "cp -rf #{shared_path}/public/* #{current_release}/public/"
  run "rm -rf #{current_release}/public/assets; ln -s #{shared_path}/assets #{current_release}/public/assets"
  run "rm -rf #{current_release}/themes; ln -s #{shared_path}/themes #{current_release}/themes"

After an initial

cap deploy:setup

place the version independent data into the shared directory:


After that, a Mephisto update should be as simple as

cap deploy