Monthly Archives: August 2011

Adding Google Contacts to Roundcube Webmail


This article describes the necessary steps to integrate one’s Google-based address book to the Roundcube web-based IMAP client.

For people who tend to keep their personal information like contacts data in one self-managed place, it must seem rather lame to store those data at Google’s. Yet, there are virtually no free open source address books out there that could do what Google offers: full bidirectional sync with basically all mobile devices and support for major protocols. Therefore, using Google as storage for contacts data seems appropriate for the time being. Also, the integration with Google’s Calendar works like a charm. But that’s for another article.

Download of Google Contacts plugin

The necessary plugin can be retrieved from the following website: It is supposed to be stored in Roundcube’s plugins folder, where it is unpacked by:

tar xzf google_contacts-<version_numnber>.tar.gz

There is a config file alongside with the archive. It’s options do not need customization for general needs.

Creating the database table

In the plugin’s SQL-subfolder there is a file called mysql.initial.sql. After creating a new table called google_contacts in your Roundcube’s database, import the file mysql.initial.sql into the new table.

Installation of Zend package

The Google Contacts plugin needs the Zend GData APIs for it to work. Download the most recent version from and place it into Roundcube’s program/libs folder. After unpacking the according archive, a folder called ZendGdata-<version_number> should be there. In order to have Roundcube finding the relevant libs, create a symbolic link in program/libs as follows:

ln -s ZendGdata-1.11.10/library/Zend .

Configure Google Contacts access

If all went right there should be a new option in a user’s Roundcube settings. Under the section “Address Book” it is now possible to enter one’s Google account name and password. The next access to the user’s address book in Roundcube will trigger the sync with Google’s address book so that all existing contacts will be available.

Transmission daemon: remove finished torrents

In transmission-daemon, downloaded torrents stay listed as long as they are not manually removed. In order to get them flushed automatically, the following command run by cron can help:

transmission-remote -l | grep 100% | grep Done | \
awk '{print $1}' | xargs -n 1 -I % transmission-remote -t % -r

In order to add this to cron, the “%”-symbols have to be escaped with a leading slash like this:

*/5 * * * * /usr/bin/transmission-remote -l | grep 100\% | grep Done | awk '{print $1}' | xargs -n 1 -I \% /usr/bin/transmission-remote -t \% -r

FlexGet Installation in Ubuntu

This post is deprecated. Please go to for more recent information.

This posts documents the installation of FlexGet in Ubuntu. It uses FlexGet v1.0r2301 and by the time of writing it is tested on Ubuntu 11.04.

There is no apt-package for FlexGet available yet. It has to be installed from PyPI. In order to prepare the necessary build environment the following packages have to be installed:

aptitude install python2.6 python-setuptools

The next line downloads and builds FlexGet itself:

easy_install flexget

The following step is optional. In case an interface to transmission-daemon is of use, the according FlexGet-plugin is installed like this:

easy_install transmissionrpc

Installation of Mailman in Ubuntu

Mailman is a powerful mailing list manager. It has a decent web interface for users and admins and offers content filtering, archiving, and much more. This documentation is based on Mailman v.2.1.14, Ubuntu 11.04, and Exim v.4.7.4 as MTA.

Package installation

To install the necessary packages this line is used:

aptitude install mailman exim4-daemon-heavy

Initial config

Unfortunately, the next steps are not part of the process of package installation but have to be done manually. First, a site password has to be set:


Now, the initial list has to be created:

newlist mailman

Exim setup

To give Exim awareness of an existing Mailman setup, two ways are possible. The first one is based on the /etc/aliases file where new lists need to be added by hand. The second way is more comfortable, yet needs some customisation on the Exim part.

Alias file based

The previous step of creating the initial Mailman list results in the following output:

