June 2009 - calendarserver-dev - lists.macosforge.org

[CalendarServer] #286: ./run script have Perl run-time dependency.
by CalendarServer 13 Sep '09

13 Sep '09

#286: ./run script have Perl run-time dependency. ------------------------------+--------------------------------------------- Reporter: bland(a)bbnest.net | Owner: wsanchez(a)apple.com Type: Enhancement | Status: new Priority: 4: Nice to have | Milestone: Component: Calendar Server | Version: trunk Severity: Other | Keywords: ------------------------------+--------------------------------------------- ./run script uses xpath utility to fetch values out of caldavd.plist. This utility is Perl based and adds excessive dependency to CalendarServer bundle. It will be nice to switchover to PyXML inline code instead. -- Ticket URL: <https://trac.calendarserver.org/ticket/286> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

UIDs as ATTENDEE IDs, please fix that
by Helge Heß 01 Jul '09

01 Jul '09

Hi, CalServer switched to use URNs/UIDs as ATTENDEE identifies. I think thats a really BIG mistake, I feel very strongly about it ;-) and would like to see that behaviour modified. Currently: ATTENDEE;X-CALENDARSERVER-EMAIL=abc@def.de:urn:uid:29838484... should be ATTENDEE;X-CALENDARSERVER-UID=29838484:mailto:abc@def.de or even ATTENDEE;X-CALENDARSERVER-UID=29838484:tel:+49-12234-233 Why? There are two big reasons: a) Interoperability. I would claim that all iCalendar clients use mailto ids today. Plus plenty of other iCalendar infrastructure. Changing this will result in interop issues and breaks a lot of stuff for (IMO) no good reason. b) The URN is completely opaque/proprietary to the client. It can't possibly resolve a URN to a contact database or other things which relate to attendees. This results in bad user experience and cross app integration at multiple levels. Note that my suggestion still includes a server specific UID which can be used for a stable resolution - as long as clients preserve it. And if not, its still sufficient for the far majority of real world deployments (reassigning email addresses is a no go, don't understand why people even consider that :-). Cyrus claims that this is not viable because clients throw away X- attributes. Does iCal do that? I think Kontact, Evo, Moz are all preserving such (we certainly do). Note: I'm fine with emitting URNs for stuff which can't possibly be resolved. Resources or locations _might_ be in that category, though I would still prefer an LDAP URL (+ UID X attr) if they are backed by something like OD. This still gives the client a way to learn about the ATTENDEE. Thanks a lot, Helge -- Helge Hess http://helgehess.eu/

3 13

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP directory service
by CalendarServer 29 Jun '09

29 Jun '09

#260: OpenLDAP directory service ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: wsanchez@… Type: Feature | Status: new Priority: 3: Important | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by wsanchez@…): Leopard iCal required OpenDirectory for attendee lookups and proxies ("delegates"). Snow Leopard iCal will do this via DAv to the calendar server, which means it should work with all the directory plugins. -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:24> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP directory service
by CalendarServer 29 Jun '09

29 Jun '09

#260: OpenLDAP directory service ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: wsanchez@… Type: Feature | Status: new Priority: 3: Important | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by oxullo@…): Ok, therefore is more sane to get focused on the proxies' client-side definition. The reason why this mechanism does not work with iCal and its convenient "Manage access to my account" interface is still due to failing lookups of the user on the directory, is that right? And with no opendirectory serving the lookups there is no way to add proxies with iCal, still right? thanks for the suggestion -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:23> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP directory service (was: OpenLDAP)
by CalendarServer 29 Jun '09

29 Jun '09

#260: OpenLDAP directory service ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: wsanchez@… Type: Feature | Status: new Priority: 3: Important | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by wsanchez@…): Replying to [comment:21 oxullo@…]: > Opendirectory interface, as well XMLDirectory one, allows to create proxies via configuration among resources/locations and users or groups. Note that in trunk, we are moving proxy management out of the directory. -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:22> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP
by CalendarServer 29 Jun '09

29 Jun '09

#260: OpenLDAP ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: wsanchez@… Type: Feature | Status: new Priority: 3: Important | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by oxullo@…): Just as a quick suggestion for whoever may be interested to use delegation with Aymeric's patch. As delegation works with proxies and due to the fact that they can be specified by client side, there is a simple way to add them using CalDAVClientLibrary, as described briefly here [http://www.mail- archive.com/calendarserver-users@lists.macosforge.org/msg00798.html 1]. Opendirectory interface, as well XMLDirectory one, allows to create proxies via configuration among resources/locations and users or groups. It would be nice to have the same behavior for LDAPDirectory, but I'm struggling with schemas (how to specify such linkage?). Any suggestion is welcomed! 1. http://www.mail-archive.com/calendarserver- users(a)lists.macosforge.org/msg00798.html -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:21> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Syntax Error in caldavxml.py line 97
by Thomas 26 Jun '09

