[CalendarServer-users] Basic understanding / questions setting up XML directory based users

Eric Rabinowitz eric.rabinowitz at gmail.com
Mon Jun 23 14:08:23 PDT 2008

Hi folks,
   this is an open set of questions.  Although I am a 25+ year veteran  
of writing device drivers and embedded systems, I am humbly Python  
illiterate so my questions are very basic and I apologize in  
advance.    After considerable time reading the documentation,  
magazine articles, newsgroups, our mail-list, playing with builds and  
installs of the caldav server I find myself with some very basic  
questions.   The answers might be helpful to start a FAQ/Quick Start  
guide.    I am trying to setup a home 'family network' of  
collaborative calendars for myself, wife and kids (fwiw: all osx  
10.5.3 using iCal).    I know others have done this, but that is just  
background...  I was able to get some calendars shared between iCal  
accounts using boilerplate described in the list.

I am using a hard-coded XML directory table in an accounts<xxx>.xml  
file referenced by my caldav<xxx>.plist

Some Basic Assumptions:

A) I understand that the caldav server runs independently of the  
Apache WebDav server extensions and it is not needed for calendar  
serving. The Caldav server also implements the essential elements of  
HTTP protocol so it cal also be perused by a web browser at it's  
appropriate ports (such as 8008).   Browsing the server can be helpful  
in debugging your setup.

B) the './run' command is issued by a regular user (ie:not root).   If  
root attempts to start caldav server then it will fail when calling  
memcached:  You will see occasional memcache errors fly by on the  
console if root starts the server.  I never saw this non-root  
restriction documented anywhere and I guess it was just 'assumed'.    
Perhaps I just 'assumed' that you should be root when installing a  
server application!  In any case, only non-root users can start the  
It is also useful to not run the server as a daemon (using -r or  
[nothing] instead of -d) so that you can see transaction messages and  
errors on your terminal....


1) What exactly is the story with the usage of GUID-based names using  
the XML directory structure?   I have had some accounts fail when  
connecting if I used GUID's in principal entries and some not fail.    
All of the original GUID-based example principals in the accounts- 
test.xml work fine but what is the proper, precise way to ADD a  
principal using a GUID?  I have seen suggestions on the list to remove  
GUID to get things working for troubled users but that does not  
explain if it is obsoleted.  Do I need to reset a database or cache  
when using GUID's?

2) If a __GUID__ is not referenced during the 1st run, the <xxx>/ 
twistedcaldav/test/data has /__UID__/ subdirectory generated.     Is  
this correct?   What are the tradeoffs for a small system to use UID  

3) Is there a proper way to initialize a new principal AFTER the  
initial run of caldav server (GUID+UID or UID-only) using xml coded  
directory entries?

4) I noticed that there were some '.db.sqlite' database files in the  
principle directories (under /<xxx>/twistedcaldav/test/data/).   Could  
someone please explain when these database files are initialized?    
Can they/should they be regenerated if needed?  Do I need to  
initialize a database when adding a user after the first start of the  
server when I use GUID-based principals?

5) Is the caldav server capable of receiving iCal 'publish'  
commands?   I was able to implement 'publish' using the Apache Webdav  
as a workaround, but what is the method under caldav to accept publish?

Sorry if this is all covered before,  I really did dig around and play  
a lot before posting.

Thanks for your help!


Eric Linn Rabinowitz
415.336.6938 mobile
512.494.4914  home/office


Eric Linn Rabinowitz
eric at panoramic.org
415.336.6938 mobile
512.494.4914  home/office


Eric Linn Rabinowitz
eric at panoramic.org
415.336.6938 mobile
512.494.4914  home/office


More information about the calendarserver-users mailing list