Category Archives: Linux

Configure Spamassassin for Exim 4 in Ubuntu

*[MTA]: Mail Transfer Agent
This article describes the configuration of the spam scanner called spamassassin in conjunction with the MTA called Exim 4 in Ubuntu Linux (as of writing Ubuntu 11.10 is the most recent). Assuming an otherwise working Exim 4 setup, this document describes just the essential steps to a working spamscanner.

First, the necessary packages need to be installed:

aptitude install exim4-daemon-heavy sa-exim spamassassin

In /etc/default/spamassassin set the following lines:

ENABLED=1
CRON=1

The first option lets the spamassassin daemon start on boot. The second one defines that spamassassin's rules become updated each night using a cron job.

In order to check if the first steps went ok, it's time to start spamassassin the very first time:

service spamassassin start

To check if spamassassin runs smoothly on it's dedicated port, this command helps:

lsof -i :783

Now in /etc/exim4/exim4.conf.template, insert the following lines in MAIN CONFIGURATION SETTINGS:

local_scan_path = /usr/lib/exim4/local_scan/sa-exim.so

To enable Exim's spamassassin connector, the file /etc/exim4/sa-exim.conf has to be modified. Comment the following line in that file:

# SAEximRunCond: 0

In default setups, debugging is enabled. That will lead to huge log files. So for production use, changing the following line to zero is advised:

SAEximDebug: 0

The updated file /etc/exim4/exim4.conf.template becomes active by running the following line:

update-exim4.conf && service exim4 restart

For a basic protection, the MTA is now good to go.

Disable Multiarch in Ubuntu Oneiric 11.10

Since Ubuntu 11.10 multiarch support becomes set by default in new systems as well as in upgraded ones. This sounds like a nice feature, but it breaks one of my favorite tools: aptitude. As of now, aptitude can't handle multiple arches of the same package and therefore runs wild when told to do any task.

The solution to this is to disable multiarch for the time being. This is done by the following command:

mv /etc/dpkg/dpkg.cfg.d/multiarch /etc/dpkg/dpkg.cfg.d/multiarch.backup && apt-get update

In case aptitude learns how to handle multiarch some day, it can be re-enabled by running the command the other way round.

Move Cacti data from one platform to another one

In order to migrate Cacti's rrd-tool data from one system to a different one, that data has to be converted to XML-format first. That is also true if you move from x86 to a x86_64.

To to so, first convert all rrd-data in /var/lib/cacti/rrd to XML using the following line in that folder:

for i in find -name "*.rrd"; do rrdtool dump $i > $i.xml; done

Now pack up the resulting XML-files:

tar czf cacti-xml.tar.gz /var/lib/cacti/rrd/*xml

Move the tar.gz-container to the new system and unpack its files in the same directory using:

tar xzf cacti-xml.tar.gz

The re-conversion of those XML-files into rrd format is done using this line:

for i in find -name "*.xml"; do rrdtool restore $i echo $i |sed s/.xml//g; done 

Resetting the MySQL root password the dirty way

It happens to me quite often that I forget the root password of a MySQL-setup. In that case, a dirty way to reset the root user's password is to stop the database and run it with "--skip-grant-tables". This enables anyone to connect without a password and with all privileges which is certainly not recommended for regular use. After changing the password, the database is supposed to be restarted with regular settings.

The following lines document the actual doing. Remember to replace NEW_PASSWORD in the last line with your new one:

service mysql stop
mysqld --skip-grant-tables &
mysql -u root mysql
UPDATE user SET Password=PASSWORD('NEW_PASSWORD') WHERE User='root'; FLUSH PRIVILEGES; exit;
ps ax|grep mysqld | awk '{print $1}'|xargs kill -9
service mysql start

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: http://sourceforge.net/projects/roundcubegoogle/files/. It is supposed to be stored in Roundcube's plugins folder, where it is unpacked by:

tar xzf google_contacts-.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 http://framework.zend.com/download/webservices 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

*[PyPI]: Python Package Index

This post is deprecated. Please go to http://www.grosseosterhues.com/2012/02/flexget-installation-and-upgrade/ 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

*[MTA]: Mail Transfer Agent

 

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:

mmsitepass

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:

newaliases
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.
MAILMAN_HOME=/var/lib/mailman
MAILMAN_WRAP=MAILMAN_HOME/mail/mailman

# User and group for Mailman, should match your --with-mail-gid
# switch to Mailman's configure script.
MAILMAN_USER=list
MAILMAN_GROUP=daemon
# ---------- /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.
mailman_workaround:
  domains = +local_domains
  require_files = MAILMAN_HOME/lists/$local_part/config.pck
  driver = accept
  local_parts = mailman
  local_part_suffix_optional
  local_part_suffix = -bounces : -bounces+* : \
           -confirm+* : -join : -leave : \
           -subscribe : -unsubscribe : \
           -owner : -request : -admin
  transport = mailman_transport
  group = MAILMAN_GROUP

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

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

# ---------- MAILMAN --------------------------------------------------------
mailman_transport:
  driver = pipe
  command = MAILMAN_WRAP \
            '${if def:local_part_suffix \
                  {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
                  {post}}' \
            $local_part
  current_directory = MAILMAN_HOME
  home_directory = MAILMAN_HOME
  user = MAILMAN_USER
  group = MAILMAN_GROUP
  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:

/var/lib/mailman/bin/unshunt

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:

http://yourjabberhostname.yourdomain.tld:5280/admin

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.