I was actually facing some strange issues: Using Mac OS X keychain access app and SSL/TLS client certificates (and other authentication items in keychain) in Chrome or Safari did not work. I saw the „allow“ or „always allow“ buttons; I could klick on them, but nothing happened. It was very strange. It was that strange that I did reset my login keychain – without any impact.

And also Google did not help – unless I stumbled today on a discussion at the Apple forums. There is a reference to a security update from Apple, which includes this change/fix:

SecurityAgent
Available for: OS X El Capitan 10.11
Impact: A malicious application can programmatically control keychain access prompts
Description: A method existed for applications to create synthetic clicks on keychain prompts. This was addressed by disabling synthetic clicks for keychain access windows.
CVE-ID
CVE-2015-5943

Which practically means that any tool that interferes with the input devices is not allowed to grant keychain access rights. So does MagicPrefs.

What a painful thingy – I was almost resetting my whole system from scratch (like the private and business MacBook Pro).

After all – it’s good to query such issues over and over again.

In my latest post I did mention the new setup and since I am a litte narcissistic I did tweet this post right away. And a good friend and fellow software craftsman Mark Paluch (@mp911de) instantly claimed the question about data protection (aka backup).

Over the years I did try out several simple backup systems (eg. backup-manager), but it never felt right.

Therefore I started to create some very simple script and by now I am still using it:

#!/bin/bash

SSHFS_MOUNT_SOURCE=sshfs-server.domain:/
SSHFS_MOUNT_TARGET=/mnt/local-backup-mount
BACKUP_PATH="${SSHFS_MOUNT_TARGET}/backup/"
BASE_PATH=/basepath-to-be-used
PUB_KEY_EMAIL=email@some.domain

sshfs "${SSHFS_MOUNT_SOURCE}" "${SSHFS_MOUNT_TARGET}"

cutoff=$(date -d '7 days ago' +"%s")

for BACKUP_ITEM in {all,sub,paths}; do
 TMP_TARGET="/tmp-storage/backup-${BACKUP_ITEM}-$(date +"%Y-%m-%d").tar.gz"
 GPG_TARGET="${TMP_TARGET}.gpg"
 tar -czf "${TMP_TARGET}" "${BASE_PATH}/${BACKUP_ITEM}"
 gpg -e -r "${PUB_KEY_EMAIL}" -o "${GPG_TARGET}" "${TMP_TARGET}"
 cp "${GPG_TARGET}" "${BACKUP_PATH}"

 cutoff=$(date -d '7 days ago' +"%s")

 find "${BACKUP_PATH}" -type f | while read fileName; do
 fileDate=$(echo $fileName | sed 's/.*-\([0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]\).*/\1/')
 fileDateInSeconds=$(date -d "${fileDate}" +%s)
 if [ ${fileDateInSeconds} -lt ${cutoff} ]; then
 rm ${fileName}
 fi
 done

 rm "${TMP_TARGET}" "${GPG_TARGET}"
done

umount "${SSHFS_MOUNT_TARGET}"

It works out quite nicely – but this is far from being a enterprise backup solution 😉

Some things happen for a reason. Last week there seemed to be one of those days: Root Server HDD crash.

But as the HDD got replaced and the system was usable again, I took this opportunity to start from scratch:

• Use Docker instead of plain LXC
• Use a Docker based email server
• Switch from Liferay to WordPress – once again Docker based
• Owncloud container

Some sites are not yet up an running, but I need to check if I still need them – as said, some things happen for a reason.

Next up: Use a NGINX based SSL proxy (obviously also Docker based) with Let’s Encrypt automated certificate creation.

Willkommen zur deutschen Version von WordPress. Dies ist der erste Beitrag. Du kannst ihn bearbeiten oder löschen. Und dann starte mit dem Schreiben!