Tag Archives: tip

exim4 and catchall email address

If you search for a way how to configure a catchall email address with exim4, it is highly probable that you will see a router like:

  debug_print = "R: system_aliases for $local_part@$domain"
  driver = redirect
  domains = +local_domains
  data = ${lookup{$local_part}lsearch*{/etc/aliases}}

In this case the catchall mechanism is included in the system_alias router that normally just uses:

 data = ${lookup{$local_part}lsearch{/etc/aliases}}

Thus each email sent to an address entered before the “:” in /etc/alias will be redirected to the mailbox entered after the “:”.
By changing lsearch to lsearch* you can have an entry in /etc/aliases that looks like

*: catchall

This should be at the end of the alias file and for every address that has no other entry, the email is redirected to the catchall-mailbox.

Unfortunately this has the drawback that you need to add an entry for every user that should get emails that looks like:

user: user

If you ommit it, all emails to user will be put into the catchall-mailbox. That’s because the sequence of exim4 routers matters and in the Debian default configuration the router that checks for local users is put behind the system_aliases-router. You might think about changing the sequence of routers, but this is generally a bad idea. If you reverse the order of system_aliases and local_user, you can no longer redirect emails to system accounts like uucp or news to something more appropriate.

So, why not leave the system_aliases-router alone and simply add another router at the end of the router section:

  debug_print = "R: catchall for $local_part@$domain"
  driver = redirect
  domains = +local_domains
  data = catchall

It is very similar to the system_aliases-router but does not search anything for a matching entry but simply redirects everything to catchall. If it is really at the end, the email would have been rejected without this router and so no harm related to the behaviour of other routers is done. Due to driver = redirect it even takes care of .procmailrc and/or .forward …

USB 3.0 hub and Gigabit LAN adapter

Recently I bought an USB 3.0 Hub with three USB 3.0 ports and one Gigabit LAN port. It is manufactured by Delock and I purchased it from Reichelt (Delock 62440).

Under Wheezy the USB part is recognized without problems but the kernel (3.2.0-4) does not have a driver for the ethernet part.
The USB Id is idVendor=0b95 and idProduct=1790, the manufacturer is ASIX Elec. Corp. and the product is: AX88179. So Google led me to a product page at Asix, where I could download the driver for kernel 2.6.x and 3.x.

mkdir -p /usr/local/src/asix/ax88179
cd /usr/local/src/asix/ax88179
wget www.asix.com.tw/FrootAttach/driver/AX88179_178A_LINUX_DRIVER_v1.13.0_SOURCE.tar.bz2
tar -jxf AX88179_178A_LINUX_DRIVER_v1.13.0_SOURCE.tar.bz2
cd AX88179_178A_LINUX_DRIVER_v1.13.0_SOURCE
apt-get install module-assistant
module-assistant prepare
make install
modprobe ax88179_178a.ko

After editing /etc/network/interfaces and doing an ifup eth1, voila, I have a new network link. I hope the hardware is as good as the installation has been easy.

Manage own CA with Debian

Self signed SSL certificates are nice, but only provide encryption of retrieved data. Nobody knows who is really sending the data.

If one buys an SSL certificate for a website, the browser doesn’t complain as much as with a self signed certificate. But can you really trust the other side? Almost every commercial CA has some kind of “fast validation” or “domain validation, issued in minutes”, which is done by email or phone. So if required, within minutes everybody might become you. Even with putting money on the table your users can not be sure whether this server really belongs to the right guy.

Well, why wasting time and money? Just create your own Root CA and tell users that they need to add something in order to avoid some error messages. In Debian we basically have five packages who claim to be able to manage some kind of CA.

easy-rsa is mainly needed to manage certificates used by openVPN. Within this use case it works like a charm, but I don’t want to manage a more complex CA with it.

gnomint is dead upstream and only uses SHA1 as signature algorithm. This will cause lots of problems as Mircrosoft and Google want to deprecate SHA1 in their products by 2017. Besides, this package is already orphaned and maybe it can disappear now.

