Closed macsrwe closed 5 years ago
Hi @macsrwe - for the specific case of migrating CalendarServer from macOS Server style to open source style, there is this: https://developer.apple.com/support/macos-server/macOS-Server-Service-Migration-Guide.pdf. After reading all the intro stuff starting on page 35 (and satisfying the pre-reqs, most notably the need for an out-of-band Postgres installation that matches the version included with macOS Server), the actual migration can either be executed manually or using a convenience script in the open source repo. To use the script, don't do the steps under "manual instructions" on page 37, and instead use the steps under "Instructions using the transition script:" on page 38. Even those simplified instructions are probably only suitable for users who are comfortable with Terminal. Be sure to have good backups before attempting any of this.
Deploying complex open source software such as CalendarServer that includes many discrete moving parts is challenging in part because there are so many variables beyond the scope of the package itself - things like host-level configuration, networking environment, and other potentially conflicting packages. Taking all these variables into account to arrive at a mostly automatic package that "just works" without requiring the user to understand at least some of the implementation details is quite a large task, because it requires the software to make lots of assumptions about the local configuration / environment / host, and also assumptions about the user's intent. Given the variety of supported platforms for (the open source distribution of) CalendarServer, that's basically a non-starter, I'm afraid. Even though the 'environmental' differences between average Macs running macOS Server are quite small compared to the expected differences across the constellation of all the supported platforms for CalendarServer, macOS Server still struggled to cope with those differences throughout its lifetime, and they were a reliable source of problems. The major feature of macOS Server (even prior to the removal of almost all the services) was simplicity - but that comes at the cost of lack of flexibility. Keeping the configuration as standard as possible, only varying in specific well-understood ways, was critical to have any reasonable hope of automatically maintaining everything, given that users aren't expected to know what's going on under the hood.
It sounds like I'm just making excuses, but really I'm just trying to explain why achieving an end-user experience anything close to what macOS Server aspires for - and with a vastly expanded list of supported systems - is just extremely difficult, and well beyond the resources available to this open source project. The silver lining is that all the relevant details are knowable, and all the relevant code is in this repo (with help from the other ccs-* repos also under github.com/apple). It takes significant skill to make sense of it all, but I guess that's better than a total black-box with no path forward.
Thanks. That's a pretty comprehensive porting document, and much more proof that the average user is well up the creek. I know I certainly don't want to deal with all that effort.
Ultimately, I decided the most straightforward way out of this hole was to leave my old Mini running elsewhere in the house, doing nothing but calendar duty. Perhaps it will buy me enough time for some entrepreneur to market a third-party calendar server for the Mac.
Much the same issue as #490 but now more urgent.
Apple gutted its calendar server in Mojave. They published a list of recommended replacements. This package is number 1 on the list.
People who need to replace their calendar servers are going to be coming here for a package they can deploy, not one they have to fork and develop.
I know you didn't paint this target on your own back, but it's there now. Can you at least put together a document telling people who aren't programmers how to get this package up and running? Preferably using their existing calendar data?
Thanks.