Hi! I've set up Calendar Server 3.2 on an Ubuntu Oneiric system (with some trouble, but that's a different story), I managed to connect to our OpenLDAP, and I've configured iCal on OS X 10.7.3 to connect to Calendar Server. So far, so good. However, now and then the following appears in the access log: 10.0.1.68 - - [25/Apr/2012:15:54:07 +0200] "PROPFIND /calendars/__uids__/3d8d8220-3809-5008-aa56-d5250f800f89/ HTTP/1.1" 401 141 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=24.5 or=1 10.0.1.68 - rbh [25/Apr/2012:15:54:07 +0200] "PROPFIND /calendars/__uids__/3d8d8220-3809-5008-aa56-d5250f800f89/ HTTP/1.1" 207 32176 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=21.9 or=1 cached=1 10.0.1.68 - - [25/Apr/2012:15:55:07 +0200] "PROPFIND /calendars/__uids__/3d8d8220-3809-5008-aa56-d5250f800f89/ HTTP/1.1" 404 258 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=12.8 or=1 10.0.1.68 - - [25/Apr/2012:15:55:07 +0200] "PROPFIND /principals/__uids__/3d8d8220-3809-5008-aa56-d5250f800f89/ HTTP/1.1" 404 259 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=6.6 or=1 10.0.1.68 - - [25/Apr/2012:15:55:07 +0200] "PROPFIND /principals/__uids__/3d8d8220-3809-5008-aa56-d5250f800f89/ HTTP/1.1" 404 259 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=7.1 or=1 10.0.1.68 - - [25/Apr/2012:15:55:07 +0200] "PROPFIND / HTTP/1.1" 207 441 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=2.6 or=1 10.0.1.68 - - [25/Apr/2012:15:55:07 +0200] "PROPFIND /principals/ HTTP/1.1" 401 141 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=10.8 or=1 10.0.1.68 - rbh [25/Apr/2012:15:55:07 +0200] "PROPFIND /principals/ HTTP/1.1" 207 505 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=14.7 or=1 responses=1 The first two lines come from an ordinary, successful refresh while the rest come from a refresh (that sometimes makes iCal hang, saying "iCal - Updating…" in the title of the window for more than 20 minutes) resulting in the following error from iCal: The server responded with an error. The URL https://columba.intomics.com:8443/principals/__uids__/3d8d8220-3809-5008-aa5... encountered HTTP error 404. Make sure the URL is correct. Any ideas? I had the same problems when using version 2.4 as packaged with Ubuntu Since all our clients are either MacBook Pros or iPhones, and all our servers run Linux, I'd very much like to get CalendarServer to work on Ubuntu. I've taken notes on what I've done so far, so if I manage to get it to work, I'll post a rough howto on the list. Best regards, Rasmus ----------------------------------------------------------------- Hansen, Rasmus Borup Intomics - from data to biology System Administrator Diplomvej 377 Scientific Programmer DK-2800 Kgs. Lyngby Denmark E: rbh@intomics.com W: http://www.intomics.com/ P: +45 5167 7972 P: +45 8880 7979
On 04/25/2012 10:35 AM, Rasmus Borup Hansen wrote:
Hi! I've set up Calendar Server 3.2 on an Ubuntu Oneiric system (with some trouble, but that's a different story), I managed to connect to our OpenLDAP, and I've configured iCal on OS X 10.7.3 to connect to Calendar Server. So far, so good. However, now and then the following appears in the access log:
10.0.1.68 - - [25/Apr/2012:15:54:07 +0200] "PROPFIND /calendars/__uids__/3d8d8220-3809-5008-aa56-d5250f800f89/ HTTP/1.1" 401 141 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=24.5 or=1 10.0.1.68 - rbh [25/Apr/2012:15:54:07 +0200] "PROPFIND /calendars/__uids__/3d8d8220-3809-5008-aa56-d5250f800f89/ HTTP/1.1" 207 32176 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=21.9 or=1 cached=1 10.0.1.68 - - [25/Apr/2012:15:55:07 +0200] "PROPFIND /calendars/__uids__/3d8d8220-3809-5008-aa56-d5250f800f89/ HTTP/1.1" 404 258 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=12.8 or=1 10.0.1.68 - - [25/Apr/2012:15:55:07 +0200] "PROPFIND /principals/__uids__/3d8d8220-3809-5008-aa56-d5250f800f89/ HTTP/1.1" 404 259 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=6.6 or=1 10.0.1.68 - - [25/Apr/2012:15:55:07 +0200] "PROPFIND /principals/__uids__/3d8d8220-3809-5008-aa56-d5250f800f89/ HTTP/1.1" 404 259 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=7.1 or=1 10.0.1.68 - - [25/Apr/2012:15:55:07 +0200] "PROPFIND / HTTP/1.1" 207 441 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=2.6 or=1 10.0.1.68 - - [25/Apr/2012:15:55:07 +0200] "PROPFIND /principals/ HTTP/1.1" 401 141 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=10.8 or=1 10.0.1.68 - rbh [25/Apr/2012:15:55:07 +0200] "PROPFIND /principals/ HTTP/1.1" 207 505 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50b)" i=0 t=14.7 or=1 responses=1
The first two lines come from an ordinary, successful refresh while the rest come from a refresh (that sometimes makes iCal hang, saying "iCal - Updating…" in the title of the window for more than 20 minutes) resulting in the following error from iCal:
The server responded with an error.
The URL https://columba.intomics.com:8443/principals/__uids__/3d8d8220-3809-5008-aa5... encountered HTTP error 404. Make sure the URL is correct.
Any ideas? I had the same problems when using version 2.4 as packaged with Ubuntu
Since all our clients are either MacBook Pros or iPhones, and all our servers run Linux, I'd very much like to get CalendarServer to work on Ubuntu. I've taken notes on what I've done so far, so if I manage to get it to work, I'll post a rough howto on the list.
Best regards,
Rasmus I don't have a solution for you, but I did want to note that when I had tried to set up CalendarServer on Ubuntu Oneiric (from the Ubuntu repo) about four months ago I was running into the exact same issue using the web based interface....getting random 404's for no obvious reason. After a while of trying to figure out how to manually recreate the issue I sort of gave up.
If anyone can figure it out I'd be interested in giving CalendarServer a try again. The PHP-based alternative I'm using at the moment isn't the best solution for my needs.
On Wed, Apr 25, 2012 at 10:11 AM, Matthew Morgan <atcs.matthew@gmail.com>wrote:
I don't have a solution for you, but I did want to note that when I had tried to set up CalendarServer on Ubuntu Oneiric (from the Ubuntu repo) about four months ago I was running into the exact same issue using the web based interface....getting random 404's for no obvious reason. After a while of trying to figure out how to manually recreate the issue I sort of gave up.
If anyone can figure it out I'd be interested in giving CalendarServer a try again. The PHP-based alternative I'm using at the moment isn't the best solution for my needs.
I will simply echo that I'm having similar problems using the dpkg of 2.4. I've narrowed it down to requested items not being found in memcached, but the fact that I am a crappy python programmer combined with the fact that getting calendarserver is NOT part of my day job, I have been unable to dig in any further and come up with a cause. I've posted questions on the topic on this mailing list a couple of times that didn't bear much fruit. Maybe together we can figure this out? One thing that may be relevant is that the 2.4 package of calendarserver runs against the standard memcached installation. I know that there are some packages that calendarserver sucks in and modifies, and I do not know if memcached is one of those. Maybe a developer can answer this question? Can we run calendarserver--any version--against a standard memcached distribution? -- Chris Cleeland
On Apr 25, 2012, at 17:57 , Chris Cleeland wrote:
I will simply echo that I'm having similar problems using the dpkg of 2.4. I've narrowed it down to requested items not being found in memcached, but the fact that I am a crappy python programmer combined with the fact that getting calendarserver is NOT part of my day job, I have been unable to dig in any further and come up with a cause.
I've posted questions on the topic on this mailing list a couple of times that didn't bear much fruit. Maybe together we can figure this out?
One thing that may be relevant is that the 2.4 package of calendarserver runs against the standard memcached installation. I know that there are some packages that calendarserver sucks in and modifies, and I do not know if memcached is one of those. Maybe a developer can answer this question? Can we run calendarserver--any version--against a standard memcached distribution?
I tried disabling memcached with the configuration below (setting the key ClientEnabled to false) and stopping the memcached that comes with Ubuntu. I still get random 404s, so I think there's more to it than just problems with memcached. <!-- Memcache Settings --> <key>Memcached</key> <dict> <key>MaxClients</key> <integer>5</integer> <key>Options</key> <array> <string>-U</string> <string>0</string> <string>-m</string> <string>6000</string> </array> <key>Pools</key> <dict> <key>Default</key> <dict> <key>ClientEnabled</key> <false/> <key>ServerEnabled</key> <false/> <key>BindAddress</key> <string>localhost</string> <key>Port</key> <integer>11211</integer> <key>HandleCacheTypes</key> <array> <string>Default</string> </array> </dict> </dict> <key>memcached</key> <string>memcached</string> </dict> In addition, I get a lot of the following errors: 2012-04-26 09:04:06+0200 [-] [caldav-0] [-] [twext.web2.dav.http#info] 404 response while getting property: ('http://calendarserver.org/ns/', 'getctag') 2012-04-26 09:04:06+0200 [-] [caldav-0] [-] [twext.web2.dav.http#info] 404 response while getting property: ('DAV:', 'sync-token') Are they related? Best regards, Rasmus ----------------------------------------------------------------- Hansen, Rasmus Borup Intomics - from data to biology System Administrator Diplomvej 377 Scientific Programmer DK-2800 Kgs. Lyngby Denmark E: rbh@intomics.com W: http://www.intomics.com/ P: +45 5167 7972 P: +45 8880 7979
It looks like I've solved the problem. Apparently, you cannot rely on CalendarServer generating the GUIDs. I added the following configuration and haven't had problems yet: … <key>DirectoryService</key> <dict> <key>type</key> <string>twistedcaldav.directory.ldapdirectory.LdapDirectoryService</string> <key>params</key> <dict> … <key>rdnSchema</key> <dict> <key>guidAttr</key> <string>entryUUID</string> … This reuses OpenLDAP's Universally Unique IDentifiers as Globally Unique IDentifiers in CalendarServer which is probably a nice thing in itself. Best regards, Rasmus ----------------------------------------------------------------- Hansen, Rasmus Borup Intomics - from data to biology System Administrator Diplomvej 377 Scientific Programmer DK-2800 Kgs. Lyngby Denmark E: rbh@intomics.com W: http://www.intomics.com/ P: +45 5167 7972 P: +45 8880 7979 On Apr 26, 2012, at 9:08 , Rasmus Borup Hansen wrote:
On Apr 25, 2012, at 17:57 , Chris Cleeland wrote:
I will simply echo that I'm having similar problems using the dpkg of 2.4. I've narrowed it down to requested items not being found in memcached, but the fact that I am a crappy python programmer combined with the fact that getting calendarserver is NOT part of my day job, I have been unable to dig in any further and come up with a cause.
I've posted questions on the topic on this mailing list a couple of times that didn't bear much fruit. Maybe together we can figure this out?
One thing that may be relevant is that the 2.4 package of calendarserver runs against the standard memcached installation. I know that there are some packages that calendarserver sucks in and modifies, and I do not know if memcached is one of those. Maybe a developer can answer this question? Can we run calendarserver--any version--against a standard memcached distribution?
I tried disabling memcached with the configuration below (setting the key ClientEnabled to false) and stopping the memcached that comes with Ubuntu. I still get random 404s, so I think there's more to it than just problems with memcached.
<!-- Memcache Settings --> <key>Memcached</key> <dict> <key>MaxClients</key> <integer>5</integer> <key>Options</key> <array> <string>-U</string> <string>0</string> <string>-m</string> <string>6000</string> </array> <key>Pools</key> <dict> <key>Default</key> <dict> <key>ClientEnabled</key> <false/> <key>ServerEnabled</key> <false/> <key>BindAddress</key> <string>localhost</string> <key>Port</key> <integer>11211</integer> <key>HandleCacheTypes</key> <array> <string>Default</string> </array> </dict> </dict> <key>memcached</key> <string>memcached</string> </dict>
In addition, I get a lot of the following errors:
2012-04-26 09:04:06+0200 [-] [caldav-0] [-] [twext.web2.dav.http#info] 404 response while getting property: ('http://calendarserver.org/ns/', 'getctag') 2012-04-26 09:04:06+0200 [-] [caldav-0] [-] [twext.web2.dav.http#info] 404 response while getting property: ('DAV:', 'sync-token')
Are they related?
Best regards,
Rasmus
----------------------------------------------------------------- Hansen, Rasmus Borup Intomics - from data to biology System Administrator Diplomvej 377 Scientific Programmer DK-2800 Kgs. Lyngby Denmark E: rbh@intomics.com W: http://www.intomics.com/ P: +45 5167 7972 P: +45 8880 7979 _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
On Thu, Apr 26, 2012 at 6:07 AM, Rasmus Borup Hansen <rbh@intomics.com>wrote:
It looks like I've solved the problem. Apparently, you cannot rely on CalendarServer generating the GUIDs. I added the following configuration and haven't had problems yet:
… <key>DirectoryService</key> <dict> <key>type</key>
<string>twistedcaldav.directory.ldapdirectory.LdapDirectoryService</string>
<key>params</key> <dict> … <key>rdnSchema</key> <dict> <key>guidAttr</key> <string>entryUUID</string> …
This reuses OpenLDAP's Universally Unique IDentifiers as Globally Unique IDentifiers in CalendarServer which is probably a nice thing in itself.
Interesting. I'll have to think about how I could do something similar, since I'm not using LDAP as a directory service. With regard to disabling memcached, one of the few responses I got back to my queries regarding memcached is that it's not possible to disable: http://lists.macosforge.org/pipermail/calendarserver-users/2012-February/001... In my case, I'm not sure the GUID generation would change the situation substantially because I already have calendars with GUIDs assigned. What will happen in my case is that sometimes a request will come in and will be "found", while 5 minutes later a request for the same item will come in and not be found. With my weak python debugging skills I traced it down to trying find that something in cache and it not being there. I would think that when it's not in cache it would get loaded, but it's almost as if memcached thinks it has the item but doesn't return it. -- Chris Cleeland
On Apr 26, 2012, at 15:05 , Chris Cleeland wrote:
With regard to disabling memcached, one of the few responses I got back to my queries regarding memcached is that it's not possible to disable:
http://lists.macosforge.org/pipermail/calendarserver-users/2012-February/001...
In my case, I'm not sure the GUID generation would change the situation substantially because I already have calendars with GUIDs assigned. What will happen in my case is that sometimes a request will come in and will be "found", while 5 minutes later a request for the same item will come in and not be found. With my weak python debugging skills I traced it down to trying find that something in cache and it not being there. I would think that when it's not in cache it would get loaded, but it's almost as if memcached thinks it has the item but doesn't return it.
I didn't test the setup without memcached thoroughly - I just noted that it didn't work either. I'm just guessing, but could it be a problem with some mapping between a real username and a GUID that at some point expires from a cache? Perhaps the code does not regenerate the mapping? If the usernames and GUIDs are in a directory, they can just be looked up. Best regards, Rasmus ----------------------------------------------------------------- Hansen, Rasmus Borup Intomics - from data to biology System Administrator Diplomvej 377 Scientific Programmer DK-2800 Kgs. Lyngby Denmark E: rbh@intomics.com W: http://www.intomics.com/ P: +45 5167 7972 P: +45 8880 7979
On Thu, Apr 26, 2012 at 9:07 AM, Rasmus Borup Hansen <rbh@intomics.com>wrote:
I'm just guessing, but could it be a problem with some mapping between a real username and a GUID that at some point expires from a cache? Perhaps the code does not regenerate the mapping? If the usernames and GUIDs are in a directory, they can just be looked up.
Interesting idea, and I wonder if I could test the theory by hard-coding the guid in a test server where there is only one user. -- Chris Cleeland
On Apr 26, 2012, at 4:07 AM, Rasmus Borup Hansen <rbh@intomics.com> wrote:
It looks like I've solved the problem. Apparently, you cannot rely on CalendarServer generating the GUIDs. I added the following configuration and haven't had problems yet:
… <key>DirectoryService</key> <dict> <key>type</key> <string>twistedcaldav.directory.ldapdirectory.LdapDirectoryService</string>
<key>params</key> <dict> … <key>rdnSchema</key> <dict> <key>guidAttr</key> <string>entryUUID</string> …
This reuses OpenLDAP's Universally Unique IDentifiers as Globally Unique IDentifiers in CalendarServer which is probably a nice thing in itself.
Nice find! We've updated the default value for guidAttr to be entryUUID instead of None. http://trac.calendarserver.org/changeset/9188/ Cheers, -dre
Best regards,
Rasmus
----------------------------------------------------------------- Hansen, Rasmus Borup Intomics - from data to biology System Administrator Diplomvej 377 Scientific Programmer DK-2800 Kgs. Lyngby Denmark E: rbh@intomics.com W: http://www.intomics.com/ P: +45 5167 7972 P: +45 8880 7979
On Apr 26, 2012, at 9:08 , Rasmus Borup Hansen wrote:
On Apr 25, 2012, at 17:57 , Chris Cleeland wrote:
I will simply echo that I'm having similar problems using the dpkg of 2.4. I've narrowed it down to requested items not being found in memcached, but the fact that I am a crappy python programmer combined with the fact that getting calendarserver is NOT part of my day job, I have been unable to dig in any further and come up with a cause.
I've posted questions on the topic on this mailing list a couple of times that didn't bear much fruit. Maybe together we can figure this out?
One thing that may be relevant is that the 2.4 package of calendarserver runs against the standard memcached installation. I know that there are some packages that calendarserver sucks in and modifies, and I do not know if memcached is one of those. Maybe a developer can answer this question? Can we run calendarserver--any version--against a standard memcached distribution?
I tried disabling memcached with the configuration below (setting the key ClientEnabled to false) and stopping the memcached that comes with Ubuntu. I still get random 404s, so I think there's more to it than just problems with memcached.
<!-- Memcache Settings --> <key>Memcached</key> <dict> <key>MaxClients</key> <integer>5</integer> <key>Options</key> <array> <string>-U</string> <string>0</string> <string>-m</string> <string>6000</string> </array> <key>Pools</key> <dict> <key>Default</key> <dict> <key>ClientEnabled</key> <false/> <key>ServerEnabled</key> <false/> <key>BindAddress</key> <string>localhost</string> <key>Port</key> <integer>11211</integer> <key>HandleCacheTypes</key> <array> <string>Default</string> </array> </dict> </dict> <key>memcached</key> <string>memcached</string> </dict>
In addition, I get a lot of the following errors:
2012-04-26 09:04:06+0200 [-] [caldav-0] [-] [twext.web2.dav.http#info] 404 response while getting property: ('http://calendarserver.org/ns/', 'getctag') 2012-04-26 09:04:06+0200 [-] [caldav-0] [-] [twext.web2.dav.http#info] 404 response while getting property: ('DAV:', 'sync-token')
Are they related?
Best regards,
Rasmus
----------------------------------------------------------------- Hansen, Rasmus Borup Intomics - from data to biology System Administrator Diplomvej 377 Scientific Programmer DK-2800 Kgs. Lyngby Denmark E: rbh@intomics.com W: http://www.intomics.com/ P: +45 5167 7972 P: +45 8880 7979 _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
participants (4)
-
Andre LaBranche
-
Chris Cleeland
-
Matthew Morgan
-
Rasmus Borup Hansen