tinyCA uses more signature algorithms, unfortunately SHA1 seems to be the “best” it can. There are some patches to support up to SHA512, but they don’t work for all parts of the software yet. For example Sub-CAs still use SHA1 despite of choosing something different in the GUI. So nice, but not (yet) usable in Jessie.

FreeIPA seems to be great, but didn’t make it into Jessie in time. Unfortunately the Release Team has reasons to not unblock it. So nice, but not usable in Jessie.

xca is based on QT4. As announced in the 15th DPN of 2014 the deprecated QT4 will be removed from Debian Stretch (= Jessie+1). Apart from this, the software meets all my requirements.

Xen toolstack

Notice to my future self: In the default Jessie installation of Xen a new toolstack called xl is introduced. More information about the motivation in doing this can be seen in the Xen Wiki. It should be backward compatible with the removed xm (=XEND) toolstack, so in any command just use xl insead of xm.

Problem starting XEN guest

Notice to my future self: In case there are problems starting a domU, and /var/log/xen/xend.log says something about “Cannot allocate memory” then look at the memory consumption of dom0 with:

xm list

If this value is near the maximum available memory, just use

xm mem-set Domain-0 6500

or whatever looks good.

Moving WordPress to another server

Today I moved this blog from a vServer to a dedicated server. The migration went surprisingly smooth. I just had to apt-get install the Debian packages apache2, mysql-server and wordpress. Afterwards only the following steps were necessary:

  • dumping the old database with basically just one command:

    mysqldump -u$DBUSER -p$DBPASS –lock-tables=false $DBNAME > $DBFILE

  • creating the database on the new host:

    \r $DBNAME

  • importing the dump with something like:

    mysql –user=$DBUSER –password=$DBPASS $DBNAME < $DBFILE

and almost done …

Finally some fine tuning of /etc/wordpress/htaccess and access rights of a few directories to allow installation of plugins. As I wanted to clean up my wp-content-directory, I manually reinstalled all plugins instead of just copying them. Thankfully all of the important plugins store their data in the database and all settings survived the migration.

Configure services – bind (3.1)

After preparing everything, we can start to configure different services now. The first one shall be bind9. There are lots of information out there about configuring bind9 for IPv4, so I assume that there is a bind already running.

A newly installed bind (remember I am mainly writing about Debian systems) has the following option configured in /etc/bind/named.conf.options

options {
listen-on-v6 { any; };

Thus this daemon listens on all IPv6 interfaces to answer queries.

In the next step we just need to configure AAAA-records for every IPv6-address that we want to distribute. They look like A-records:

dummyhea.ipv6.alteholz.net. IN A
dummyhea.ipv6.alteholz.net. IN AAAA 2a01:4f8:d12:1b03::dead:2

Voila, we are done:

~$ dig dummyhea.ipv6.alteholz.net AAAA

; <> DiG 9.8.4-rpz2+rl005.12-P1 <> dummyhea.ipv6.alteholz.net AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25822
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5

;dummyhea.ipv6.alteholz.net. IN AAAA

dummyhea.ipv6.alteholz.net. 5706 IN AAAA 2a01:4f8:d12:1b03::dead:2

~$ ping6 -c5 dummyhea.ipv6.alteholz.net
PING dummyhea.ipv6.alteholz.net(2a01:4f8:d12:1b03::dead:2) 56 data bytes
64 bytes from 2a01:4f8:d12:1b03::dead:2: icmp_seq=1 ttl=49 time=66.8 ms
64 bytes from 2a01:4f8:d12:1b03::dead:2: icmp_seq=2 ttl=49 time=67.1 ms
64 bytes from 2a01:4f8:d12:1b03::dead:2: icmp_seq=3 ttl=49 time=66.8 ms
64 bytes from 2a01:4f8:d12:1b03::dead:2: icmp_seq=4 ttl=49 time=71.6 ms
64 bytes from 2a01:4f8:d12:1b03::dead:2: icmp_seq=5 ttl=49 time=66.3 ms

--- dummyhea.ipv6.alteholz.net ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 66.378/67.782/71.678/1.969 ms

This was pretty easy.