Gpg Enigmail And Error Messages

I got a GPG encrypted mail, which should be a good thing since encryption and these things. But every time I use GPG something does not work. And every time the error messages are useless.

So the moral of this blog post is: If you are a developer write meaningful error messages.

A short overview what my setup is, I have a Fedora 22 with gpg2 and my default mail client is Thunderbird. And to use Thunderbird with GPG I use the Enigmail plugin which if it's working an okayish way to read and write encrypted mails.

What was my problem? Well if you read the error messages I guess something like you haven't imported your private key yet.

gpg: decryption failed: No secret key

Error - no matching private/secret key found to decrypt message

So I checked that with gpg -K and I see my key, I even extracted the encrypted part from the mail and decrypted it on the command line without a problem. Thanks to the Internet I was able to find other people with the same problem. And one of this posts gave me the right idea. By default there is no pinentry-program installed. After I installed one with sudo dnf install pinentry-qt4 and restarted my Thunderbird it can magically encrypt the message.

Jekyll Build From Github

You might or might not remember how I publish this blog with Github. But I wrote a post about this. Since I migrated my hosting to a VPS I changed a few things. The important bits that changed are, the way things get logged. Now I use tee which has the side effect that the output is on my logfiles and get printed to stdout which you can see then on you php update page (this helps to debug the build process). The other thing that changed is that on FreeBSD jekyll is installed in /usr/local/bin, which is not in the default path. This resulted in a blog which get no updates, because the jekyll binary is missing. That's why I added /usr/local/bin to the path, to fix this.

$ cat update.php
<?php
	$output = shell_exec('./update.sh');
	echo "<pre>$output</pre>"; 
?>

$ cat update.sh
#!/bin/sh
export PATH=$PATH:/usr/local/bin

#the logfile
datestr=$(date +%Y%m%d_%H%M%S)
LOGFILE=/usr/local/www/update_log/log_$datestr

#cd to your git repo
cd /usr/local/www/blog_git_src

#update ALL TEH SOURCE
echo git | tee -a $LOGFILE
git version | tee -a $LOGFILE
git pull origin master | tee -a $LOGFILE

#build page
echo jekyll | tee -a $LOGFILE
jekyll build -d /usr/local/www/blog | tee -a $LOGFILE

Jekyll Nginx Rewrite Rules

I use permalink: pretty which create for each post a folder with a index.html. This creates nice urls like this /2015/04/22/htaccess-proxy. But last time I cheked my error logs I saw a few peoples who tried urls like this: /2015/04/22/htaccess-proxy.html. So I thought why not redirect this urls. Of course I'm not the first person with this problem, I found two blog post on which I based my solution.

• vec.io/posts/jekyll-clean-urls-with-nginx
• rickharrison.me/how-to-remove-trailing-slashes-from-jekyll-urls-using-nginx

My solution:

server {
        listen       80;
        server_name  l33tsource.com www.l33tsource.com;

        rewrite ^/index.html$ / redirect;
        rewrite ^(/.+)/index.html$ $1 redirect;
    
        if ($request_uri ~* ".html") {
            rewrite (?i)^(.*)/(.*)\.html $1/$2 redirect;
        }

        location / {
            rewrite ^/(.*) /$1 break;
            proxy_pass http://blog;
        }
}

If you have any problems or find broken urls, just write me.

###Update

For some weird reason all these redirection foo doesn't work when the blog upstream not on port 80 is.

Htaccess Proxy

Lets say you have a web application bound to localhost. For example your ruby or python web project. The next logic step is to install nginx and setup a reverse proxy. If that's not an option and you need to use Apache and can not edit the Apache settings. There is a solution which I used for some time:

This assumes that your application run at port 886688.

RewriteEngine On
RewriteRule ^(.*) http://localhost:886688/$1 [P]

Probably not the best and cleanest solution but works for me!

I Accidentally Used Php

I try to avoid PHP software when ever possible. But sometimes the best tool for the job is written in PHP. One of these tools is observium which is a network monitoring platform. And I can really recommend it. But sadly it's written in PHP. That is why I accidentally start debugging PHP code one evening.

But first things first. I want to add my RaspberryPi, which is my primary DNS server, to observium. I click on add device fill out the snmp infos and woops "Could not resolve $host". My first thought was well I forgot something, after I double checked everything it was still not working. This was the point where I was annoyed enough to debug PHP code.

After poking around in the source code I found this:

dns_get_record($host, DNS_A + DNS_AAAA)

This was my first WTF moment, I mean seriously DNS_A + DNS_AAAA what should that do. A grep later with no result, it was clear that it must be a function of PHP. And look: it's in the manual. Turns out the way they implement it, allows to do addition and subtraction with these constants since there are internally bit masks or something. Which is a smart idea but of course you don't find this in the manual, it's only in a user comment below.

Anyway the manual states what dns_get_record should return:

This function returns an array of associative arrays, or FALSE on failure.

Doesn't sound entirely wrong. A empty array on a failure might come in handy, why I show you in a second.

var_dump(dns_get_record($host, DNS_A));


array(1) {
  [0]=>
  array(5) {
    ["host"]=>
    string(14) "host.name.tdl"
    ["class"]=>
    string(2) "IN"
    ["ttl"]=>
    int(0)
    ["type"]=>
    string(1) "A"
    ["ip"]=>
    string(12) "192.168.17.2"
  }
}

Like in the manual described a array is returned.

var_dump(dns_get_record($host, DNS_AAAA));

PHP Warning:  dns_get_record(): DNS Query failed in file.php on line 4
bool(false)

Like in the manual described it returns FALSE if the is no AAAA record found.

I guess at this point you can assume what happens when you combine these two requests.

var_dump(dns_get_record($host, DNS_A + DNS_AAAA));

PHP Warning:  dns_get_record(): DNS Query failed in file.php on line 4
bool(false)

It returns only FALSE in this case, even if there is a A record for this domain.

And the moral of this story

Deploy IPv6 everywhere to prevent this! Or maybe don't build software based on PHP. I personally recommend both things.

If you are a observium pro user it's fixed, according the mailing list in revision 6357 and
for everyone else with the next half yearly release.