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 <firstname.lastname@example.org>
Make sure to test this change by running the file manually:
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.
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.
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.
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…
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.