April 2008 - calendarserver-dev - lists.macosforge.org

[PATCH] Name Service Switch (NSS) based directory service
by Guido Günther 06 May '08

06 May '08

Hi, I finally got bored of synchronizing accounts.xml with the other user and group databases, so I stitched together a simple NSS based user and group lookup directory service that simply uses the users and groups known to the system. You can set a prefix for groups and ranges for uids/gids to make sure system/admin users/groups don't end up having calendars. There's no location and resource handling yet although we could handle this too, but a proper LDAP interface might be more appropriate in that case. This directory service is not doing any authentication since everybody is doing Kerboeros anyways nowadays, so have fun! Pam would be possible to stich in too - but you'll have to hack up python-pam a bit which isn't worth it - so better get your KDC now! This was tested on Linux but should work on any unix based system. I'd be happy to adjust for other OSes if there are problems. The first patch adds the directory service itself while the second adds the defaults to twistedcaldav.config. Use: twistedcaldav.directory.nss.NssDirectoryService as DirectoryService and have a look at twistedcaldav.directory.nss for the available options. The patche are at Ticket #271 in trac: http://trac.macosforge.org/projects/calendarserver/ticket/271 Cheers, -- Guido

2 1

Darwin Calendar Server
by Tony Rogers 30 Apr '08

30 Apr '08

Hello, I just joined the list. I probably don't have much to offer in terms of developing the Calendar Server, but maybe I could help with documentation or some code gruntwork (fixing formatting, renaming stuff, etc.). About me: * 24-year-old student @ University of Maryland * Started with HTML+CSS in 2001, slowly moved into programming with PHP and a little Java o XHTML/CSS is my strongest skill o Followed by PHP, then Java; I tend to understand object-oriented stuff better, but I imagine I might be able to do some simple stuff in Python if assigned gruntwork * Lately interested in XML+XSL; I also play around with DocBook 5 (XML, not SGML), and I've gotten pretty comfortable with the basics. I can create/edit DocBook and output to XHTML pretty well, and my comfort level with CSS allows me to aim for "best practices" in terms of output markup with pretty good accuracy * I'm sometimes right-brained, sometimes left-brained; I love programming, but I'm somewhat bad at Calculus; I love creative work, but I get bored with a diet of 100% artsy stuff. I find the most satisfying work is work that has creative + technical work in relative balance, like the Yin & Yang. :) Let me know if there's anything I can do to help! I would love to help out such a great project if I can. -- Tony

1 0

Finding the principals by LDAP/OD
by Pascal Robert 23 Apr '08

23 Apr '08

Hello, I'm trying to find the principals location by JNDI, and I'm reading this: http://trac.calendarserver.org/projects/calendarserver/browser/CalendarServ… 312395FC-363A-44D5- BA5D-98B178D5CD43:CFD9E112-9CC3-4AB7-97A6-3951C61ECECB:calendar \----------------------------------/ \----------------------------------/ \------/ Computer Record GUID Virtual Host GUID Service name The Services Locator is used to allow the calendar server given a virtual host from the Virtual Host Plist to find all the records that have calendars provisioned on that server. It is also used to allow iCal given a user record to find the following information: I'm looking at the OD schema and I did find the Computer Record GUID, but I don't finbd the Virtual Host GUI anywhere in my schema. And for computer GUI, I have 3 CN records, which one should I use ?

1 0

[bug] Invisible imported recurring events
by Łukasz Langa 15 Apr '08

15 Apr '08

