Tinkering with Raspberry (and other things)

OSX El Capitan 10.11.4 and the CardDav Bug

I have been moving my OwnCloud instance to another provider and while I was at it, I migrated to nextCloud. Everything worked fine on all my devices. Even the newly acquired Windows Surface Book did not have any problem with syncing my contacts and calendars.

Well, for the Macs running El Capitan, things are different. There is a well known bug with the way El Capitan handles the carddav-protocol and Apple has not been able or willing to fix it. There’s loads of information about this on the internet but with 10.11.4 these workarounds stopped working (at least for me). After spending 2 hours editing .htaccess files and trying every possible permutation of servername and path in the “Internet Accounts” panel on my machine, I finally found a solution.

First, you still need redirects. My NextCloud installer did add them to .htaccess on its own. If you are running NextCloud or Owncloud in a subdirectory of your domain just add a .htaccess file at the webroot directory. The following lines did the trick (assuming the cloud installation is in subdirectory “MYDIR”):

RewriteEngine on
  RewriteRule ^\.well-known/carddav /MYDIR/remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /MYDIR/remote.php/dav/ [R=301,L]

On to the System Settings -> Internet Accounts on the Mac.
Add an new CalDav-Account in the following manner:
Account Type: Advanced
Password: userpassword
Server Address:
Server Path: /MYDIR/remote.php/carddav/principals/USERNAME/
Port: 443
Use SSL: X

With these settings I was able to start the Contacts app and after a few seconds all my contacts appeared. If you open this account via the Contacts app’s Settings menu you will not see the Server Path you added in the above steps. Do not try to edit this path.


Mac OS – El Capitan bluetooth discoverabilty

I recently upgraded my Mid 2011 Mac Mini to El Capitan and had to discover that when Bluetooth was switched on, the machine stayed discoverable via Bluetooth. Living in the middle of a big city this is a gerat security risk. I just don’t want everybody in the neighborhood to be able to see my Mac.

There are numerous instructions on the internet on how to disable the bluetooth visiblity via terminal commands (e.g. at but none of that did work. So I decided on checking the alternatives. And succeeded, thus this blog post. Continue reading

Edit Source Code Remotely

Recently I caught myself juggling with 5 open terminal sessions simultaneously. Four windows were showing different source files from a project I am working on and the fifth terminal was the commandline from where I started compilation and ran the programs. This was really annoying because even on my 27″ monitor the terminal windows took all the space and I frequently had to change desktops and so on.

So the question arose: “Can’t this be done in a more efficent way?” Continue reading

1 Comment

Basics for Beginners (part 3 – SSH)

Welcome to the third part of what in reality is just a compilation of my notes…

My Raspberry is running “headless”. Most of the time. This means that no keyboard, mouse or display is attached to it. The only means of access is via a secured shell, SSH in short. I will not go into detail on how to activate SSH on the Raspberry, this is extensively described in every “First steps” guide I know. So from now on I will suppose that you have successfully logged into your Raspberry via SSH from a remote machine.

Continue reading

1 Comment

Basics for Beginners (part 2 – backup/restore)

The Basics for Beginners (part 1) got rather lengthy so I decided to split it into two three parts. In this second part it’s all about backup and accessing the Raspberry Pi via SSH.

At first I did not care about backing up the system. If something went wrong I just dumped a new and clean image onto my SD-card and started all over. With more and more bits and pieces coming together and (some of them) working out, I soon realized that it would be a good idea to regularly backup the things I had accomplished so far.
Remote access is another important thing. I am sure most of us have the Raspberry Pi running as a “headless” system, connecting to it via SSH from a shell. However, there is one drawback with SSH. It generates a key per IP address. Now I wanted to use just one IP for my Raspberry, no matter which SD-card was inserted. This usually goes not very well with SSH, as different systems (per SD-card) will result in different SSH-keys. Continue reading