Tag Archives: tip

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

*sigh*

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:

system_aliases:
  debug_print = "R: system_aliases for $local_part@$domain"
  driver = redirect
  domains = +local_domains
  allow_fail
  allow_defer
  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:

local_catchall:
  debug_print = "R: catchall for $local_part@$domain"
  driver = redirect
  domains = +local_domains
  allow_fail
  allow_defer
  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
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:

    CREATE DATABASE $DBNAME;
    \r $DBNAME
    GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER ON $DBNAME TO ‘$DBUSER’@’localhost’ IDENTIFIED BY ‘$DBPASS';
    GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER ON $DBNAME.* TO ‘$DBUSER’@’localhost’ IDENTIFIED BY $DBPASS';
    FLUSH PRIVILEGES;

  • 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.