Hello. First post, sorry for breaking any list rules (in particular I wasn't sure what list does this belong to). I've successfully set up DCS on Fedora 7 (on March, 25th) using the trunk checkout. It's working fine, I have a couple of users set up using the XML accounts file. Yesterday I encountered a strange problem, though. It seems that importing calendar entries to the server in iCal makes the imported events invisible (they are physically on the server but when synchronising the calendar with another iCal instance, they are not being added). To reproduce: - create a new calendar on the server - in iCal import the attached .ics file to this freshly created calendar - in the DCS logs we see that all events are added 83.20.190.7 - ambv [08/Apr/2008:15:20:16 +0200] "PUT /calendars/ __uids__/ambv/3B643D7C-F36A-4F8A-A160-A7048532DBC4/A9F0C104-9C28-42BC- A6F5-354FA9BAA59D.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [160.8 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:16 +0200] "PUT /calendars/__uids__/ambv/3B643D7C-F36A-4F8A-A160- A7048532DBC4/1E31130F-4AC6-4FF1-A32F-F6270EF5335C.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [126.1 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:16 +0200] "PUT /calendars/__uids__/ambv/ 3B643D7C-F36A-4F8A-A160-A7048532DBC4/D82FCEE8-6295-42DF-A4C6- B57A2A318B06.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [140.6 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:17 +0200] "PUT /calendars/__uids__/ambv/3B643D7C-F36A-4F8A-A160- A7048532DBC4/0DF0F511-ADBA-4080-8CB8-39AF26327D2C.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [161.1 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:17 +0200] "PUT /calendars/__uids__/ambv/ 3B643D7C-F36A-4F8A-A160-A7048532DBC4/1E8D9BE0-7D11-4C84- BA02-3ACC26A41BC9.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [124.6 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:17 +0200] "PUT /calendars/__uids__/ambv/3B643D7C-F36A-4F8A-A160- A7048532DBC4/57766EE1-178B-41E8-89A2-1E72547934A5.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [138.2 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:17 +0200] "PUT /calendars/__uids__/ambv/ 3B643D7C-F36A-4F8A-A160-A7048532DBC4/C25E9C14-C56E-45F2- AF11-8153FBA1B117.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [100.7 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:17 +0200] "PUT /calendars/__uids__/ambv/3B643D7C-F36A-4F8A-A160- A7048532DBC4/24D3D83C-D6CD-4E70-AAE3-A4A72DE1189D.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [142.8 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:18 +0200] "PUT /calendars/__uids__/ambv/ 3B643D7C-F36A-4F8A-A160-A7048532DBC4/FB0660DC-A627-4626-B280- FCE12D6254D4.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [152.9 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:18 +0200] "PUT /calendars/__uids__/ambv/3B643D7C-F36A-4F8A-A160- A7048532DBC4/02D40F09-80DE-41EA-A4EE-0BF9F462B33A.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [170.8 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:18 +0200] "PUT /calendars/__uids__/ambv/ 3B643D7C-F36A-4F8A-A160-A7048532DBC4/FFBE7FFB-FA2B-42F9-A9E6- E25C7545189F.ics HTTP/1.1" 201 0 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [110.4 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:18 +0200] "PUT /calendars/__uids__/ambv/3B643D7C-F36A-4F8A-A160-A7048532DBC4/ A87A2B4F-566D-4943-BA24-F71A992F26B1.ics HTTP/1.1" 201 0 "-" "DAVKit/ 2.0 (10.5.2; wrbt) iCal 3.0.2" [147.4 ms] - try to synchronize this calendar from another iCal instance. In the DCS logs we see that iCal successfully PROPFINDs this calendar and REPORTs for changes 83.20.190.7 - ambv [08/Apr/2008:15:20:35 +0200] "PROPFIND /calendars/ __uids__/ambv/3B643D7C-F36A-4F8A-A160-A7048532DBC4/ HTTP/1.1" 207 833 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [41.7 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:35 +0200] "PROPFIND /calendars/ __uids__/ambv/3B643D7C-F36A-4F8A-A160-A7048532DBC4/ HTTP/1.1" 207 7963 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [118.8 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:35 +0200] "REPORT /calendars/ __uids__/ambv/3B643D7C-F36A-4F8A-A160-A7048532DBC4/ HTTP/1.1" 207 17707 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [286.4 ms] 83.20.190.7 - ambv [08/Apr/2008:15:20:36 +0200] "PROPFIND /calendars/ __uids__/ambv/inbox/ HTTP/1.1" 207 499 "-" "DAVKit/2.0 (10.5.2; wrbt) iCal 3.0.2" [40.1 ms] - no events show up in the client -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/

2 3

Re: [CalendarServer-dev] [bug] Invisible imported recurring events
by Łukasz Langa 08 Apr '08

08 Apr '08

Wiadomość napisana w dniu 2008-04-08, o godz 16:31, przez Michael Rasmussen: > On Tue, 8 Apr 2008 16:17:57 +0200 > Łukasz Langa <lukasz(a)langa.pl> wrote: > >> >> Please try to use the .ics file I attached in the first message and >> try this for yourself. >> > I dont have Polish locale so I cannot confirm whether the text is > ISO-8859-2 or UTF-8. CalDAV only supports ISO-646(ISO-8859-1) and > UTF-8. Could it be that the client locale is ISO-8859-2? No, the locale is UTF-8 and the data is properly stored on the server- side. -- Pozdrawiam serdecznie, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/

2 2

Write Locks and Unmapped URLs
by Michael Rasmussen 07 Apr '08

07 Apr '08

Hi again, According to RFC4918 (June 2007) Adding a calendar resource could cause a lost-update so clients are advised to use on of the following scheme: 1) If lock is supported request a lock on and Unmapped URL 2) If lock is not supported use the header If-None-Match (RFC2616) As I see it using If-None-Match header is more flexible and requires less from both client and server. My question is then: Are there any added benefit from using a Lock on and Unmapped URL if the server supports locking or should I use If-None-Match header anyway? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Use uniform input formats. - The Elements of Programming Style (Kernighan & Plaugher)

3 3

Fw: [CalendarServer-dev] LOCK: What is supported?
by Michael Rasmussen 07 Apr '08

07 Apr '08

