Tag Archives: tip

dcmd: what is in the dsc file

Notice to my future self: If you want to see a list of files that are referenced by a Debian dsc-file, you need to use:

dcmd dsc-file

The output is the list of files in its ‘Files’ section, plus the dsc-file itself. You can also apply dcmd to changes-files. You can also use a command as the second parameter and do funny stuff with all those files within the dsc-file.

Litecoin and IPv6

Notice to my future self: If you start the litecoin client (v0.10.2.2) all peers in peers.dat seem to be IPv4 only. At least, I got no connection to the Litecoin network. After looking at the list of supernodes, I could filter two supernodes with IPv6 addresses:

  • ltc.block-explorer.com
  • ltc.lfcvps.com

Putting them as


into litecoin.conf, I got my connection and could do some transactions.

openvpn: ping only works between server and client

Notice to my future self:

  • an openvpn connection can be stablished between client and server
  • you can ping the server from the client
  • you can ping the client from the server
  • you added the route in your server config
  • route -n shows everything is in place
  • but you can not ping any host on an attached network

… then you forgot to add a file in the ccd-directory for the correct common name of your client containing all iroute statements.

Package of the Day: ansiweather

While looking at NEW I sometimes see a package and think “wow this is great, you have to try this”.

One of these packages is ansiweather. It looks at the data at openweathermap and presents them on the console. So with

ansiweather -l chemnitz -u metric

I get something like:

Current weather in Chemnitz => 12 °C ☔ – Wind => 2.52 m/s WNW – Humidity => 80 % – Pressure => 1014 hPa

Now I see that I need a coat and an umbrella for my walk. Or better I don’t go outside and continue looking at other stuff in NEW :-)

alpine and UTF-8 and Debian lists

This is a note for my future self: When writing an email with only “charset=US-ASCII”, alpine creates an email with:

Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

and everything is fine.

In case of UTF-8 characters inside the text, alpine creates something like:

Content-Type: MULTIPART/MIXED; BOUNDARY="705298698-1667814148-1432049085=:28313"

and the only available part contains:

Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8
Content-Transfer-Encoding: 8BIT

Google tells me that the reason for this is:

Alpine uses a single part MULTIPART/MIXED to apply a protection wrapper around QUOTED-PRINTABLE and BASE64 content to prevent it from being corrupted by various mail delivery systems that append little (typically advertising) things at the end of the message.

Ok, this behavior might come from bad experiences and it seems to work most of the time. Unfortunately if one sends a signed email to a Debian list that checks whether the signature is valid (like for example debian-lts-announce), such an email will be rejected with:

Failed to understand the email or find a signature: UDFormatError:
Cannot handle multipart messages not of type multipart/signed


ntpd is rather good in ignoring

Notice to my future self: Recently I wondered why one of the computers doesn’t show the correct time. Among others, there are the following lines in /etc/ntp.conf:

interface ignore eth2
interface ignore eth3

As this computer doesn’t have eth2 and eth3 but only eth0, ntpd assumes that I want to ignore all network devices and just listens on lo. After removing those lines, everything is working fine. The version of the Debian ntp package is 1:4.2.6.p5+dfsg-2+deb7u1 and you can find the bugreport here.

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.