Domainfactory will selbst den Private Key für Kunden-Zertifikate erstellen (Update)

Ich komme aus dem Facepalmen nicht mehr heraus (Hervorhebung durch mich):

"Leider ist es bei dieser Erneuerung des Zertifikates aus technischen Gründen nicht möglich, ein von Ihnen erstelltes CSR zu verwenden.

Daher würden wir für Sie einen neuen CSR sowie einen neuen Private Key erstellen und beides für Sie im Kundenmenü hinterlegen. Nach der Ausstellung des Zertifikates würden Sie sowohl das Zertifikat als auch den Private Key über das Kundenmenü herunterladen können."

Das war die Antwort von DomainFactory, nach dem ich - wie im Blog angekündigt - aufgrund der durch Heartbleed potentiellen Kompromitierung ein neues SSL-Zertifikat zum Austausch beantragen wollte. Ich habe abgelehnt und gefragt, ob ich da gerade etwas falsch verstehe, das war vor zwei Tagen. Seit dem keine Reaktion mehr.

Wohl gemerkt, wir reden hier nicht von einem Wald-und-Wiesen-Zertifikat, sondern von einem EV-Zertifikat für knapp 240 EUR im Jahr.

Ich war mit DomainFactory eigentlich immer sehr zufrieden und habe sie oft empfohlen. Aber das hier zieht mir die Schuhe aus.

Update: Na bitte, kurz nachdem ich über Google+ domainfactory auf diesen Blogeintrag aufmerksam gemacht habe, wurde mir als Alternative vorgeschlagen, die Erneuerung direkt über ein Portal von Geotrust zu machen :-)

XBMC: Lautstärketasten wiederholen nicht

Wenn ich die Lautstärke in XBMC verändern will, muss ich bei meiner Hama MCE Remote für jede Stufe eneut drücken - sehr nervig. Das Problem ist offenbar, dass Linux hier intelligenter sein will als es sollte und die Wiederholungskommandos ausfiltert.

In einer Antwort in einem "WON'T FIX"-Bugreport (#14116 Kommentar 19) habe ich die Lösung gefunden. Es reicht, die Keycodes umzumappen.

Falls man sowieso ein eigenes Script einsetzt, um XBMC zu starten, dann kann man das auch direkt dort hinein bauen:

How to use ferm firewall rules on OpenWRT

OpenWRT has a very flexible Firewall configuration system, but for various reasons I want to use rules generated by ferm instead.

Use this howto on your own risk! I do not guarantee that it's free of errors! If you're not absolutly sure about something written here, or you don't know how to make backups of your router config and how to savely restore them: don't follow these instructions!

rsync's --fuzzy parameter: what is a 'similar named' file?

rsync has a parameter called '--fuzzy', which tries to find an equal or similar file within the same directory to diff against if the destination file is not found. For example, if you move or copy a file. It does this by first looking for a file having the same timestamp and the same size as the destination file. If this fails it tries to find a 'similar named' file as comparent. However, even if there are thousands of sources that tell you that the fuzzy option exists, I didn't find a single site explaining what a 'similar named' file actually is.

So I start to check rsync's source code to verify that my backup plan (one new archive file each day, which is rsync'd to another host) will work as intended. I want that rsync transfers the newest archive based on the previous file.

The starting point is the function find_fuzzy(..) in generator.c. The first part does the timestamp and filesize based check, which is not of any interest for me since both will always differ in my archives.

After that, it does the following (pseudo-code here):

initialize LOWEST_DISTANCE with 25
for each other FILE within the same directory do:
    calculate DISTANCE as 
        fuzzy_distance(FILE.name, INPUTFILE.name) + fuzzy_distance(FILE.suffix, INPUTFILE.suffix)
    if DISTANCE is lower or equal to LOWEST_DISTANCE then:
        set LOWEST_DISTANCE to DISTANCE
        remember FILE
return last remembered FILE

According to util.c fuzzy_distance(..) is based one the Levenshtein Distance.

Conclusion (or TL;DR)

rsync's --fuzzy algorithm will choose the file with the lowest Levenshtein Distance of it's name and it's suffix name. If there are multiple files with the same resulting value (which might happened on timestamp'ed named archive files) the last one will be taken. So, my backup plan should work as intended in most cases, but not in all. For example, it will choose the archive '2013-12-10' when transfering the backup of '2013-12-11'. However, on '2014-01-01' it might decide for '2013-12-01' instead of '2013-12-31' or even '2013-01-01', which is completly wrong. This means that I should choose another naming schema to avoid unnecessary traffic.

Alternative approach: Put the archive in directories named by the date and called "current.tar" and "parent.tar", where "parent.tar" is a hardlink to the previous "current.tar". In conjunction with --hard-links this should work, since the Levenshtein Distance of "current.tar" and "parent.tar" is below 25 (actually it is 3). Of course, source and target filesystems have to support hardlinks, and you must ensure that "parent.tar" is transmitted before "current.tar".

Pages