26 Jun '09

dear all, I build the DCS on a Linux CentOS machine running python 2.5.1 x86_64 everything compiled fine, but when i tried to start the server, i do get the following syntax error: ========= Output of run =============================== Starting server... exec python /root/CalDEV/Twisted/bin/twistd -n caldav -f /root/CalDEV/CalendarServer/conf/caldavd-dev.plist -o ProcessType=Combined Traceback (most recent call last): File "/root/CalDEV/Twisted/bin/twistd", line 19, in ? run() File "/root/CalDEV/Twisted/twisted/scripts/twistd.py", line 27, in run app.run(runApp, ServerOptions) File "/root/CalDEV/Twisted/twisted/application/app.py", line 689, in run config.parseOptions() File "/root/CalDEV/Twisted/twisted/application/app.py", line 669, in parseOptions usage.Options.parseOptions(self, options) File "/root/CalDEV/Twisted/twisted/python/usage.py", line 226, in parseOptions for (cmd, short, parser, doc) in self.subCommands: File "/root/CalDEV/Twisted/twisted/application/app.py", line 680, in subCommands self.loadedPlugins[plug.tapname] = plug File "/root/CalDEV/CalendarServer/twisted/plugins/caldav.py", line 13, in getProperty return getattr(reflect.namedClass(self.serviceMakerClass), propname) File "/root/CalDEV/Twisted/twisted/python/reflect.py", line 349, in namedObject module = namedModule('.'.join(classSplit[:-1])) File "/root/CalDEV/Twisted/twisted/python/reflect.py", line 337, in namedModule topLevel = __import__(name) File "/root/CalDEV/CalendarServer/twistedcaldav/__init__.py", line 45, in ? import twistedcaldav.caldavxml File "/root/CalDEV/CalendarServer/twistedcaldav/caldavxml.py", line 97 self.start = parse_date_or_datetime(attributes["start"]) if "start" in attributes else None ^ SyntaxError: invalid syntax ======================================================= Thanking you very much in advance for helping me best regards, Malcom

2 2

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP
by CalendarServer 26 Jun '09

26 Jun '09

#260: OpenLDAP ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: wsanchez@… Type: Feature | Status: new Priority: 3: Important | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by oxullo@…): Dear Aymeric,[[br]] thanks to the suggestion, I've successfully implemented groups, based on groupOfNames schema. I think that the configuration is fine, at least with these assumptions: 1. the 'attr' key of every rdnSchema entries has to be the rdn of the element (wasn't so implicit to me!) 2. locations and resources don't work unless few lines are added to the method that create LDAP->principal mappings (patch follows) This patch is a lame way to have a quick working support for resources and locations. If there is no need at all for code redundancy (dunno if check against cn is enough), the branch can be integrated with the group's one. {{{ --- ldapdirectory.py.orig 2009-06-26 19:54:12.000000000 +0200 +++ ldapdirectory.py 2009-06-26 19:54:44.000000000 +0200 @@ -165,6 +165,12 @@ fullName = self._getUniqueLdapAttribute(attrs, 'cn') calendarUserAddresses = emailAddresses enabledForCalendaring = True + elif (recordType == DirectoryService.recordType_resources or + recordType == DirectoryService.recordType_locations): + shortName = self._getUniqueLdapAttribute(attrs, 'cn') + fullName = self._getUniqueLdapAttribute(attrs, 'cn') + calendarUserAddresses = emailAddresses + enabledForCalendaring = True return LdapDirectoryRecord( service = self, }}} Can you kindly suggest an example LDIF so we can refer ourselves to a specific and suggested schema? Right now I'm using: * context containers (groups, locations, resources, users): ''organizationalUnit'' * users: ''inetOrgPerson'' + ''simpleSecurityObject'' * groups: ''groupOfNames'' * resources: ''device'' * locations: (suggestions? why ''room'' 's cn is "commonName"?) Then, I gave a quick look to attendees support, which seems to be broken. Probably due to a missing email'S 'mailto:' specification for a fully qualified url. I will give a look to that tomorrow. Finally, about delegates: this is the mechanism which allows one principal to have access to another principal. Right now, for instance and on a XMLDirectory instance, I have two locations and one resource configured as delegates to a group. Every person on this group can add each location and resource's calendar at ease and with no other credential set. I wish that is worthy for someone to get this snippet published here as a template (avoiding pydict to plist boring mapping): {{{ <key>DirectoryService</key> <dict> <key>type</key> <string>twistedcaldav.directory.ldapdirectory.LdapDirectoryService</string> <key>params</key> <dict> <key>credentials</key> <dict> <key>dn</key> <string>cn=admin,dc=example,dc=com</string> <key>password</key> <string>secretWord</string> </dict> <key>groupSchema</key> <dict> <key>membersAttr</key> <string>member</string> <key>memberIdAttr</key> <string></string> </dict> <key>rdnSchema</key> <dict> <key>base</key> <string>dc=example,dc=com</string> <key>users</key> <dict> <key>rdn</key> <string>ou=users</string> <key>attr</key> <string>cn</string> <key>emailSuffix</key> <string></string> </dict> <key>groups</key> <dict> <key>rdn</key> <string>ou=groups</string> <key>attr</key> <string>cn</string> <key>emailSuffix</key> <string></string> </dict> <key>resources</key> <dict> <key>rdn</key> <string>ou=resources</string> <key>attr</key> <string>cn</string> <key>emailSuffix</key> <string></string> </dict> <key>locations</key> <dict> <key>rdn</key> <string>ou=locations</string> <key>attr</key> <string>cn</string> <key>emailSuffix</key> <string></string> </dict> </dict> </dict> </dict> }}} -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:20> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP
by CalendarServer 26 Jun '09

