[CalendarServer-users] unable to install calendarserver

Emmanuel Bourreau ebourreau at nordnet.fr
Tue Feb 21 00:36:47 PST 2017

I haven’t seen that Rob Archibald had just replied to me and no to the list.
He gave me a solution with launchd which, as far as I’m concerned, works for me and does what I wanted. 
Here is my calendarserver.plist which is in my LaunchAgents folder

<?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">

It works on MacOS 10.11.6, with automatic login on my account.
Sorry for the time you have spent on this problem.
> Le 21 févr. 2017 à 02:44, Andre LaBranche <dre at apple.com> a écrit :
>> On Feb 18, 2017, at 12:57 AM, Emmanuel Bourreau <ebourreau at nordnet.fr <mailto:ebourreau at 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 <https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html#//apple_ref/doc/uid/10000172i-SW7-BCIEDDBJ> 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 <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> <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%3C/string%3E>
>     </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 <dre at apple.com <mailto:dre at 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 <ebourreau at 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 <ebourreau at 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 <dre at 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 <ebourreau at 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 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/20170221/be60627a/attachment-0001.html>

More information about the calendarserver-users mailing list