technology and zen of life

“A heisenbug (named after the Heisenberg Uncertainty Principle) is a computer bug that disappears or alters its characteristics when an attempt is made to study it.”

Installation notes for Postfix, SASL and Unbound on RHEL 6

Today I finished installing and configuring a filtering mailserver that does virus- and spamfiltering. In fact, it only does filtering, and then passes the mail on to internal mail servers.

I hit a few hurdles and these installation notes are meant for my own future reference. I publish them on this weblog so others might benefit as well.

Environment

A Scientific Linux (RHEL clone) 6.4 64-bit installation, virtualized inside a KVM host. I use macvtap/macvlan networking and virtio drivers. The EPEL repository is activated.

I used the Spamassassin Ultimate Setup Guide written by Warren Togami to get most of the system up.

Fixing SASL support for Postfix

My SASL-Postfix configuration

As the mailserver is mainly a spam filter and frontend SMTP receiver, I do not run Dovecot or other IMAP servers on the box. So I opted for the Cyrus SASL components.

Furthermore I use the sasldb plugin to have more secure password mechanisms over the line (I don’t care about the unencrypted storage as my SMTP password differ from user passwords). Manage SMTP users with saslpasswd2 (db stored in /etc/sasldb2).

Install SASL support:

yum install cyrus-sasl*

cat /etc/sasl2/smtpd.conf

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: CRAM-MD5 DIGEST-MD5 NTLM

cat /etc/postfix/main.cf | grep sasl

smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous, noplaintext

Postfix error: no SASL authentication mechanisms

less /var/log/messages

filter postfix/smtpd[12154]: fatal: no SASL authentication mechanisms

Install all “mechanisms”:

yum install cyrus-sasl*

Check mechanism files using:

ls /usr/lib64/sasl2/

Postfix error: sql_select option missing

less /var/log/messages

Oct 17 12:41:35 filter postfix/smtpd[3852]: sql_select option missing
Oct 17 12:41:35 filter postfix/smtpd[3852]: auxpropfunc error no mechanism available
Oct 17 12:41:35 filter postfix/smtpd[3852]: auxpropfunc error invalid parameter supplied

According to CarbonCopy, “I found this on another site and it worked fine”

The workaround for the above problem is actually quite simple, really. You simply remove all the libsql* files in /usr/local/lib/sasl2. That’s it. Personally, I moved them all into a folder I created in that directory on the off chance that I may need them in the future. Obviously, this is going to wreak havoc if you are using libsasl for more than one app’s authentication and the other one uses sql. But, if you are using it as I am, where I’m only using sasl for smtp auth through an alternate mechanism (authdaemond in my case), then this will end the spamming of your log file.

Seems indeed to be a problem, as I have cyrus-sasl-sql installed.

yum list installed | grep cyrus-sasl

So remove it with:

yum remove cyrus-sasl-sql

And the error message is gone. (Check by restarting postfix and checking /var/log/messages).

Unbound SELINUX problem with root.anchor

A filtering mailserver will do lots of DNS lookups, because of the large amount of spammers who use all kind of (bogus) host names, and because of DNS based blacklists. You want to cache DNS requests so your mail flow will not me needlessly delayed by nameserver requests.

Of course a spam- and virusfiltering server needs to be tought. Do not disable SELINUX. If you don’t know selinux, watch this great video: SELinux For Mere Mortals, by Thomas Cameron, Red Hat Summit 2012.

I choose Unbound because of it’s reputation of being fast, modern, and secure. And it is developed in The Netherlands

Installation of Unbound

yum install unbound (EHEL repo)

That installs these packages:

  • ldns-1.6.16-2.el6.x8664.rpm – libevent-1.4.13-4.el6.x8664.rpm – unbound-1.4.21-1.el6.x86_64.rpm
  • unbound-libs-1.4.21-1.el6.x86_64.rpm

Error reading root.anchor

But the unbound service did not start successfully. There was a selinux problem accourding to /var/log/messages:

