MacPorts port of calendarserver
I've ported Apple Calendar and Contacts Server to MacPorts. See https://github.com/macports/macports-ports/pull/4978 This port is completely independent of Server.app, and uses an nginx reverse proxy for modern crypto and to isolate the backend server. I have it deployed and it’s working well. If anyone has specific comments or suggestions about how ccs-calendarserver is implemented in MacPorts (https://github.com/macports/macports-ports/pull/4978), your feedback would be most welcome. Specifically, these are known issues that could use some help: 1. ccs-calendarserver doesn’t have standard GNU-like DESTDIR or PREFIX capabilities for staged installs. See https://github.com/apple/ccs-calendarserver/issues/540, https://www.gnu.org/prep/standards/html_node/DESTDIR.html In my own tests, running `./bin/package -F ${DESTDIR}` hard codes the build directory within all the virtualenv compiled Python code and object libraries, and therefore does not work. Even hacky workarounds like creating symbolic links to `DESTDIR` and building within the symlinks don't work. This prevents the current MacPorts Portfile from being able to manage/delete/update all the files created with the ccs-calendarserver ./bin/package install command. 2. All local accounts have access to calendarserver's password using security find-generic-password -a calendarserver@${fullhost} -g This is a hack to provide twistedcaldav authentication access. See: https://github.com/apple/ccs-calendarserver/blob/master/twistedcaldav/util.p.... An alternate approach must be used if non-trusted local accounts exist on the Calendar and Contacts Server. 3. The exisiting Portfile implementation uses native macOS Python, not MacPorts Python. I haven’t been able to get ccs-calendarserver running with non-native Python, which is desirable/best-practice for a package-managed install. 4. The package ccs-calendarserver is written in Python 2.7, which will reach the end of its life on January 1st, 2020. A future version of pip will drop support for Python 2.7. It's not clear yet how macOS will handle Python 2.7 after its EOL. See https://github.com/apple/ccs-calendarserver/issues/537
On Aug 8, 2019, at 4:33 AM, Steven Smith <steve.t.smith@gmail.com> wrote:
This port is completely independent of Server.app, and uses an nginx reverse proxy for modern crypto and to isolate the backend server. I have it deployed and it’s working well.
What 'modern crypto' are you referring to? Twisted (upon which CalendarServer is based) ought to be able to get an A+ on SSLLabs and use all the most modern ciphersuites (including TLS 1.3). I'm not up on CalendarServer's configuration these days, but it should be possible to adjust it to be as fancy and modern as it needs to be... (I'm not sure what you mean by "isolating" the server?) -glyph
Thanks for your comments. For TLS and the reverse proxy, I’m referring to three things: 1. I do not see how to enable or configure TLSv1.2 or 1.3 in the ccs-calendarserver configuration code. See, for example, the default configuration plist and the associated Python code: <!-- SSL method: SSLv2_METHOD, SSLv3_METHOD, SSLv23_METHOD, or TLSv1_METHOD --> <key>SSLMethod</key> <string>SSLv23_METHOD</string> https://github.com/apple/ccs-calendarserver/blob/15561ced74a7a45cfffa0610201... 2. I do not see how to specify Diffie-Hellman parameters for PFS. A search through the code doesn’t yield any hits, and it doesn’t appear to be a configuration key: https://github.com/apple/ccs-calendarserver/search?q=dhparam&unscoped_q=dhpa... <https://github.com/apple/ccs-calendarserver/search?q=dhparam&unscoped_q=dhparam> 3. In my own Server.app version 3.7, Apache was used as a reverse proxy for Calendar and Contacts Server. I do not know what went into this design decision, but I inferred that this is related to configuring a central web server for Server.app that also provides the benefits of a reverse proxy. Because of the issues mentioned above, I configured an nginx reverse proxy for a MacPorts port of Calendar and Contacts Server. Here’s the nginx.conf: https://github.com/macports/macports-ports/pull/4978/files#diff-ec7e62c591a2... Yes, “isolate” is too strong for a reverse proxy (should say “help isolate”), but they do have several benefits, which may or may not also be a part of the ccs-calendarserver backend: mod_security, rate limiting, routing through a single exposed http/https port, and the like. I don’t know how to do any of this with the ccs-calendarserver code, but a lot of reasonable features like these are used in Server.app’s apache2 .conf files in its reverse proxy design. If there’s a way to configure ccs-calendarserver to use native twisted capabilities, that would be good to have a for simplified setup without using an nginx front-end. I also see that Twisted has already migrated to python3—ccs-calendarserver is still on Python 2.7 which is EOL in four months!—so python3 migration could be part of this. Should ccs-calendarserver’s Twisted TLS config be raised as an issue at https://github.com/apple/ccs-calendarserver/issues <https://github.com/apple/ccs-calendarserver/issues> ?
On Aug 8, 2019, at 11:31 PM, Glyph <glyph@twistedmatrix.com> wrote:
On Aug 8, 2019, at 4:33 AM, Steven Smith <steve.t.smith@gmail.com <mailto:steve.t.smith@gmail.com>> wrote:
This port is completely independent of Server.app, and uses an nginx reverse proxy for modern crypto and to isolate the backend server. I have it deployed and it’s working well.
What 'modern crypto' are you referring to? Twisted (upon which CalendarServer is based) ought to be able to get an A+ on SSLLabs and use all the most modern ciphersuites (including TLS 1.3). I'm not up on CalendarServer's configuration these days, but it should be possible to adjust it to be as fancy and modern as it needs to be...
(I'm not sure what you mean by "isolating" the server?)
-glyph
participants (2)
-
Glyph
-
Steven Smith