26 Jun '09

#260: OpenLDAP ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: wsanchez@… Type: Feature | Status: new Priority: 3: Important | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by aymeric.augustin@…): You're right about the lack of documentation of my patch. Non-obvious configuration options should be documented, at least. Groups are supported "flexibly". Here is how. * If you don't use NIS groups, group records have member fields giving the dn of each user belonging to the group. This is the default configuration : {{{ <key>groupSchema</key>  <dict> <key>membersAttr</key> <string>member</string> <key>memberIdAttr</key> <string></string> </dict> }}} * If you use NIS groups, group records have memberUid fields giving the uid of each user belonging the group. The dn of the user can be rebuilt with the information in the rdnSchema section of the configuration. {{{ <key>groupSchema</key>  <dict> <key>membersAttr</key> <string>memberUid</string> <key>memberIdAttr</key> <string>uid</string> </dict> }}} * Other representations could probably be mapped to one of these two. Delegates are not supported, I'm not even sure what they are. The configuration may be too generic and too flexible. However the defaults work out of the box. Do you have an opinion on this matter? -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:19> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP
by CalendarServer 26 Jun '09

26 Jun '09

#260: OpenLDAP ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: wsanchez@… Type: Feature | Status: new Priority: 3: Important | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by oxullo@…): I'd like to add some lines about my personal experience trying to make OpenLDAP work with DCS. First of all, thanks to Aymeric and Brandon for their proposals. I tried both suggestions, with these objectives: * To integrate iCal and TB+Lightning 1.0pre in a calendar system, using an OpenLDAP directory to hold user's data * To have attendees' lookups work with both iCal and TB+L * To reduce the complexity of users' schema (quite naive implication, but relevant to the fact that there are no tools, at least known to me, to easily maintain directory's data) As reported in many forums ([http://discussions.apple.com/thread.jspa?messageID=9201124 1], [http://www.zimbra.com/forums/isync-caldav/14812-ical-attendee-lookup- using-zimbra-directory.html 2], [http://forums.kerio.com/index.php?t=msg&goto=51672 3], [http://discussions.apple.com/message.jspa?messageID=9469770 4]) iCal lookup troubles are caused by the lack of some information on which iCal rely, in order to set a proper scoping relating calendar server with server's users. 1. Brandon Evans' package Finely documented installation process (wiki page here: [http://wiki.expertmx.com/doku.php?id=applecalendarserver 5]). This suggestion seems to be the most integrated solution for iCal's requirements. However, I could not make it work: no explicit errors, but calendars placeholders are not automatically generated on document root's structure, so I end up with principals with no default calendar. I can provide more details to whom is interested. Moreover, my concern is: whenever this solution works, how am I supposed to maintain it platform independently? Resource info, service locators et cetera.. 2. Aymeric Augustin's patch Completely undocumented, but quite straightforward and at least simple solution for RFC2307 integration. I could make it work (at least with no groups, nor delegates) but clearly no lookup support for iCal. In this specific situation I peeked into iCal<>LDAP communication. Lookup request is performed with the correct filter and data are returned, but iCal simply discard them. TB+L lookups are damned easy and they work out of the box. Relatively to iCal, it seems to me that the easiest way to fix this problem is to break the need of iCal to filter out contacts with high level metadata. Isn't possible just to configure this behavior? Another thing that shakes me is that lookup for local groups works [http://discussions.apple.com/message.jspa?messageID=9469770 4]. I don't really want to end up to maintain a fake group list on each company's Mac! 1. http://discussions.apple.com/thread.jspa?messageID=9201124 2. http://www.zimbra.com/forums/isync-caldav/14812-ical-attendee-lookup- using-zimbra-directory.html 3. http://forums.kerio.com/index.php?t=msg&goto=51672 4. http://discussions.apple.com/message.jspa?messageID=9469770 5. http://wiki.expertmx.com/doku.php?id=applecalendarserver -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:18> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0