Oct 17 12:57:42 filter unbound: [4004:0] error: unable to open /var/lib/unbound/root.anchor for reading: Permission denied
Oct 17 12:57:42 filter unbound: [4004:0] error: error reading auto-trust-anchor-file: /var/lib/unbound/root.anchor
Oct 17 12:57:42 filter unbound: [4004:0] error: validator: error in trustanchors config
Oct 17 12:57:42 filter unbound: [4004:0] error: validator: could not apply configuration settings.
Oct 17 12:57:42 filter unbound: [4004:0] error: module init for module validator failed
Oct 17 12:57:42 filter unbound: [4004:0] fatal error: failed to setup modules

This specific error might be somewhat related to other selinux packaging bugs, for examble bug 963067 and bug 896599.

Fix using audit2allow

Googling for “audit2allow el6? tells me it’s in policycoreutils-python, so let’s install that:

yum install policycoreutils-python

And this is how we are going to fix it by creating a selinux policy:

grep unbound /var/log/audit/audit.log | grep root | audit2allow -M unbound-fix-anchor
semodule -i unbound-fix-anchor.pp

(Note that I first did a “grep anchor” but that didn’t do the trick, so then I tried a “grep root”.)

And yes it works

Configure Unbound for a mailserver

I love a large DNS cache to speed up mail delivery and lower network traffic from my mailserver. Luckely, there is an Unbound optimization guide. Add the text below to /etc/unbound/unbound.conf

    # more cache memory, rrset=msg*2
    # Due to malloc overhead, the total memory usage is likely
    # to rise to double (or 2.5x) the total cache memory!!
    rrset-cache-size: 100m
    msg-cache-size: 50m

Furthermore, you might want to give internal mailservers the local IP addresses they have. Add to /etc/unbound/local.d/internal-mailservers.conf

local-data: "bifrost.evert.net. IN A 10.0.0.7"
local-data: "bifrost. IN A 10.0.0.7"

Configure Postfix to use the local DNS caching nameserver

Of course, don’t forget to make sure your mailserver uses the DNS caching nameserver. There are various methods to do so:

  • edit /etc/resolv.conf (if you don’t use Network Manager), set nameserver 127.0.0.1
  • configure using Network Manager
  • edit /etc/sysconfig/network-scripts/ifcfg-eth0, set BOOTPROTO=dhcp and PEERDNS=no (if PEERDNS is disabled, then /etc/resolv.conf will not be modified when this interface gets its DHCP address)
  • when using DHCP, set a custom DHCP reservation with DNS server 127.0.0.1 for the mailserver

About Evert Mouw

Interested in kinda everything, studied political science, now studying medical informatics. MCSE, Linux enthousiast, and believing that technology is the path to enlightenment ;-) Best RTS game ever is Warhammer Soulstorm (IMHO). Other hobbies include hiking, kayaking, reading and when I have time, trying to have an ant colony in an artificial nest (formicarium).

Leave a Reply

3 Responses

  1. For the Unbound error, on CentOS its “unbound-anchor”, not “unbound-fix-anchor”: found your blog on how to fix, then found this when the error still happened. Thanks for the good lead overall.

    http://rpm.pbone.net/index.php3/stat/45/idpl/21959703/numer/8/nazwa/unbound-anchor

    • Followup: https://admin.fedoraproject.org/updates/unbound-1.4.21-1.el6 mentions attempts to solve some SELinux bugs. On CentOS 6.4, you still might not be able to use Unbound for forwarding local domains without finding a way to tell SELinux to allow changes to /var/lib/unbound/ (other forums suggest its failing on recreating the root.anchor file); or have it use a different directory altogether.

      • Evert Mouw says:

        Michael, thanks for your comments. The nameof the policy file (“unbound-anchor” | “unbound-fix-anchor) should not matter. There are indeed still SELinux bugs. For me it’s running Ok but for various cases installing unbound on RHEL or a clone might be a bit of a hassle.

Email Subscription

Disclaimer

The views expressed on this blog are personal. We do not claim to be a representative voice of the views of any organisation whatsoever. We are not responsible for the content present on the blogs to which we have linked.Views expressed are solely that of the author and does not reflect a collective opinion of contributors.
%d bloggers like this: