January 2017 - calendarserver-users

Controlling log level 9.0
by Dirk-Willem van Gulik 29 May '17

29 May '17

How does one control the loglevel on 9.0: With:  <key>DefaultLogLevel</key> <string>warn</string> <!-- debug, info, warn, error —> The log is still showing (after memcache purge & restart): 2017-01-13T16:07:53+0000 [twext.enterprise.adbapi2#debug] ConnectionPool: txn free 'jobqueue.workCheck': free=1, busy=0, waiting=0 And secondly - can LogLevels be used to control this in a more grannular fashion ? I had hoped that <key>LogLevels</key> <dict> <key>twext.enterprise.adbapi2</key> <string>error</string> </dict> would do the trick - but no dice sofar. Dw.

3 3

Check Availability - iPhone or Web clients?
by Ian Baker 23 Jan '17

23 Jan '17

We are running Server.app 5.2 on macOS 10.11.5. In the Mac based Calendar client there is a ‘Check Availability’ button that can be used to verify the schedule of an invitee for their free time. Is there any way to ‘Check availability’ of an invitee using the iOS Calendar app? Is is possible to do so with Server.app’s web client, and if not, are there any other web based calendar clients that are known to provide this functionality? Thanks in advance Ian

2 2

24->63 upgrade
by Dirk-Willem van Gulik 13 Jan '17

13 Jan '17

On a recent py27-calendarserver-9.0 (freebsd ports) should one expect caldavd to auto upgrade a 24 -> 63 (postgress backend) database ? A cursory glance at the code suggest this - but I see: 017-01-12T17:11:27+0000 [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Beginning database schema check. 2017-01-12T17:11:27+0000 [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Required database key VERSION: 63. 2017-01-12T17:11:27+0000 [twext.enterprise.adbapi2#debug] ConnectionPool: txn busy 'UpgradeDatabaseCoreStep.getVersions': free=0, busy=1, waiting=0 2017-01-12T17:11:27+0000 [twext.enterprise.adbapi2#debug] ConnectionPool: txn free 'UpgradeDatabaseCoreStep.getVersions': free=1, busy=0, waiting=0 2017-01-12T17:11:27+0000 [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Actual database key VERSION: 24. 2017-01-12T17:11:27+0000 [calendarserver.tap.caldav#error] Data store not available; shutting down and unfortunately calendarserver_upgrade Seems mired with some circular dependencies in this version: Traceback (most recent call last): File "/usr/local/bin/calendarserver_upgrade", line 11, in <module> load_entry_point('CalendarServer==9.0', 'console_scripts', 'calendarserver_upgrade')() ... File "/usr/local/lib/python2.7/site-packages/calendarserver/tap/util.py", line 38, in <module> from calendarserver.tools.util import checkDirectory Any advice appreciated, Dw

2 2

9.0 upgrade -- sharing/groups
by Dirk-Willem van Gulik 13 Jan '17

13 Jan '17

I am trying to debug why groups/shared calendars seem to have gone AWOL on 9.0 — working with a stock install with the sample files only lightly edited. With the sample test/admin pair accounts.xml (http://pastebin.com/RQ9b3RV0 for full version): > <record type="user"> > <uid>AEFBD20D-D975-11E6-9FB8-C86000BC390D</uid> > ... > <full-name>Super User</full-name> > </record> > <record type="user"> > <uid>AEFBD20D-D975-11E6-9FB8-C86000BC390E</uid> > ... > <full-name>Test User</full-name> > </record> > <record type="group”> > ... > <full-name>Group 01</full-name> > <member-uid>AEFBD20D-D975-11E6-9FB8-C86000BC390D</member-uid> > <member-uid>AEFBD20D-D975-11E6-9FB8-C86000BC390E</member-uid> > </record> I nicely see a group01 with the right group members (http://pastebin.com/KBiMRQ5f for full version): > • Group members: > • -> (<RecordType=user>)AEFBD20D-D975-11E6-9FB8-C86000BC390D - Super User > • -> (<RecordType=user>)AEFBD20D-D975-11E6-9FB8-C86000BC390E - Test User > • > • Group memberships: > • '() > • but nothing in the reverse- the membership() of the users (http://pastebin.com/4me8Dv2L for full version): > • Group members: > • '() > • > • Group memberships: > • ‘() Is it not fair to assume that members() and membership() are each others inverse ? Or am I barking up the wrong tree here. Dw

1 0

endless loop on resources/locations
by Dirk-Willem van Gulik 13 Jan '17

13 Jan '17

Trying to get a 9.0 instance ready for migration; taking the stock example files (ignoring the ones in the distribution with obviously wrong GUIDs); I see the server hang the second I add (full file: http://pastebin.com/ZQCYqdAb) > <key>ResourceService</key> > <dict> > <key>Enabled</key> > <true/> > <key>type</key> > <string>xml</string> > <key>params</key> > <dict> > <key>xmlFile</key> > <string>/usr/local/etc/caldavd/resources/locations-resources.xml</string> > <key>recordTypes</key> > <array> > <string>locations</string> > <string>resources</string> > </array> > </dict> > </dict> below in — just after the more or less identical entry for accounts.xml. location-resources.xml is taking from samples — albeit with the GUIDs modernized to actual UUIDs. > <?xml version="1.0"?> > <directory realm="Test Realm"> > <record type="location"> > <short-name>location%02d</short-name> > <guid>A8022A2A-D355-40A2-BC60-D7F123661B4A</guid> > <uid>location%02d</uid> > <full-name>Room %02d</full-name> > </record> > <record type="resource"> > <short-name>resource%02d</short-name> > <guid>B8022A2A-D355-40A2-BC60-D7F123661B4A</guid> > <uid>resource%02d</uid> > <full-name>Resource %02d</full-name> > </record> > </directory> The server hangs during startup; just after 2017-01-13T12:38:06+0000 [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseOtherStep#warn] Beginning database other upgrades check. 2017-01-13T12:38:06+0000 [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseOtherStep#warn] No dropbox migration - managed attachments not enabled 2017-01-13T12:38:06+0000 [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseOtherStep#warn] Database other upgrades check complete. And prior to to listening to inbound http request. Does that ring a bell with anyone ? Stock freebsd-11, 9.0 form ports. Dw.

1 0

calendarserver_upgrade failing oddly
by Joe Malcolm 03 Jan '17

03 Jan '17

I am attempting to install calendarserver-9.0 as an upgrade to 5.x on FreeBSD. I am using the FreeBSD port. Starting caldavd gets me a string of output that includes: 2016-12-23T22:03:34+0000 [twext.enterprise.adbapi2#debug] ConnectionPool: txn free 'UpgradeAcquireLockStep.stepWithResult': free=1, busy=0, waiting=0 2016-12-23T22:03:34+0000 [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Beginning database schema check. 2016-12-23T22:03:34+0000 [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Required database key VERSION: 63. 2016-12-23T22:03:34+0000 [twext.enterprise.adbapi2#debug] ConnectionPool: txn busy 'UpgradeDatabaseCoreStep.getVersions': free=0, busy=1, waiting=0 2016-12-23T22:03:34+0000 [twext.enterprise.adbapi2#debug] ConnectionPool: txn free 'UpgradeDatabaseCoreStep.getVersions': free=1, busy=0, waiting=0 2016-12-23T22:03:34+0000 [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Actual database key VERSION: 24. 2016-12-23T22:03:34+0000 [calendarserver.tap.caldav#error] Data store not available; shutting down So, fair enough. Then running calendarserver_upgrade gets me a traceback as follows: root@cal:/usr/local/etc/caldavd # calendarserver_upgrade -f /usr/local/etc/caldavd/caldavd.plist Traceback (most recent call last): File "/usr/local/bin/calendarserver_upgrade", line 11, in <module> load_entry_point('CalendarServer==9.0', 'console_scripts', 'calendarserver_upgrade')() File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 565, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2631, in load_entry_point return ep.load() File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2291, in load return self.resolve() File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2297, in resolve module = __import__(self.module_name, fromlist=['__name__'], level=0) File "/usr/local/lib/python2.7/site-packages/calendarserver/tools/upgrade.py", line 27, in <module> from txdav.common.datastore.sql import CommonDataStore File "/usr/local/lib/python2.7/site-packages/txdav/common/datastore/sql.py", line 85, in <module> from calendarserver.tools.util import displayNameForCollection, getEventDetails, agoString File "/usr/local/lib/python2.7/site-packages/calendarserver/tools/util.py", line 38, in <module> from twistedcaldav.stdconfig import DEFAULT_CONFIG_FILE File "/usr/local/lib/python2.7/site-packages/twistedcaldav/stdconfig.py", line 1854, in <module> config.update() File "/usr/local/lib/python2.7/site-packages/twistedcaldav/config.py", line 262, in update hook(self._data, reloading=reloading) File "/usr/local/lib/python2.7/site-packages/twistedcaldav/stdconfig.py", line 1478, in _postUpdateResourceService from twistedcaldav.upgrade import upgradeResourcesXML File "/usr/local/lib/python2.7/site-packages/twistedcaldav/upgrade.py", line 67, in <module> from calendarserver.tap.util import getRootResource, FakeRequest File "/usr/local/lib/python2.7/site-packages/calendarserver/tap/util.py", line 38, in <module> from calendarserver.tools.util import checkDirectory ImportError: cannot import name checkDirectory So, pardon my Python ineptitude, but as the file /usr/local/lib/python2.7/site-packages/calendarserver/tools/util.py is present and is identical to the distribution, this error is pretty confusing to me. Can anyone toss me a clue? Thanks, Joe

1 1

Monitoring CalendarServer
by Gaurav Jain 01 Jan '17

01 Jan '17

Hello, Thank you for creating calendarServer. I have a question. I run custom deployment of CalendarServer on AWS EC2 instance. It runs various processes like memcached, postGres and worker threads. What is most ideal way of monitoring these processes? For eg. I want to have an alert if CalendarServer is not working as expected. Or there is a process crash etc. Please provide pointers? Best Regards, Gaurav Jain

1 0