calendarserver-users

Download

calendarserver-users@lists.macosforge.org

March 2012

1 participants
2 discussions

Switching to 3.2? Features ?
by Fredrik Unger 10 Jul '12

10 Jul '12

Hi, I have been using version 2.4.dfsg-6 packaged by Debian. As CS is now 3.2 I figured I'd bite the bullet and upgrade. An update can not hurt.. :) As I understand one now needs a Postgres database instead of the file system attributes. What Features does 3.2 have ? How well does it run on a Debian system ? Is there any Debian packaging planned ? (Question belongs to the Debian maintainer, but maybe they are listening here as well.. ) Currently I run some calendars the "old" way with groups. (with a patch) How do I set up a group calendar in 3.2. I have LDAP users, and they are "memberof" different groups. User X and Y is member of group A. Currently I have a calendar named A which both user X and Y can use via LDAP group membership authentication. How is a "proper" setup for this in 3.2 ? X and Y have also their "private" calendars, so they have to keep 2 calendars manually in order, but that was OK for the beginning. There are not that many users. I am also interested in CardDAV functionality in the same manner. Private and group address books. Any linux and windows client suggestions ? Well I think that was the first questions, I might come back with more. Also I could try to help write up some of the information to improve documentation of the calendar server. Anything else to think about. Thanks, Fredrik Unger

2 1

Consistently getting memcache errors finding a directory
by Chris Cleeland 12 Mar '12

12 Mar '12

BACKGROUND: Debian 2.4 calendarserver package, upgraded from Debian 1.2. No user-initiated changes to the database of events, though that doesn't mean that the package installer didn't do something unbeknownst to me. One account with multiple calendars under it to achieve "sharing" Clients: iCal from Snow Leopard; calendar app from iOS 5.0.1 on iPhone 4S and iPad 2. SYMPTOM: calendars eventually fail to sync. The scenario is strange (they always are) but consistent. If I add an account to iCal/SNL, the account syncs all events over a period of time (there are several years worth of events). Once the initial sync is complete, I can add an event in one client, then refresh the others and see the new event in the others. I can also delete an event in one client, then refresh and see the effect. All is good. <Time goes on...maybe a few hours, maybe a day or two...and my wife complains that calendars are broken again> If I pop open the error.log, which I have fully cranked up to "debug" threshold, I will see, amongst many things, stuff like this (see original excerpt at http://www.milodesigns.com/~chris/caldav2.4memcache.log ): 2012-03-12 08:21:53-0500 [-] [caldav-8008] [-] [twistedcaldav.cache.MemcacheResponseCache#debug] hashing key for get: ('PROPFIND', '{DAV:}unauthenticated', '/principals/__uids__/212c90da-66c5-5aff-8e74-df7a2418773c/', '0', -2045049267) to '930e80ec74a58ff30214d9e18701eb71' 2012-03-12 08:21:53-0500 [-] [caldav-8008] [-] [twistedcaldav.cache.MemcacheResponseCache#debug] Checking cache for: '930e80ec74a58ff30214d9e18701eb71' 2012-03-12 08:21:53-0500 [-] [caldav-8008] [-] [twistedcaldav.memcachepool.MemCachePool#debug] Busied client: <twistedcaldav.memcachepool.PooledMemCacheProtocol instance at 0xa5999ac> 2012-03-12 08:21:53-0500 [-] [caldav-8008] [-] [twistedcaldav.memcachepool.MemCachePool#debug] Clients #free: 1, #busy: 1, #pending: 0, #queued: 0 2012-03-12 08:21:53-0500 [-] [caldav-8008] [PooledMemCacheProtocol,client] [twistedcaldav.memcachepool.MemCachePool#debug] Freed client: <twistedcaldav.memcachepool.PooledMemCacheProtocol instance at 0xa5999ac> 2012-03-12 08:21:53-0500 [-] [caldav-8008] [PooledMemCacheProtocol,client] [twistedcaldav.memcachepool.MemCachePool#debug] Clients #free: 2, #busy: 0, #pending: 0, #queued: 0 2012-03-12 08:21:53-0500 [-] [caldav-8008] [PooledMemCacheProtocol,client] [twistedcaldav.cache.MemcacheResponseCache#debug] Not in cache: '930e80ec74a58ff30214d9e18701eb71' 2012-03-12 08:21:53-0500 [-] [caldav-8008] [PooledMemCacheProtocol,client] [twistedcaldav.directory.principal#error] No principal found for UID: 212c90da-66c5-5aff-8e74-df7a2418773c Notice the last line, where it says that there is no principal for the UID. While that may well be true for memcached, the reality is that the UID it's trying to look up does, indeed, exist in the filesystem, as that is the UID for the one single user configured in the client. And, in fact, the server was able to find the UID for initial population. While I would love it if somebody would be able to tell me what's wrong and an easy fix, I've developed software far too long to think that's realistic :) What I *AM* hoping is that somebody could help me make sense of what those 7 lines from the log are telling me, so that maybe I can apply some logic and deduction to hunt down real problem. Some additional questions/observations: 1. This package uses memcached from another debian package, but it's the same version as that pulled down by calendarserver during the build. 2. I have installed the memcache command line tools, though they strangely don't seem to dump anything. 3. While I would dearly love to move to a later release, that's not a realistic option at the moment, especially since it's not clear that it would actually resolve my issue. 4. Are the data stores compatible between 1.2 and 2.4? Was there some sort of migration I was supposed to run? Thank you so much for any help, -cj -- Chris Cleeland

1 0