Sorry, again, again. Should have been to the list Begin forwarded message: Date: Mon, 7 Apr 2008 21:59:02 +0200 From: Michael Rasmussen <mir(a)datanom.net> To: Cyrus Daboo <cdaboo(a)apple.com> Subject: Re: [CalendarServer-dev] LOCK: What is supported? Hi Cyrus, On Mon, 07 Apr 2008 15:45:26 -0400 Cyrus Daboo <cdaboo(a)apple.com> wrote: > > No. We are being naughty in advertising support for LOCK when we > don't actually implement it. I think that was done because there was > some dav client that would not work properly without LOCK being > advertised even though it did not use LOCK. > Or expression wishes for the future:-) It no big deal at the moment though, but my implementation which is supposed to be incorporated in Claws-Mail is aiming for support for shared calendars so locking sure makes live more easy. > We do have a ticket open to support LOCK. However, its not a big > priority item as it does not seem like many clients to date have > tried to make use of it (though of course that could be because its > not supported - however I've not heard from client developers who > expressed an interest in wanting it). > Could I be allowed to express a small request for implementing that? I would be a cull feature to announce support for shared calenders. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Avoid temporary variables. - The Elements of Programming Style (Kernighan & Plaugher) -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Forrest Gump: "Stupid is as stupid does"

1 1

Fw: [CalendarServer-dev] Write Locks and Unmapped URLs
by Michael Rasmussen 07 Apr '08

07 Apr '08

Sorry, again, again. Should have been to the list Begin forwarded message: Date: Mon, 7 Apr 2008 22:04:51 +0200 From: Michael Rasmussen <mir(a)datanom.net> To: Cyrus Daboo <cdaboo(a)apple.com> Subject: Re: [CalendarServer-dev] Write Locks and Unmapped URLs On Mon, 07 Apr 2008 15:59:42 -0400 Cyrus Daboo <cdaboo(a)apple.com> wrote: > > If-None-Match is probably best right now. I think LOCK is more useful > when you need to make multiple updates and ensure those are > consistent. > I was under the same impression. Locking is actually only beneficial for adding in the cases where you are required to uphold ACID. As this is not really an issue for the present use of CalDAV I see no purpose of making things more complicated. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Chicken Little was right. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Forrest Gump: "Stupid is as stupid does"

1 0

LOCK: What is supported?
by Michael Rasmussen 07 Apr '08

07 Apr '08

Hi all, I small question. ICalender server announces support for LOCK and UNLOCK but requesting even a simple lock like this: <?xml version=\"1.0\" encoding=\"utf-8\" ?> <D:lockinfo xmlns:D=\"DAV:\"> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockinfo> Gives this response: <html> <head> <title>501 Not Implemented</title> </head> <body> <h1>Not Implemented</h1> Some functionality requested is not implemented on this server. </body> </html> Anything wrong with the lock request? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- printk("NULL POINTER IDIOT\n"); linux-2.6.6/drivers/media/dvb/dvb-core/dvb_filter.c

2 1

Fw: [CalendarServer-dev] Bug related to Example 7.8.6 in the RFC
by Michael Rasmussen 04 Apr '08

04 Apr '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, should have been to the list. Begin forwarded message: Date: Fri, 4 Apr 2008 15:52:34 +0200 From: Michael Rasmussen <mir(a)datanom.net> To: Helge Heß <me(a)helgehess.eu> Subject: Re: [CalendarServer-dev] Bug related to Example 7.8.6 in the RFC - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Helge, On Fri, 4 Apr 2008 01:53:12 +0200 Helge Heß <me(a)helgehess.eu> wrote: > > I have the impression that you use the term 'collection' a bit > inappropriately. Well, collection was used as an "abstract class":-) > A (WebDAV) 'collection' does not have an etag (it can have a ctag, > but thats Apple specific, not CalDAV). > It can also have an ics resource representation which then can have > an etag (when you query it using GET, but this is not really CalDAV > or collection related). > I no. The main idea is this: 1) I want to be able to retrieve any resource related to a specific ACL for the shake of been able to share calendar resources in a generic way. 2) A VEVENT is not required to store information about its specific ICal resource, but following the CalDAV specification any VEVENT is required to store its UID which must be unique. 3) Having a specific VEVENT means access to its unique UID by which it is possible to get the associated ETag with this specific iCal resource. 4) According to the CalDAV specification the ETag is required to be able to modify and/or delete an iCal resource. > Just use > <C:text-match>20080404t182145z-123401(a)example.com</C:text-match> > for now (per spec this will default to "i;ascii-casemap"). > Yes, of course:-) Thanks. > > I guess this didn't come up before because clients usually query > servers by URL, not by UID. Which I personally prefer anyways (why > do you use the UID in the first place?). > As explained above. You cannot be certain that you know the URL. Many clients store the specific resource name and combining this with the URL to the collection, you have the URL. You can be certain that you know the UID since by specification any resource must save it in a guarantied unique manor. - - -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 - - -------------------------------------------------------------- Debian Hint #7: You can use the cron-apt package to do automatic nightly downloads of updates for packages installed on your system. - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9jKiQQOPluUB9RwRAidKAJ0Z1E9Xb7hPItn5UrsJgps4iQDnLQCfUHDs k65HMLzc1JDIEaU2VRHGUYs= =oMZV - -----END PGP SIGNATURE----- - -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 - -------------------------------------------------------------- Don't get to bragging. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9jbRQQOPluUB9RwRArTuAKCWr7dsroWAZ/XQ4yYBLqIlpkjKiACglvsx eB2FHcbGVJy8r92y2RRZzfU= =7E0U -----END PGP SIGNATURE-----

3 6