Python error(s) /usr/sbin/update-apt-xapian-index

I recently switched /usr/bin/python on Debian 7 to use Python3.x instead of Python2.x. Unfortunately, this breaks /usr/sbin/update-apt-xapian-index which is run in the weekly cron:

  File "/usr/sbin/update-apt-xapian-index", line 86
    except OSError, e:
SyntaxError: invalid syntax
run-parts: /etc/cron.weekly/apt-xapian-index exited with return code 1

There’s an easy fix, though and it won’t require debugging the file… much. 🙂

Simply edit the first line of the file in /usr/sbin/ to use /usr/bin/python2.x (in my case /usr/bin/python2.7)

# -*- coding: utf-8 -*-

# update-apt-xapian-index – Maintain a system-wide Xapian index of Debian
# package information
# Copyright (C) 2007–2010 Enrico Zini <>

Make sure to test this change by running the file manually:

root@dietbrand:~# /usr/sbin/update-apt-xapian-index
Reading en translations from /var/lib/apt/lists/ftp.debian.org_debian_dists_wheezy_contrib_i18n_Translation-en: done.
Reading en translations from /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_non-free_i18n_Translation-en: done.
Reading en translations from /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_contrib_i18n_Translation-en: done.
Reading en translations from /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_main_i18n_Translation-en: done.
Reading en translations from /var/lib/apt/lists/ftp.debian.org_debian_dists_wheezy_non-free_i18n_Translation-en: done.
Reading en translations from /var/lib/apt/lists/ftp.debian.org_debian_dists_wheezy_main_i18n_Translation-en: done.
Rebuilding Xapian index: done.

Props to Martijn Pieters on Stackoverflow for the insight.

Nginx client certificates

I had this issue where the client (intermediate and root) certificates were not properly downloaded when viewing the site. In most if not all browsers, this is not an issue as they have most of these certificates on board. With the recent and future implementations of SHA-2 I thought it would be prudent to have it working correctly.

Apparently, ssl_client_certificate and ssl_trusted_certificate no longer work (for reasons I will probably never understand). Instead, you have to add your client certificates to your server certificate. The quickest way to do that on *Nix is using this simple command:

cat ca >> crt

Where ca is the file that stored the client certificates and crt is the file where you store your server certificate. Now all you need to do is comment or edit out the line in your config that said ssl_client_certificate or ssl_trusted_certificate and restart the Nginx webservice.



Byebye Google, hello …

Slowly but surely. That’s probably my motto right now. My beef with Google is slowly but surely increasing. Not only did they increase ranking in search results for sites using HTTPS (over it), they now launched a browser that’s punishing you for using encrypted (yet insecure) sites.

Gosh, I couldn’t care less!

I have quite a lot of credentials on encrypted local environments stored away in Chrome. Surprise surprise, these sites are NOT secured using a certificate. While I understand the Chrome product team’s reasons to deliver a secure and attentive browser, advanced users like myself have always been stuck in the same corner as well. My first gripe back when Chrome 5 launched was that highlighting a URL automatically included http:// when using copy. I sort of got over that but now they won’t let you use your stored credentials anymore? Without even giving us the chance to set exceptions? Queue the blood boiling in 3… 2… 1…

Continue reading “Byebye Google, hello …”

Well, I got hacked… (update!)

I’m still trying to find out how and where. It looks like either the theme got compromised, SQL injection or some other doohickey. If you see something curious like ads or links to filth, do let me know. Send a screenshot to me[.at.]dietbrand[.dot.]eu.

Now I know what I’m going to do this Saturday… 🙂

Challenge accepted hacker dickheads… Challenge accepted.

Update: I found it! The plugin “Share Buttons WP” by antonsps11 had some code injected into it. I found this by doing a find for files that were modified in the last 7 days.

# find . -type f -mtime -7

The welcome.txt file contained a list of IP’s. This probably randomized the chances of you seeing it or not.