[CalendarServer-users] Running CalendarServer on Mac OS X 10.8.5

Andre LaBranche dre at apple.com
Fri Nov 29 14:52:42 PST 2013

On Nov 29, 2013, at 5:15 AM, Scott Cherf <cherf at ambient-light.com> wrote:

> Bernard, I strongly suggest sticking with the Calendar Server you have and avoiding MacOS X Server at all expense. At the very least, take a look at some of the critical commentary available for the Server product. I tried that route myself when I became frustrated by some installation issues I was experiencing with CalanderServer and wasted several weeks. I would not recommend attempting to install the Apple Server product; in my experience it does not work at all.


It might be useful to qualify this a little. While I don’t doubt your experience, I can’t help but feel like there’s an implied “… for my purposes” at the end of your last sentence. I can confirm that OS X Server and the Calendar & Contacts service therein does actually work for many purposes - but not all purposes :)

Based on my fair amount of sysadmin experience, I will assert that running a server ‘for real’ is going to involve some amount work. By ‘for real’, I mean:
the service is actually used by real humans other than yourself, whose numbers may be increasing or decreasing, and whose usage patterns may change.
those humans use the service to create data which they care about. don’t lose, break, or leak this data.
the service needs to be up, always and forever, notwithstanding planned outages for things like upgrades / migrations / end-of-life.
I’m not aware of any vendor’s non-hosted solution for any service fitting these criteria that doesn’t require the operator to wear a sysadmin hat, at least sometimes. If any of those criteria don’t fully apply, it gets much, much easier. I assume they must all fully apply.

That’s all rather vague, so here are some specific questions I think about when I’m evaluating options for deploying any solution that is at least partially vendor-supplied:
What’s the startup cost in time and money? How much needs to be built / configured versus acquired ready-to-use?
What are the different high-level components of the service - the moving parts? This is basically the list of things that can break.
Where is the demarcation line between things the operator is responsible for fixing and things the vendor is responsible for fixing? What’s the expected level of service for vendor fixes?
Who owns the responsibility for monitoring, troubleshooting, maintenance, performance / scalability testing? For things the operator is responsible for, what tools are available?
With the answers to the above in-hand, how much operator knowledge is needed to achieve success in a worst / average / best-case scenario, without relying on luck? What are the means for sourcing that knowledge?
Do all involved parties understand and agree on all of these points?
There are multiple continuums at play, and making a solid decision requires understanding the tradeoffs involved in each.

Just my two cents :)

> Scott.
> On Nov 8, 2013, at 1:21 PM, Bernhard Spinnler wrote:
>> On 07.11.2013, at 22:09, Olivier DUCROT <olivier.ducrot at easymac.fr> wrote:
>>> Why don't you simply install Server 2.2 from AppStore. It's worth the price. $20 and one click install..
>> Yes, that's certainly a good option. However, I thought, since I do not need any other parts of the server right now and the CalDAV/CardDAC server is probably similar or even identical, I try the open source solution. Thanks for the suggestion.
>> Cheers,
>> 	Bernhard
>> _______________________________________________
>> calendarserver-users mailing list
>> calendarserver-users at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/calendarserver-users
> _______________________________________________
> calendarserver-users mailing list
> calendarserver-users at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/calendarserver-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/calendarserver-users/attachments/20131129/73e37f44/attachment.html>

More information about the calendarserver-users mailing list