Posts tagged Linux

Configure exim4 to send mail to other hosts

If you have just installed Debian (or other Linux) you might be stumped as to why sending e-mails from web software (such as forum activation e-mails) is not working. The reason is that by default the exim4 mail software is setup not to forward any mail to any remote hosts. This of course is an excellent anti-spam measure, but not very useful if you really need a server to send mail out to the world.

The solution is really simple. Edit the file /etc/exim4/update-exim4.conf.conf and change the following line:




Then restart exim4 and you’re done! To test if it really works, first create a file called “testmail” that looks like this:

Subject: exim4 mail test
(blank line)

The “(blank line)” must obviously be a real blank line. Just press enter a few times and save the file. Then try to send it with the following command:

sendmail -v < testmail

Change the e-mail address into your own working e-mail address (like a Gmail account or something). The output of the sendmail command will give you a very detailed overview on how the e-mail was sent (or not). If the test was successful you’ll find the mail in your mailbox in a few minutes.

Solving “IPv6 addrconf: prefix with wrong length 48” permanently

If you have a recent distribution of Linux, you might find the message “IPv6 addrconf: prefix with wrong length 48” repeated a lot in syslog. If you Google this error message you’ll quickly find that this is because IPv6 auto configuration (sort of like DHCP) is failing. Now if you don’t want to bother with IPv6 yet or if you use static IPv6 (like my servers do) you don’t need IPv6 auto configuration.

A quick fix to solve the problem (as mentioned on sites like these) is to run the following commands:

echo 0 > /proc/sys/net/ipv6/conf/eth0/autoconf
echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_ra

And yes, that solves the problem – until the next reboot that is. The permanent solution mentioned on that site however, does not work (as also confirmed by this IPv6 howto). The reason is that referring to all network interfaces using “all” in the following lines in /etc/sysctl.conf somehow doesn’t work:

net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0

The simple solution is to refer to each network interface specifically. My servers have both eth0 and eth1 (2 NICs) so I setup /etc/sysctl.d/ipv6.conf as follows:

net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.eth0.accept_ra = 0
net.ipv6.conf.eth1.autoconf = 0
net.ipv6.conf.eth1.accept_ra = 0

If you have only one network interface, you can omit the “eth1” lines. Alternatively you can use pre-up commands as described in the IPv6 howto, though I think my solution is prettier.

How to prevent cron & PowerDNS clogging syslog

On a default Debian installation both cron and PowerDNS will log into /varlog/syslog. If you are running very frequent cron jobs (like every 5 minutes) or an active PowerDNS server (or recursor), you’ll find syslog will be completely clogged with mostly unimportant messages. The solution of course, is to have these two services output log messages to their own log files.

In Debian Linux, you’ll need to change a few configuration files. First in open /etc/rsyslog.conf and change the following line:

*.*;auth,authpriv.none          -/var/log/syslog

into this (basically add local0 and cron to the list of things not to log into syslog):

*.*;local0,cron,auth,authpriv.none          -/var/log/syslog

Then uncomment the line just below that (remove # sign):

cron.*                         -/var/log/cron.log

If you do not run PowerDNS you can skip to the end of this post. If you do run PowerDNS (server or recursor) create the file /etc/rsyslog.d/pdns.conf (for example using the command nano -w /etc/rsyslog.d/pdns.conf) with the following contents:

local0.* -/var/log/pdns.log

Then update your PowerDNS configuration to make use of this file by changing the following section in either /etc/powerdns/pdns.conf and/or /etc/powerdns/recursor.conf

# logging-facility      Facility to log messages as. 0 corresponds to local0

As you can see, uncomment the logging-facility line and set it to 0. After this reboot PowerDNS.

In order for the PowerDNS log file not to grow out of control, you might want to add it to the list of log files that should be rotated by editing /etc/logrotate.d/rsyslog and adding /var/log/pdns.log to the list of log files (I typically add this line below /var/log/messages just before the opening { bracket):


Finally restart rsyslog by running /etc/init.d/rsyslog restart

Multiple DNS servers with PowerDNS and MySQL replication

With DNS it is essential to have at least two and preferably more DNS servers for your domains in geographically separated locations. Putting all your DNS servers on the same server is asking for trouble: even if your server goes down for only a little while (like a reboot) some visitors may perceive your sites due to negative DNS caching (where a visitor’s ISP resolving DNS server will “remember” your site “does not exist” for a while).

There are of course several commercial DNS hosting providers that can solve this problem for you, but most of these charge by how much DNS traffic your domains generate. For certain types of very popular sites (like image & file hosting sites) that may be costly because of the level of DNS traffic they generate. Or perhaps you simply want to maintain your own DNS servers.

The solution is to have several DNS servers powered by PowerDNS using MySQL as a backend, and synchronizing the DNS servers not using any DNS specific mechanism but simply through MySQL replication.  As the main DNS server you could use your own server, and as secondary servers you can use other servers or cheap VPS servers.

As PowerDNS supports caching using MySQL as a backend is not going to be a performance issue unless you really have a lot of different domains you want to provider DNS for (and in that case, just get beefier hardware or more servers). For information on how to setup PowerDNS with MySQL, see the official documentation.

To setup MySQL replication I recommend this guide, although the part on the first page about getting a snapshot of the master server (using the lock/unlock commands) is a bit obsolete if you used InnoDB to create the tables for PowerDNS. With InnoDB you can get a snapshot without any interruption with a single command:

mysqldump --opt --single-transaction --flush-logs --master-data=1 pdns > pdns.sql

The “master-data=1” bit even includes the right CHANGE MASTER command in the dumped SQL file, so you don’t need to manually specify the master position and only need load the SQL dump and restart the slave. Be aware though that MySQL replication might sometimes break (for example if one of the servers was uncleanly reboot) so occasionally check if MySQL replication is still working from phpMyAdmin or using the SHOW SLAVE STATUS command. For DNS troubleshooting I highly recommend

I apologize this post is not a straight-forward how-to, but hopefully it will point you in the right direction.

Keep WordPress & phpMyAdmin up-to-date with a single command

Notice: see this follow-up post for better ways of keeping WordPress & phpMyAdmin up-to-date.

Keeping up-to-date with the latest versions of commonly used web software such as WordPress and phpMyAdmin can be a bit of a drag if you would have to manually download, unzip and upload new files through FTP each time a new version is released.

But keeping WordPress and phpMyAdmin up-to-date can be as simple as logging into your server with SSH and executing just a single command. The key to this is that these software are being developed using version control software like Subversion and Git. Not only developers can take advantage of this however; you as end-user can use them as well.

First you’ll need to install Subversion and/or Git of course. On Debian (and Ubuntu presumably) you can do this by simply running the following command (as root):

aptitude install subversion git-core

Once either or both have been installed, I can simply recommend the excellent Installing/Updating WordPress with Subversion article in the case of WordPress.

For phpMyAdmin you will need to following commands from the root directory where you would want to install phpMyAdmin in:

git clone
cd phpmyadmin/
git branch --track STABLE origin/STABLE
git checkout STABLE
git pull

In case of a new install don’t forget to copy “” to “” and editing it where applicable (see the phpMyAdmin documentation for more info). To keep it up-to-date, then simply run the following command from the “phpmyadmin” folder  whenever a new version is released:

git pull

This command should not overwrite custom files like the configuration file.

Update April 2012: it would appear phpMyAdmin has moved to GitHub, so the URL above has been updated.

Go to Top