On Nov 29, 2013, at 2:52 PM, Andre LaBranche wrote: > > On Nov 29, 2013, at 5:15 AM, Scott Cherf <ch...@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. > > Hi, > > 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. >
All good tuff Andre, and I expect for very large installations it may be more efficient to work through the installation and configuration issues I've experienced with MacOS X Server over the past 5 years. My experience is based on managing a small business network of 2 servers and 5 client machines running 10.6.8. I began experimenting with the Server product with 10.4 and successively installed and tested versions through 10.6. I have no practical experience using later operating systems. None of my experimental installations were successful and in every case I rolled back to the retail product. My background is in IT and I began my career as a systems administrator using HP 1000 machines running both RTE (4 through 6) and BCS in a research lab environment (NASA's Gerard P. Kuiper Airborne Observatory). Since then I spent 12 years writing OS software for Tandem Computers, then took a position designing and implementing the software development environment for cisco Systems. I retired as Chair of cisco's Reliability, Availability and Serviceability Lab. I consider my IT background extensive. That said, I would rather use open source tools like your Calendar Server without the additional management overhead of MacOS X Server in my environment. I find the lack of documentation and poor user interface to be a drawback, along with some severe shortcomings in basic product functionality. I can't recommend it, and I hope I've at least qualified myself to have an educated opinion on the subject. Regards, Scott. > Just my two cents :) > -dre > >> >> Scott. >> >> On Nov 8, 2013, at 1:21 PM, Bernhard Spinnler wrote: >> >>> >>> On 07.11.2013, at 22:09, Olivier DUCROT <olivier.duc...@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@lists.macosforge.org >>> https://lists.macosforge.org/mailman/listinfo/calendarserver-users >> >> _______________________________________________ >> calendarserver-users mailing list >> calendarserver-users@lists.macosforge.org >> https://lists.macosforge.org/mailman/listinfo/calendarserver-users >
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
