I have gone through many Mac OS upgrades with no issues. However, the upgrade to OS X Mavericks caused quite an issue. I lost the ability to use sync services to sync calendar and contact information with my iPhone. To gain this back, I would either have to use iCloud (not something I am willing to do) or put in my own iCloud-like service. There are several to choose from, including Baikal-Server, ownCloud, and even functionality that is part of my Synology device. I chose to go the route of ownCloud.
Here are the steps I followed:
Step 1: Set up a VM just for ownCloud
I first tried to use ownCloud on my Synology device, but it was just a little too slow for my tastes (which is apparently a common complaint about ownCloud on top of Synology). So instead, I created a RHEL 6.4 VM to run ownCloud within it.
Step 2: Download and install the community edition of ownCloud
The download and everything went smoothly, but the install is somewhat special. You use yum to install ownCloud, as this will install not only ownCloud, but also all the dependencies, such as PHP. Start your web server, and then point a browser at http://vm-ipaddress/owncloud to configure. The website will walk you through every step required to get ownCloud up and running.
Step 3: Enable Active Directory integration
For this to work, you need to first install the mod_ldap package via yum. Since I was installing additional packages, I went and installed mod_ssl as well. To finish the integration, you need to log in as the ownCloud admin, visit the Apps menu item in the upper right (as seen here to the left), and add the LDAP user and group backend app.
Once that is done, you need to visit the Admin menu item to configure LDAP for use with Active Directory. This can be a bit tricky, but there are clear and concise instructions all over the web for it. I made my settings match the following; note that the domain information has been removed to preserve security.
First, set up the LDAP Basic settings; the user login filter is the most important setting.
Second, set the Connection settings, nothing should change here.
Third, set the Directory Settings. Once more these should be filled in for you.
Fourth, set the Special Attributes. I had to add the sAMAccountName; without it, everything shows up as a UUID associated with Active Directory. Rather difficult to parse for the real users.
Lastly, set the expert elements. The crucial element is to ensure that these fields are blank.
Test your configuration, and then look at your user lists. All Active Directory users should show up. Interestingly enough, there is no need to use the domain name to log in, as LDAP integration already uses the domain name for you.
Step 4: Configure LDAP Users and set up sharing groups
Under the Users menu item, you can create groups for sharing data. This is incredibly important for those who need a shared calendar: families, for instance, or perhaps those who use shared space within an office, such as a meeting room. Sharing within a group allows many users to view the shared calendar and contacts. It is possible to allow every user to share with every other user, but utilizing groups helps with security issues.
Step 5: Set up CalDAV on OS X Mavericks, Linux, iPhone, etc.
Pick one device as the initial master. In my case, I chose OS X Mavericks. Using the OS X Calendar app, I exported my calendar. Now, set up a CalDAV server entry, but do not override your original calendar. Then, import the previously exported calendar into the CalDAV server. The calendar, even shared calendars within ownCloud, works flawlessly. Be sure to read the Mac OS/iOS-specific documentation, as URLs for CalDAV differ from other devices.
Set up sharing within ownCloud instead of subscribing to calendars, as you can then have one place for managing all sharing of calendars.
Step 6: Share calendars as needed
Sharing calendars is very useful for family calendars, shared work calendars such as those for meeting rooms, and the like. To share a calendar, the owner of the calendar clicks on the gear to open up an informational dialog and then clicks on the sharing icon. Once that is done, the owner specifies the group with which to share and exits the dialog (see below).
Step 7: Ensure calendars work as expected: test, and test some more
Test calendar updates by updating entries from your smart device, desktop, Linux, etc.: whatever you are using. We saw updates show up on all devices within thirty seconds of an update. This timing will depend on how often your device fetches data.
One thing to note: On my OS X Mavericks, I thought there was an Alarm issue with ownCloud, but the problem turned out to be the Do Not Disturb (DND) built into the OS X Mavericks Notification Center. If you mirror displays (as if you were presenting a slide show), DND disables notifications. Nice feature, but it caused me some issues.
Step 8: Set up CardDAV on OS X Mavericks, Linux, iPhone, etc.
First, export all your contacts from OS X Mavericks as a vCard (select all entries, then select Export). Next, import these into ownCloud’s contacts. I imported this way because the Address Book app with OS X Mavericks did not work. However, iPhone picked up the changes quickly. Note that the URL used for CardDAV, like the one for CalDAV, is different for each tool in use.
Step 9: Fixes for OS X Mavericks
Adding a CardDAV account to the Address Book for OS X Mavericks actually creates a system account. That account should be accessible at all times. However, when you attempt to click on it within the System Preferences -> Internet Accounts, it asks once more for the password you initially used to create it. This is due to the way Internet Accounts attempts to talk to a CardDAV server. It goes to the IP in question and looks for /.well-known/carddav instead of the address you originally used to connect to the account. In addition, it attempts to communicate over SSL regardless of how you specified the URL. So, we need to fix these items first:
- SSL: I installed mod_ssl already so all we need to do is add a certificate and configure SSL within Apache per normal means. I however make several additional changes to the ssl.conf file we edit for the purpose of adding SSL to Apache. I add the following to meet any necessary PCI requirements:
SSLProtocol -ALL +SSLv3 +TLSv1 SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:!RC4-MD5:!RC4-SHA:+HIGH:!MEDIUM RewriteEngine on RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] TraceEnable off- /.well-known: Create the necessary redirect so that OS X Mavericks Internet Accounts can login into ownCloud’s cardDAV application. You can add these into the /etc/httpd/conf/httpd.conf but I found it much easier to add them to the .htaccess file in the document root directory of the web server. Ensure, the web server can read the .htaccess file.
Redirect 301 /.well-known/carddav /owncloud/remote.php/carddav Redirect 301 /.well-known/caldav /owncloud/remote.php/caldavNow, the Internet Accounts logins just fine so you can modify items, however, ownCloud has an error 32: Broken-Pipe when attempting to read the contacts from the ownCloud server into the OS X Mavericks application. This was tracked down to a faulty ‘Expert’ of the LDAP setup. All Expert fields should be blank.
Unfortunately, while address books work perfectly for my iOS devices, they do not work as well for my OS X Mavericks laptop. Only one contact list is allowed, and that is the first by alphabetical order. So, if you have several address books that are shared, such as an organization phone book, it could override your personal contacts within OS X Mavericks address book. Which basically means that I need a better contact manager that also integrates with OS X Mavericks email, etc.
One key thing to remember is to always back up your data using the native export functionality of what you consider to be your master information source, and to always test everything, including updates, alarms, edits, etc. If you do both of these, then you will not lose any data, and you can ensure that the features you require for ownCloud (or your chosen cloud service) are available for your use.
Yet, my iOS 7 and other systems work just fine and as expected
Update: Just recently my OS X Mavericks email decided to hang, I traced this down to one more iCloud invasion on my system. I removed the following file after forcing Mail.app to quit: ~/Libary/Mail/V2/MailData/SyncedFilesInfo.plist. What is interesting is that I never enabled iCloud for email, so why was this there, telling Mail.app to use iCloud? iCloud is pervasive and if you do not use it but enable it for one item but not all you end up with quite a few artifacts.
