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


Owncloud – Good bye (for now)

Sorry I have been quite for a while, but real life starts to kick in. I changed from freelance projects to a permanent position and that leaves less time for tinkering. (Less home office, more work).

So what is this about discarding Owncloud?

As you may have read I used a Raspberry Pi with lighttpd and Owncloud to manage my own Caldav and Carddav server. This worked fine and reliable until some days ago. I suddenly could not ssh into my server any more and experienced random but numerous synchronization errors. Attaching a monitor and keyboard to check what had happened (never ever put a machine into a shelf in a way that you can’t easily attach a monitor/keyboard…) was the only way to access it.
The log files didn’t produce anything helpful so I checked for the ssh daemon (again: OK) and for better access opted to shut the machine down and do further investigations on my workbench. That was a great mistake…

After shutting down and rebooting all I got was a kernel panic, a corrupt file system and a non-working system. I tried to repair the filesystem on my Linux machine, using fsck. No success, the filesystem was damaged beyond repair. I took a new SD-card and copied a backup of my owncloud installation on it, to get my server up and running again. This worked. For exactly 9 hours. Then I had the exact same boot messages and the exact same corrupt filesystem.

I’m not giving up easily, so I took a third SD card (different manufacturer, different size, different speed class), did the backup thing again and, believe it or not, after one day this card’s filesystem has been corrupted, too.

At the moment I have no idea whatsoever, why my Raspberry Pi “eats” filesystems. On the other hand I need to have my contacts and appointments synced on a handful of devices, so I am in the need of a working caldav/carddav server. That is why I returned to Google. Yes, I know and I am not comfortable with that solution either. But until I have resolved that filesystem issue there seems to be no other way.

Funnily enough (no, not really), my second Raspberry Pi when running Owncloud with lighttpd is corrupting the filesystem at the same speed…

So I now suspect that something in my installation is issuing way too many read/write cycles that quickly “wear out” the SD card. I need to do some further testing on this but that is the only thing I can of think of as the cause.

If anyone of you has experienced the same filesystem corruptions on a Raspberry Pi that is supposed to be running 24/7 please use the comments section for tips and tricks or your findings. Perhaps together we may solve that issue.


Owncloud 6 + lighttpd 1.4.31 + Raspberry Pi (Wheezy)

This workaround patches lighttpd to “understand” the HTTP_PATCH method so Owncloud 6 can be used on a Raspberry Pi running Wheezy.

I am using a dedicated Raspberry Pi with Owncloud and lighttpd for my contatcs and calendar entries. This works fine with Android (with the cardDAVSync and calDAVSync apps) and out of the box with any iOS devices using caldav and carddav.

Recently I upgraded from Owncloud 5 to version 6, mostly because I wanted the new automatic birthday calendar feature. Then I realized that I was not able to change any entries. Creating and deleting entries worked fine, only updating/changing was affected. After some digging around I found an entry in the owncloud forums and a short remark in the installation instructions (for version 5. Not in the version 6 instructions…) reading:

Note for Lighttpd users on Debian stable (wheezy):
Recent versions of Owncloud make use of the HTTP PATCH feature, which was 
added to Lighttpd at version 1.4.32 while Debian stable only ships 1.4.31.
The patch is simple, however, and easy to integrate if you’re willing to 
build your own package.

There are instructions for patching lighttpd on Debian so I thought that this should work on the Raspberry Pi also. Well, it did not. I ended up with a completely screwed system and (even worse) an incompatible libc-version which made some more fiddling necessary. I cannot guarantee that I didn’t something wrong, but I found a workaround that is working flawlessly on my system.

This workaround involves some modifications to source files and building a debian install package. It also assumes that you have a working and properly configured lighttpd and Owncloud installation on your system! If you have never compiled/built software on a linux machine please be warned. I can not be held responsible if anything goes wrong and you end up with a non-working Raspberry Pi. That said, here’s what we are going to do:

  • make backups of all lighttpd configuration files
  • get the lighttpd 1.4.31 sources and patch them
  • build a .deb-package from the source
  • install patched lighttpd package over existing installation using dpkg
  • copy some missing files from saved backup to new locations

If you are still with me at this point, keep on reading… Continue reading

Errors on boot caused by keyboard…

I recently discovered a rather weird boot behaviour on my Raspberry. The filesystem check would return errors and then the filesystem has been mounted read-only. At first I suspected the SD card being defect and changed it for a new one, being glad that I had a backup. This didn’t do the trick. I had to dive deeper.

With the command “dmesg” you can get the current output of the kernel log, that is mostly the stuff you see on boot. So I did check the messages and found an error while checking the USB hub that is connected to my Raspberry. In fact the error was related to the keyboard that is attached. The messages read:

[   86.513145] input: USB USB Keykoard as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/input/input0
[   86.524201] hid-generic 0003:1A2C:0021.0001: input,hidraw0: USB HID v1.10 Keyboard [USB USB Keykoard] 
               on usb-bcm2708_usb-1.3.1/input0
[   96.524435] hid-generic 0003:1A2C:0021.0002: usb_submit_urb(ctrl) failed: -1
[   96.524473] hid-generic 0003:1A2C:0021.0002: timeout initializing reports
[   96.525204] input: USB USB Keykoard as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.1/input/input1
[   96.532824] hid-generic 0003:1A2C:0021.0002: input,hidraw1: USB HID v1.10 Device [USB USB Keykoard] 
               on usb-bcm2708_usb-1.3.1/input1

Obviously there was something going wrong with the keyboard. So I decided to remove the powered USB hub and connect the keyboard directly to the Raspberry. The error remained.

Booting without the keyboard attached went well, no filesystem errors an more. But as soon as I plug in the keyboard, the above error messages appear. I have yet no idea why, but the cheap keyboard I bought seems to have some serious comaptibility issues.

It is a noname, really cheap keyboard, the lsusb command does not even give a name, just the ID. So if you have a cheap keyboard and experience trouble on boot, check if the keyboard reports as

Bus 001 Device 006: ID 1a2c:0021

Lessons learned:

Don’t buy too cheap…