To finish creating your mailing list, you must edit your /etc/aliases (or
equivalent) file by adding the following lines, and possibly running the
`newaliases' program:

## mailman mailing list
mailman:              "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin:        "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:      "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join:         "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave:        "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner:        "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request:      "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe:    "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe mailman"

So, the lines after “## mailman mailing list” are to be copied and pasted at the end of the file /etc/aliases. This has to be done each time a new list is created. The changes are activated by the following line:

Exim config file based

The second way of configuration makes Mailman speak to Exim directly. Therefore, a couple of changes are to be made to different sections of the Exim config file at /etc/exim4/exim4.config.template.

In the section “MAIN CONFIGURATION SETTINGS” these lines are to be added:

# ---------- MAILMAN --------------------------------------------------------
# Home dir for your Mailman installation -- aka Mailman's prefix
# directory.

# User and group for Mailman, should match your --with-mail-gid
# switch to Mailman's configure script.
# ---------- /MAILMAN -------------------------------------------------------

In “ROUTERS CONFIGURATION” just below “begin routers” these line are new:

# ---------- MAILMAN --------------------------------------------------------
# Messages get sent out with envelope from "mailman-bounces@virtual_domain"
# But mailman doesn't put such addresses in the aliases. Recognise these here.
  domains = +local_domains
  require_files = MAILMAN_HOME/lists/$local_part/config.pck
  driver = accept
  local_parts = mailman
  local_part_suffix = -bounces : -bounces+* : \
           -confirm+* : -join : -leave : \
           -subscribe : -unsubscribe : \
           -owner : -request : -admin
  transport = mailman_transport

# Mailman lists
  domains = +local_domains
  require_files = MAILMAN_HOME/lists/$local_part/config.pck
  driver = accept
  local_part_suffix = -bounces : -bounces+* : \
                      -confirm+* : -join : -leave : \
                      -subscribe : -unsubscribe : \
                      -owner : -request : -admin
  transport = mailman_transport
# ---------- /MAILMAN -------------------------------------------------------

In section “TRANSPORTS CONFIGURATION” just after “begin transports” the next line need to be added:

# ---------- MAILMAN --------------------------------------------------------
  driver = pipe
  command = MAILMAN_WRAP \
            '${if def:local_part_suffix \
                  {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
                  {post}}' \
  current_directory = MAILMAN_HOME
  home_directory = MAILMAN_HOME
  freeze_exec_fail = true
# ---------- /MAILMAN -------------------------------------------------------

The new config is processed and set up by this line:

update-exim4.conf && service exim4 restart

Apache config

Mailman comes with a nice web UI and even a fitting config file for Apache. In /etc/apache2/sites-available/default the next two line are to be inserted right before the end of the file:

Include /etc/mailman/apache.conf
RedirectMatch ^/mailman(\/*)$ http://hostname.yourdomain.tld/cgi-bin/mailman/listinfo

The first line lets Apache parse the Mailman configuration file. The second line redirects all requests for http://hostname.yourdomain.tld/mailman to the listinfo page of Mailman at http://hostname.yourdomain.tld/cgi-bin/mailman/listinfo.

The changes are activated like this:

service apache2 restart

Workaround for list archives-bug in Ubuntu

In recent releases of the Mailman package for Ubuntu, the privileges on the directories of list-archives are not set properly so that new posts are not archived at all. To fix this the following line will help:

chown -R list /var/lib/mailman/archives/private/

In case there are already posts which are not indexed, the archive can be reinitialized like this:


Quick setup of Jabber-Server (ejabberd) in Ubuntu

This posts documents the necessary steps to setup a running Jabber-server in Ubuntu. It uses ejabberd v2.1.5 and by the time of writing it is tested on Ubuntu 11.04.

Installation of packages

First the according Ubuntu packages are supposed to be installed:

aptitude install ejabberd

Customizing the setup

Next step is to customize two settings in /etc/ejabberd/ejabberd.cfg:

%% Admin user
{acl, admin, {user, "youruser", "yourdomain.tld"}}.

%% Hostname
{hosts, ["yourdomain.tld"]}. 

The rest should basically fly by itself.

Now an administrative user has to be added. Is is done on the command line with:

ejabberdctl register youruser yourdomain.tld yourpassword

After this, the server can be started by the following line:

service ejabberd start

If all went well, now the administrative backend should be good to go. It is accessibly with this URL:


Customizing the DNS entry

In order to get your server compliant with most of the clients, your domain is supposed to offer the following SRV-entries (example shows bind zonefile entries):

yourjabberhostname       IN A       IP_of_jabberhost
_xmpp-client._tcp        IN SRV     5 0 5222 yourjabberhostname.yourdomain.tld.
_xmpp-server._tcp        IN SRV     5 0 5269 yourjabberhostname.yourdomain.tld.
_jabber._tcp             IN SRV     5 0 5269 yourjabberhostname.yourdomain.tld.

Have fun with your individual jabber server!

Testing webserver-security with Nikto

A decent tool to test a webserver’s security setup is Nikto. It performs comprehensive tests on any given webserver and outputs its vulnerabilities. Using Ubuntu, the tool is easily available. It can be installed like this:

aptitude install nikto

To perform an actual test, the basic syntax looks like this:

nikto -h www.serverofinterest.tld

Depending on the extend of the test and the vulnerability of the server in question, the output might take a while. Yet, it will be quite enlightening as to where a server’s problem are.