Problems on FreeBSD, possibly property-related
I've been trying to get CalendarServer to run on FreeBSD, and have been partly successful with a few tweaks to the kerberos headers. However, it's not quite working (or, at least, I think it's not), and I'm wondering if anyone can help point me in the right direction. Here's the output when I start the server: Unknown option: EventExpirationDays 2006/10/31 18:16 -0500 [-] Log opened. 2006/10/31 18:16 -0500 [-] twistd 2.4.0+r18545 (/usr/local/bin/python 2.4.3) starting up 2006/10/31 18:16 -0500 [-] reactor class: <class ' twisted.internet.selectreactor.SelectReactor'> 2006/10/31 18:16 -0500 [-] Loading /tmp/caldavpSmEK0... 2006/10/31 18:16 -0500 [-] Document root is: twistedcaldav/test/data/ 2006/10/31 18:16 -0500 [-] Repository configuration is: conf/repository- dev.xml 2006/10/31 18:16 -0500 [-] Using SSL private key file: conf/server.pem 2006/10/31 18:16 -0500 [-] Using SSL certificate file: conf/server.pem 2006/10/31 18:16 -0500 [-] IMPORTANT: plain text passwords are allowed without an encrypted/secure connection. 2006/10/31 18:16 -0500 [-] Using property-based password checker. 2006/10/31 18:16 -0500 [-] Using HTTP BASIC authentication. 2006/10/31 18:16 -0500 [-] Starting http server 2006/10/31 18:16 -0500 [-] Starting https server 2006/10/31 18:16 -0500 [-] Starting manhole on port 8007 2006/10/31 18:16 -0500 [-] /home/admin/calendar/Twisted/twisted/manhole/telnet.py:8: exceptions.DeprecationWarning: As of Twisted 2.1, twisted.protocols.telnetis deprecated. See twisted.conch.telnet for the current, supported API. 2006/10/31 18:16 -0500 [-] twisted.manhole.telnet.ShellFactory starting on 8007 2006/10/31 18:16 -0500 [-] Starting factory < twisted.manhole.telnet.ShellFactory instance at 0x8988fac> 2006/10/31 18:16 -0500 [-] Loaded. 2006/10/31 18:16 -0500 [-] twisted.web2.channel.http.HTTPFactory starting on 8008 2006/10/31 18:16 -0500 [-] Starting factory < twisted.web2.channel.http.HTTPFactory instance at 0x899d34c> 2006/10/31 18:16 -0500 [-] twisted.web2.channel.http.HTTPFactory starting on 8443 If I try to use the Thunderbird Lightning client to create a calendar for user01, then here is what I get on the server (the operation fails silently on the client): 2006/10/31 18:22 -0500 [HTTPChannel,0,24.77.30.155] REPORT /principals/users/user01/ HTTP/1.1 2006/10/31 18:22 -0500 [HTTPChannel,0,24.77.30.155] Exception rendering: 2006/10/31 18:22 -0500 [HTTPChannel,0,24.77.30.155] Unhandled Error Traceback (most recent call last): File "/home/admin/calendar/Twisted/twisted/web2/static.py", line 124, in renderHTTP d = maybeDeferred(super(StaticRenderMixin, self).renderHTTP, request) File "/home/admin/calendar/Twisted/twisted/internet/defer.py", line 107, in maybeDeferred result = f(*args, **kw) File "/home/admin/calendar/Twisted/twisted/web2/resource.py", line 88, in renderHTTP return method(request) File "/home/admin/calendar/Twisted/twisted/internet/defer.py", line 663, in unwindGenerator return _deferGenerator(f(*args, **kwargs)) --- <exception caught here> --- File "/home/admin/calendar/Twisted/twisted/internet/defer.py", line 623, in _deferGenerator result = g.next() File "/home/admin/calendar/Twisted/twisted/web2/dav/method/report.py", line 61, in http_REPORT x.getResult() File "/home/admin/calendar/Twisted/twisted/internet/defer.py", line 609, in getResult self.result.raiseException() File "/home/admin/calendar/Twisted/twisted/python/failure.py", line 259, in raiseException raise self.type, self.value, self.tb exceptions.AttributeError: 'NoneType' object has no attribute 'addCallback' I can log in with a browser client with admin/admin and get a directory listing for the root directory which looks sane -- here is what I see on the server: 2006/10/31 18:27 -0500 [HTTPChannel,1,24.77.30.155] GET / HTTP/1.1 2006/10/31 18:27 -0500 [HTTPChannel,1,24.77.30.155] GET / HTTP/1.1 However, if I try to go further down the hierarchy, I get errors again. For instance, if I try to fetch /calendars/users/user01, then it will not accept my username/password (whether admin/admin or user01/user01). What I see on the sever is: 2006/10/31 18:30 -0500 [HTTPChannel,2,24.77.30.155] GET /calendars/users/user01/ HTTP/1.1 2006/10/31 18:30 -0500 [HTTPChannel,2,24.77.30.155] DAV:principal-collection-set property cannot be found on the resource being authorized: <CalendarHomeFile: /usr/home/admin/calendar/CalendarServer/twistedcaldav/test/data/calendars/users/user01> 2006/10/31 18:30 -0500 [HTTPChannel,2,24.77.30.155] 'Invalid authentication details: <GET /calendars/users/user01/ (1, 1)>' I noted the error message about properties. If I look at the file in the filesystem with lsextattr, I can see that is has the following attribute: WebDAV:{DAV:}acl -- which I assume is a mangled form of DAV:acl. (Not sure where the mangling comes from or whether that might be a problem). The content of the attribute is as follows (as seen from getextattr): <?xml version='1.0' encoding='UTF-8'?> <acl xmlns='DAV:'> <ace> <principal> <authenticated/> </principal> <grant> <privilege> <read/> </privilege> </grant> </ace> <ace> <principal> <href>/principals/users/user01</href> </principal> <grant> <privilege> <all/> </privilege> </grant> <inheritable xmlns='http://twistedmatrix.com/xml_namespace/dav/'/> </ace> </acl> So, clearly something is setting the attribute -- modulo the name mangling. However, it is true that there is no DAV:principal-collection-set property there. Going up the hierarchy, there is WebDAV:{DAV:}principal-collection-set property on calendar/CalendarServer/twistedcaldav/test/data (as seen with lsextattr -- again, I'm assuming that there is some name-mangling going on here which may or may not be the problem). The content of the attribute (as seen with getextattr) is as follows: <?xml version='1.0' encoding='UTF-8'?> <principal-collection-set xmlns='DAV:'> <href>/principals/users/</href> </principal-collection-set> I haven't set this up on Mac OS X, so I don't know what I'm supposed to be seeing. If anyone can give me a few clues, I would be most grateful. My working assumption is that the names of the properties are being mangled when written in some way that is causing problems when they are read.
BTW, here is a quick list of what I had to change to get this far on FreeBSD. The "run" script has #! /bin/bash, which I had to change to #! /usr/local/bin/bash (I had the bash port installed -- I didn't check whether /bin/sh would also have worked). I had to make the following patches to the kerberos-related headers: --- calendar.orig/PyKerberos/src/kerberosbasic.h Tue Oct 31 19:26:10 2006 +++ calendar/PyKerberos/src/kerberosbasic.h Mon Oct 30 19:36:50 2006 @@ -17,9 +17,11 @@ **/ #include <gssapi.h> +#include <krb5.h> +#if 0 #include <gssapi_generic.h> #include <gssapi_krb5.h> - +#endif #define krb5_get_err_text(context,code) error_message(code) int authenticate_user_krb5pwd(const char *user, const char *pswd, const char *service, const char *defau lt_realm); diff -ur --exclude=.svn calendar.orig/PyKerberos/src/kerberosgss.h calendar/PyKerberos/src/kerberosgss.h --- calendar.orig/PyKerberos/src/kerberosgss.h Tue Oct 31 19:26:10 2006 +++ calendar/PyKerberos/src/kerberosgss.h Mon Oct 30 19:53:57 2006 @@ -17,9 +17,14 @@ **/ #include <gssapi.h> +#include <krb5.h> + +#define gss_krb5_nt_service_name GSS_KRB5_NT_PRINCIPAL_NAME + +/* #include <gssapi_generic.h> #include <gssapi_krb5.h> - +*/ #define krb5_get_err_text(context,code) error_message(code) #define AUTH_GSS_ERROR -1
Hi Ryan, --On October 31, 2006 5:46:39 PM -0600 Ryan Rempel <rgrempel@gmail.com> wrote:
I've been trying to get CalendarServer to run on FreeBSD, and have been partly successful with a few tweaks to the kerberos headers. However, it's not quite working (or, at least, I think it's not), and I'm wondering if anyone can help point me in the right direction.
FYI Recent commit fixes this. -- Cyrus Daboo
On 11/2/06, Cyrus Daboo <cdaboo@apple.com> wrote:
--On October 31, 2006 5:46:39 PM -0600 Ryan Rempel <rgrempel@gmail.com> wrote:
I've been trying to get CalendarServer to run on FreeBSD, and have been partly successful with a few tweaks to the kerberos headers. However, it's not quite working (or, at least, I think it's not), and I'm wondering if anyone can help point me in the right direction.
FYI Recent commit fixes this.
Thanks! I can confirm that I'm getting further now -- I'm having some other difficulties, but I'll start a separate thread for that :-)
participants (2)
-
Cyrus Daboo
-
Ryan Rempel