Hi, I should have been more clear: the primary release vehicle for CalendarServer is Apple's "Server" product, with which CalendarServer can be deployed and maintained on macOS relatively easily.
Importantly, Server takes care of all the persistence and OS-specific environmental configuration, and does this in a way that couldn't really be achieved without also being the OS vendor. It's not hard to deploy a simple, traditional (complied executable) daemon on macOS via launchd, but when you've got layers of shell scripts leading to Python, using launchd (in an open source context) becomes difficult because launchd is opaque and unhelpful, in my opinion. I'm sure it is possible to achieve this, I guess I was just expressing some frustration that I spent all day on it and couldn't make it work. Given the option, I wouldn't choose to have that problem, opting instead for an environment more accommodating to server-oriented use cases, hence the recommendation. If your task is to make it work on a Mac, I didn't mean to discourage you (too much). It is possible, just find the flaw(s) in my process :) Production deployments I'm aware of have been on Oracle Linux and FreeBSD, but any good server OS should be fine. -dre > On Feb 20, 2017, at 6:20 PM, Rob Archibald <r...@robarchibald.com> wrote: > > Hmm, did you really say what I think you said? Isn't this built for MacOS? > >> I recommend not using macOS for running CalendarServer. Sorry. > > > If you don't recommend running it on MacOS, is there a platform you do > recommend running it on? What is the configuration you use when you load up > iCalendar Server (at least I assume that is the marketing name of this > product on the server since I found a PDF describing a product by that name > from Apple) in its standard configuration? > > Blessings, > Rob Archibald, M.M. > Founder and Music Director, Ensign Symphony & Chorus > musicdirec...@seattleensign.org > www.seattleensign.org > >> On Feb 20, 2017, at 5:44 PM, Andre LaBranche <d...@apple.com> wrote: >> >> >>> On Feb 18, 2017, at 12:57 AM, Emmanuel Bourreau <ebourr...@nordnet.fr> >>> wrote: >>> >>> Another question: >>> how can we use calendar server as a daemon on 10.11.6 ? >>> bin/run -d crashes but bin/run -n works. But the second one prevents my >>> computer to switch off automatically at the end of the day. >> >> bin/run isn't intended for installing or managing a service that people are >> actually using, it is just a developer convenience. Properly installing >> CalendarServer varies by platform, as does the recommended way to manage >> CalendarServer as a daemon. As you are on OS X, use a launchd plist to run >> the service as a daemon, something like: >> >> <far too much time passes as I try to make this work> >> >> This is actually really hard, or at least non-obvious, which is probably one >> of the reasons the documentation is so sparse. Some of the problems I've >> encountered along this path include: >> >> * you have to do the USE_OPENSSL=1 thing, because using keychain from a >> launchd daemon is a black art that shouldn't be attempted. >> >> * specifying a launchd job in the system domain (/Library/LaunchDaemons) >> configured to run as your personal account will likely not work. I can't get >> it to work, and I think it's due to something I don't know about launchd >> that's causing it to try to give the launched process access to my GUI >> session, or something. Specifying a user that is not logged in seems to work. >> >> * ./bin/package doesn't work on macOS. "/usr/bin/python2.7 -m virtualenv >> --system-site-packages --no-setuptools --always-copy ..." results in a bunch >> of permission denied errors. Removing the "--always-copy" option works >> around it, but I haven't thought through the possible implications. >> Ultimately this is caused by a macOS security feature called System >> Integrity Protection, which includes use of special file flags on >> apple-provides OS components. Some of these flags are not writable under >> normal circumstances, and shutil tries to preserve all flags, so it blows up. >> >> * After finally arriving at a ./bin/package'd installation at >> /Users/Shared/ccs, which I've chowned to the target user, I can't start it. >> Adding "set -x" to the top of bin/caldavd shows: >> exec /Users/Shared/ccs/bin/python '' --reactor=kqueue -n caldav -f >> /Users/Shared/ccs/conf/caldavd-dev.plist -o Twisted/reactor=kqueue >> /Users/Shared/ccs/bin/python: can't find '__main__' module in '' >> Eventually I realized this is because sourcing environment.sh (produced by >> ./bin/package) is not enough; one most also activate the virtualenv produced >> by ./bin/package (source virtualenv/bin/activate) prior to starting caldavd. >> >> * Since bin/package produces no configs, so as a test (read: do not do this >> for real, developing a config file takes time and effort), I just copied the >> 'conf' directory from the project root into the dest dir produced by >> bin/package. Copy caldavd-test.plist to caldavd-dev.plist. Fish >> twistedcaldav/test/data/server.pem out of the project directory and place it >> in your dest dir, and fix the path to server.pem in caldavd-dev.plist. Also >> create the 'data' directory at the top level of your dest dir. >> >> * Now it can, maybe, hopefully, actually start: >> >> /Users/Shared/ccs/bin/caldavd -X -R kqueue -f >> /Users/Shared/ccs/conf/caldavd-dev.plist -L >> >> Yes! works interactively. >> >> * But not via a launchd plist. It just exits with a status of '78' according >> to 'sudo launchctl list', which is not helpful. I have tried manually >> declaring PYTHONPATH and PATH as an environment var in the launchd.plist >> with what should be the right settings, but it still doesn't work. >> >> <?xml version="1.0" encoding="UTF-8"?> >> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" >> "http://www.apple.com/DTDs/PropertyList-1.0.dtd";> >> <plist version="1.0"> >> <dict> >> <key>Label</key> >> <string>com.dre.calendarserver</string> >> >> <key>EnvironmentVariables</key> >> <dict> >> <key>PATH</key> >> >> <string>/Users/Shared/ccs/bin:/Users/Shared/ccs/virtualenv/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string> >> <key>PYTHONPATH</key> >> >> <string>/Users/Shared/ccs/virtualenv/lib/python27.zip:/Users/Shared/ccs/virtualenv/lib/python2.7:/Users/Shared/ccs/virtualenv/lib/python2.7/plat-darwin:/Users/Shared/ccs/virtualenv/lib/python2.7/plat-mac:/Users/Shared/ccs/virtualenv/lib/python2.7/plat-mac/lib-scriptpackages:/Users/Shared/ccs/virtualenv/lib/python2.7/lib-tk:/Users/Shared/ccs/virtualenv/lib/python2.7/lib-old:/Users/Shared/ccs/virtualenv/lib/python2.7/lib-dynload:/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7:/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin:/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk:/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac:/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages:/Users/Shared/ccs/virtualenv/lib/python2.7/site-packages:/Users/Shared/ccs/virtualenv/src/twextpy:/Users/Shared/ccs/virtualenv/src/kerberos:/Users/Shared/ccs/virtualenv/src/pycalendar/src:/Users/Shared/ccs/virtualenv/src/caldavclientlibrary:/Users/Shared/ccs/virtualenv/src/caldavtester:/Users/Shared/ccs/virtualenv/lib/python2.7/site-packages/CalendarServer-9.1b1.dev0+a5933eaf63f5f3aef3b10949e70ecc0f5a49b736-py2.7.egg:/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python:/Users/Shared/ccs/virtualenv/lib/python2.7/site-packages:/Library/Python/2.7/site-packages://Library/Frameworks/UIAutomation.framework/Versions/A/lib/python:/AppleInternal/Library/Python/2.7/site-packages:/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC</string> >> </dict> >> >> <key>WorkingDirectory</key> >> <string>/Users/Shared/ccs</string> >> >> <key>ProgramArguments</key> >> <array> >> <string>/Users/Shared/ccs/bin/caldavd</string> >> <string>-X</string> >> <string>-R</string> >> <string>kqueue</string> >> <string>-f</string> >> <string>/Users/Shared/ccs/conf/caldavd-dev.plist</string> >> <string>-L</string> >> </array> >> >> <key>UserName</key> >> <string>calendarz</string> >> >> <key>GroupName</key> >> <string>calendarz</string> >> >> <key>KeepAlive</key> >> <true/> >> >> <key>SessionCreate</key> >> <false/> >> >> <key>StandardOutPath</key> >> <string>/tmp/ccs.log</string> >> >> <key>StandardErrorPath</key> >> <string>/tmp/ccs.log</string> >> >> </dict> >> </plist> >> >> I have tried using a wrapper script that sources environment.sh and >> activates the virtualenv, and specifying that as the only ProgramArgument, >> but that fails the same way. I give up for now, and possibly forever. I >> recommend not using macOS for running CalendarServer. Sorry. >> >> -dre >> >> >>> >>> Console says python crashes >>> >>> here is the two lines: >>> 18/02/2017 09:51:13,633 com.apple.xpc.launchd[1]: >>> (com.apple.ReportCrash[3618]) Endpoint has been activated through legacy >>> launch(3) APIs. Please switch to XPC or bootstrap_check_in(): >>> com.apple.ReportCrash >>> 18/02/2017 09:51:13,993 ReportCrash[3618]: Saved crash report for >>> python[3609] version 94 to >>> /Users/emmanuel/Library/Logs/DiagnosticReports/python_2017-02-18-095113_Mac-Pro-de-Emmanuel.crash >>> >>> Is it SIP ? >>> >>> Emmanuel >>>> Le 18 févr. 2017 à 02:05, Andre LaBranche <d...@apple.com> a écrit : >>>> >>>> Hi, >>>> >>>> I'm not sure why a reboot fixed it, unless that somehow included >>>> rebuilding memcached. This could also be related to environmental changes >>>> like installing the Xcode CLI Tools (which are recommended). Research >>>> indicates this problem is similar to things we've seen when using the >>>> latest xcode on 10.11.6 without the CLI tools installed. >>>> >>>> -dre >>>> >>>>> On Feb 17, 2017, at 8:10 AM, Emmanuel Bourreau <ebourr...@nordnet.fr> >>>>> wrote: >>>>> >>>>> Hello again, >>>>> I have restarted my computer and now it works. >>>>> Don’t know why… >>>>> Emmanuel >>>>>> Le 17 févr. 2017 à 11:08, Emmanuel Bourreau <ebourr...@nordnet.fr> a >>>>>> écrit : >>>>>> >>>>>> Hello >>>>>> as usual, you’re right ! >>>>>> But I have another problem >>>>>> After bin/run -n… >>>>>> >>>>>> Starting server... >>>>>> Reading configuration from file: >>>>>> /Users/emmanuel/CalendarServer2/master/conf/caldavd-dev.plist >>>>>> 2017-02-17T10:51:17+0100 [twistedcaldav.upgrade#info] Converting >>>>>> augments.xml >>>>>> 2017-02-17T10:51:17+0100 [twistedcaldav.upgrade#info] Converting >>>>>> augments.xml >>>>>> 2017-02-17T10:51:17+0100 >>>>>> [calendarserver.tap.caldav.CalDAVServiceMaker#info] Calendar and >>>>>> Contacts Server 9.1b1.dev0+7c50b666693493196e6c3df59811063ef7368d97 >>>>>> starting Combined process... >>>>>> 2017-02-17T10:51:17+0100 [twistedcaldav.localization#info] Looking for >>>>>> Apple .lproj directories in locales >>>>>> 2017-02-17T10:51:17+0100 >>>>>> [twisted.scripts._twistd_unix.UnixAppLogger#info] twistd 16.6.0 >>>>>> (/Users/emmanuel/CalendarServer2/master/.develop/virtualenv/bin/python >>>>>> 2.7.10) starting up. >>>>>> 2017-02-17T10:51:17+0100 >>>>>> [twisted.scripts._twistd_unix.UnixAppLogger#info] reactor class: >>>>>> twisted.internet.selectreactor.SelectReactor. >>>>>> 2017-02-17T10:51:17+0100 [-] AMPPushNotifierFactory starting on 62311 >>>>>> 2017-02-17T10:51:17+0100 [-] ControlSocket starting on >>>>>> './data/Logs/state/caldavd.sock' >>>>>> 2017-02-17T10:51:17+0100 [txdav.base.datastore.subpostgres#info] Cluster >>>>>> already exists at >>>>>> /Users/emmanuel/CalendarServer2/master/data/Data/Database/cluster >>>>>> 2017-02-17T10:51:17+0100 [txdav.base.datastore.subpostgres#info] >>>>>> Requesting postgres start via: >>>>>> ['/Users/emmanuel/CalendarServer2/master/.develop/roots/PostgreSQL/bin/pg_ctl', >>>>>> 'start', >>>>>> '--log=/Users/emmanuel/CalendarServer2/master/data/Logs/postgres.log', >>>>>> '--timeout=86400', '-w', '-o', "-c listen_addresses='' -c >>>>>> unix_socket_directories=/tmp/ccs_postgres_bfc609ea6b4ff8bf216572903d163531 >>>>>> -c shared_buffers=139 -c max_connections=93 -c >>>>>> standard_conforming_strings=on -c unix_socket_permissions=0770 -c >>>>>> log_line_prefix=%t"] >>>>>> 2017-02-17T10:51:17+0100 [memcached-Default] dyld: lazy symbol binding >>>>>> failed: Symbol not found: _clock_gettime >>>>>> 2017-02-17T10:51:17+0100 [memcached-Default] Referenced from: >>>>>> /Users/emmanuel/CalendarServer2/master/.develop/roots/libevent/lib/libevent-2.0.5.dylib >>>>>> (which was built for Mac OS X 10.12) >>>>>> 2017-02-17T10:51:17+0100 [memcached-Default] Expected in: >>>>>> /usr/lib/libSystem.B.dylib >>>>>> 2017-02-17T10:51:17+0100 [memcached-Default] dyld: Symbol not found: >>>>>> _clock_gettime >>>>>> 2017-02-17T10:51:17+0100 [memcached-Default] Referenced from: >>>>>> /Users/emmanuel/CalendarServer2/master/.develop/roots/libevent/lib/libevent-2.0.5.dylib >>>>>> (which was built for Mac OS X 10.12) >>>>>> 2017-02-17T10:51:17+0100 [memcached-Default] Expected in: >>>>>> /usr/lib/libSystem.B.dylib >>>>>> 2017-02-17T10:51:17+0100 >>>>>> [txdav.base.datastore.subpostgres.PostgresMonitor#info] waiting for >>>>>> server to start.... >>>>>> 2017-02-17T10:51:18+0100 >>>>>> [txdav.base.datastore.subpostgres.PostgresMonitor#info] stopped waiting >>>>>> 2017-02-17T10:51:18+0100 >>>>>> [txdav.base.datastore.subpostgres.PostgresMonitor#error] pg_ctl: could >>>>>> not start server >>>>>> 2017-02-17T10:51:18+0100 >>>>>> [txdav.base.datastore.subpostgres.PostgresMonitor#error] Examine the log >>>>>> output. >>>>>> 2017-02-17T10:51:18+0100 >>>>>> [txdav.base.datastore.subpostgres.PostgresMonitor#info] pg_ctl process >>>>>> ended with status=256 >>>>>> 2017-02-17T10:51:18+0100 >>>>>> [txdav.base.datastore.subpostgres.PostgresMonitor#error] Could not start >>>>>> postgres; see postgres.log >>>>>> 2017-02-17T10:51:18+0100 [txdav.base.datastore.subpostgres#critical] >>>>>> Can't start or connect to postgres: No such socket file: >>>>>> /tmp/ccs_postgres_bfc609ea6b4ff8bf216572903d163531/.s.PGSQL.5432 >>>>>> 2017-02-17T10:51:18+0100 [-] (UNIX Port ./data/Logs/state/caldavd.sock >>>>>> Closed) >>>>>> 2017-02-17T10:51:18+0100 [-] (TCP Port 62311 Closed) >>>>>> >>>>>> And the server doesn’t start. Or I think so, because i can’t connect >>>>>> with Safari on localhost:8008 or 8443. >>>>>> I remember I had same problem but can’t remember how i've solved it. >>>>>> Furthermore : Is it a good idea to use bin/run -n at each startup of my >>>>>> computer ? >>>>>> Thanks >>>>>> Emmanuel >>>>>> >>>>>>> Le 17 févr. 2017 à 03:33, Andre LaBranche <d...@apple.com> a écrit : >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Try deleting the "localhost" cert from your keychain (using >>>>>>> /Applications/Utilities/Keychain). I've seen this problem a few times >>>>>>> but am still not sure exactly how it happens - possibly CalendarServer >>>>>>> has lost access privs to a keychain item that was previously stashed >>>>>>> there. Deleting will allow new items to be created. >>>>>>> >>>>>>> Alternatively, you can delete the .develop directory then "export >>>>>>> USE_OPENSSL=1" and re-run bin/develop to disable use of >>>>>>> SecureTransport, which includes disabling the use of keychain to store >>>>>>> the server's private key. >>>>>>> >>>>>>> -dre >>>>>>> >>>>>>>> On Feb 16, 2017, at 3:30 PM, Emmanuel Bourreau <ebourr...@nordnet.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> during the bin/develop, i have the following error >>>>>>>> Keychain init. >>>>>>>> Could not find identity 'org.calendarserver.test' >>>>>>>> Found certificate 'localhost' >>>>>>>> Traceback (most recent call last): >>>>>>>> File "bin/keychain_init.py", line 164, in <module> >>>>>>>> identityCreate() >>>>>>>> File "bin/keychain_init.py", line 67, in identityCreate >>>>>>>> raise RuntimeError(error if error else output) >>>>>>>> RuntimeError: security: No matching identity found for "localhost" >>>>>>>> >>>>>>>> Next, if i try a « bin/run -n » >>>>>>>> i obtain >>>>>>>> The configured TLS Keychain Identity (Keychain: >>>>>>>> org.calendarserver.test) cannot be used: Unable to load Keychain >>>>>>>> identity: org.calendarserver.test >>>>>>>> >>>>>>>> System : 10.11.6 >>>>>>>> >>>>>>>> Calendarserver 9.1 >>>>>>>> >>>>>>>> Can you help me ? >>>>>>>> Thanks >>>>>>>> Emmanuel >>>>>>>> _______________________________________________ >>>>>>>> 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
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
