[CalendarServer-changes] [10956] CalendarServer/branches/users/gaya/directorybacker
source_changes at macosforge.org
source_changes at macosforge.org
Wed Mar 20 12:04:17 PDT 2013
Revision: 10956
http://trac.calendarserver.org//changeset/10956
Author: gaya at apple.com
Date: 2013-03-20 12:04:17 -0700 (Wed, 20 Mar 2013)
Log Message:
-----------
merge from trunk
Modified Paths:
--------------
CalendarServer/branches/users/gaya/directorybacker/calendarserver/accesslog.py
CalendarServer/branches/users/gaya/directorybacker/support/Makefile.Apple
CalendarServer/branches/users/gaya/directorybacker/testserver
CalendarServer/branches/users/gaya/directorybacker/twext/python/sendfd.py
CalendarServer/branches/users/gaya/directorybacker/twistedcaldav/scheduling/ischedule/utils.py
CalendarServer/branches/users/gaya/directorybacker/txdav/base/propertystore/xattr.py
Added Paths:
-----------
CalendarServer/branches/users/gaya/directorybacker/calendarserver/tools/test/test_config.py
CalendarServer/branches/users/gaya/directorybacker/doc/RFC/RFC6764-srv-CalDAV.txt
CalendarServer/branches/users/gaya/directorybacker/doc/calendarserver_config.8
Removed Paths:
-------------
CalendarServer/branches/users/gaya/directorybacker/contrib/certupdate/
CalendarServer/branches/users/gaya/directorybacker/contrib/migration/
Modified: CalendarServer/branches/users/gaya/directorybacker/calendarserver/accesslog.py
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/calendarserver/accesslog.py 2013-03-20 03:35:56 UTC (rev 10955)
+++ CalendarServer/branches/users/gaya/directorybacker/calendarserver/accesslog.py 2013-03-20 19:04:17 UTC (rev 10956)
@@ -33,6 +33,7 @@
import psutil
except ImportError:
psutil = None
+from sys import platform
import time
from calendarserver.logAnalysis import getAdjustedMethodName, \
@@ -627,7 +628,7 @@
self.previous_cpu = cpu_now
# Memory usage
- if psutil is not None:
+ if psutil is not None and 'freebsd' not in platform:
mem = psutil.virtual_memory()
self.items["memory used"] = mem.used
self.items["memory percent"] = mem.percent
Copied: CalendarServer/branches/users/gaya/directorybacker/calendarserver/tools/test/test_config.py (from rev 10934, CalendarServer/trunk/calendarserver/tools/test/test_config.py)
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/calendarserver/tools/test/test_config.py (rev 0)
+++ CalendarServer/branches/users/gaya/directorybacker/calendarserver/tools/test/test_config.py 2013-03-20 19:04:17 UTC (rev 10956)
@@ -0,0 +1,220 @@
+##
+# Copyright (c) 2013 Apple Inc. All rights reserved.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+##
+
+from twistedcaldav.test.util import TestCase
+from twistedcaldav.config import ConfigDict
+from calendarserver.tools.config import WritableConfig, setKeyPath, getKeyPath, flattenDictionary
+from calendarserver.tools.test.test_gateway import RunCommandTestCase
+from twisted.internet.defer import inlineCallbacks
+from twisted.python.filepath import FilePath
+from xml.parsers.expat import ExpatError
+import plistlib
+
+PREAMBLE = """<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+"""
+class WritableConfigTestCase(TestCase):
+
+ def setUp(self):
+ self.configFile = self.mktemp()
+ self.fp = FilePath(self.configFile)
+
+ def test_readSuccessful(self):
+ content = """<plist version="1.0">
+ <dict>
+ <key>string</key>
+ <string>foo</string>
+ </dict>
+</plist>"""
+ self.fp.setContent(PREAMBLE + content)
+
+ config = ConfigDict()
+ writable = WritableConfig(config, self.configFile)
+ writable.read()
+ self.assertEquals(writable.currentConfigSubset, {"string":"foo"})
+
+ def test_readInvalidXML(self):
+ self.fp.setContent("invalid")
+ config = ConfigDict()
+ writable = WritableConfig(config, self.configFile)
+ self.assertRaises(ExpatError, writable.read)
+
+ def test_updates(self):
+ content = """<plist version="1.0">
+ <dict>
+ <key>key1</key>
+ <string>before</string>
+ <key>key2</key>
+ <integer>10</integer>
+ </dict>
+</plist>"""
+ self.fp.setContent(PREAMBLE + content)
+ config = ConfigDict()
+ writable = WritableConfig(config, self.configFile)
+ writable.read()
+ writable.set({"key1":"after"})
+ writable.set({"key2":15})
+ writable.set({"key2":20}) # override previous set
+ writable.set({"key3":["a", "b", "c"]})
+ self.assertEquals(writable.currentConfigSubset, {"key1":"after", "key2":20, "key3":["a", "b", "c"]})
+ writable.save()
+
+ writable2 = WritableConfig(config, self.configFile)
+ writable2.read()
+ self.assertEquals(writable2.currentConfigSubset, {"key1":"after", "key2":20, "key3":["a", "b", "c"]})
+
+ def test_convertToValue(self):
+ self.assertEquals(True, WritableConfig.convertToValue("True"))
+ self.assertEquals(False, WritableConfig.convertToValue("False"))
+ self.assertEquals(1, WritableConfig.convertToValue("1"))
+ self.assertEquals(1.2, WritableConfig.convertToValue("1.2"))
+ self.assertEquals("xyzzy", WritableConfig.convertToValue("xyzzy"))
+ self.assertEquals("xy.zzy", WritableConfig.convertToValue("xy.zzy"))
+
+
+class ConfigTestCase(RunCommandTestCase):
+
+ @inlineCallbacks
+ def test_readConfig(self):
+ """
+ Verify readConfig returns with only the writable keys
+ """
+ results = yield self.runCommand(command_readConfig,
+ script="calendarserver_config")
+
+ self.assertEquals(results["result"]["RedirectHTTPToHTTPS"], False)
+ self.assertEquals(results["result"]["EnableSearchAddressBook"], False)
+ self.assertEquals(results["result"]["EnableCalDAV"], True)
+ self.assertEquals(results["result"]["EnableCardDAV"], True)
+ self.assertEquals(results["result"]["EnableSSL"], False)
+ self.assertEquals(results["result"]["Notifications"]["Services"]["APNS"]["Enabled"], False)
+ self.assertEquals(results["result"]["Notifications"]["Services"]["APNS"]["CalDAV"]["CertificatePath"], "/example/calendar.cer")
+
+ # Verify not all keys are present, such as ServerRoot which is not writable
+ self.assertFalse(results["result"].has_key("ServerRoot"))
+
+ @inlineCallbacks
+ def test_writeConfig(self):
+ """
+ Verify writeConfig updates the writable plist file only
+ """
+ results = yield self.runCommand(command_writeConfig,
+ script="calendarserver_config")
+
+ self.assertEquals(results["result"]["EnableCalDAV"], False)
+ self.assertEquals(results["result"]["EnableCardDAV"], False)
+ self.assertEquals(results["result"]["EnableSSL"], True)
+ self.assertEquals(results["result"]["Notifications"]["Services"]["APNS"]["Enabled"], True)
+ self.assertEquals(results["result"]["Notifications"]["Services"]["APNS"]["CalDAV"]["CertificatePath"], "/example/changed.cer")
+
+ # The static plist should still have EnableCalDAV = True
+ staticPlist = plistlib.readPlist(self.configFileName)
+ self.assertTrue(staticPlist["EnableCalDAV"])
+
+ @inlineCallbacks
+ def test_error(self):
+ """
+ Verify sending a bogus command returns an error
+ """
+ results = yield self.runCommand(command_bogusCommand,
+ script="calendarserver_config")
+ self.assertEquals(results["error"], "Unknown command 'bogus'")
+
+
+ def test_keyPath(self):
+ d = ConfigDict()
+ setKeyPath(d, "one", "A")
+ setKeyPath(d, "one", "B")
+ setKeyPath(d, "two.one", "C")
+ setKeyPath(d, "two.one", "D")
+ setKeyPath(d, "two.two", "E")
+ setKeyPath(d, "three.one.one", "F")
+ setKeyPath(d, "three.one.two", "G")
+
+ self.assertEquals(d.one, "B")
+ self.assertEquals(d.two.one, "D")
+ self.assertEquals(d.two.two, "E")
+ self.assertEquals(d.three.one.one, "F")
+ self.assertEquals(d.three.one.two, "G")
+
+ self.assertEquals(getKeyPath(d, "one"), "B")
+ self.assertEquals(getKeyPath(d, "two.one"), "D")
+ self.assertEquals(getKeyPath(d, "two.two"), "E")
+ self.assertEquals(getKeyPath(d, "three.one.one"), "F")
+ self.assertEquals(getKeyPath(d, "three.one.two"), "G")
+
+ def test_flattenDictionary(self):
+ dictionary = {
+ "one" : "A",
+ "two" : {
+ "one" : "D",
+ "two" : "E",
+ },
+ "three" : {
+ "one" : {
+ "one" : "F",
+ "two" : "G",
+ },
+ },
+ }
+ self.assertEquals(
+ set(list(flattenDictionary(dictionary))),
+ set([("one", "A"), ("three.one.one", "F"), ("three.one.two", "G"), ("two.one", "D"), ("two.two", "E")])
+ )
+
+
+command_readConfig = """<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+ <key>command</key>
+ <string>readConfig</string>
+</dict>
+</plist>
+"""
+
+command_writeConfig = """<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+ <key>command</key>
+ <string>writeConfig</string>
+ <key>Values</key>
+ <dict>
+ <key>EnableCalDAV</key>
+ <false/>
+ <key>EnableCardDAV</key>
+ <false/>
+ <key>EnableSSL</key>
+ <true/>
+ <key>Notifications.Services.APNS.Enabled</key>
+ <true/>
+ <key>Notifications.Services.APNS.CalDAV.CertificatePath</key>
+ <string>/example/changed.cer</string>
+ </dict>
+</dict>
+</plist>
+"""
+
+command_bogusCommand = """<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+ <key>command</key>
+ <string>bogus</string>
+</dict>
+</plist>
+"""
Copied: CalendarServer/branches/users/gaya/directorybacker/doc/RFC/RFC6764-srv-CalDAV.txt (from rev 10934, CalendarServer/trunk/doc/RFC/RFC6764-srv-CalDAV.txt)
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/doc/RFC/RFC6764-srv-CalDAV.txt (rev 0)
+++ CalendarServer/branches/users/gaya/directorybacker/doc/RFC/RFC6764-srv-CalDAV.txt 2013-03-20 19:04:17 UTC (rev 10956)
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Daboo
+Request for Comments: 6764 Apple Inc.
+Updates: 4791, 6352 February 2013
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ Locating Services for Calendaring Extensions to
+ WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
+
+Abstract
+
+ This specification describes how DNS SRV records, DNS TXT records,
+ and well-known URIs can be used together or separately to locate
+ CalDAV (Calendaring Extensions to Web Distributed Authoring and
+ Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV)
+ services.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6764.
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+Daboo Standards Track [Page 1]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions Used in This Document ...............................3
+ 3. CalDAV SRV Service Labels .......................................3
+ 4. CalDAV and CardDAV Service TXT Records ..........................4
+ 5. CalDAV and CardDAV Service Well-Known URI .......................4
+ 5.1. Example: Well-Known URI Redirects to Actual
+ "Context Path" .............................................5
+ 6. Client "Bootstrapping" Procedures ...............................5
+ 7. Guidance for Service Providers ..................................8
+ 8. Security Considerations .........................................9
+ 9. IANA Considerations .............................................9
+ 9.1. Well-Known URI Registrations ...............................9
+ 9.1.1. caldav Well-Known URI Registration .................10
+ 9.1.2. carddav Well-Known URI Registration ................10
+ 9.2. Service Name Registrations ................................10
+ 9.2.1. caldav Service Name Registration ...................10
+ 9.2.2. caldavs Service Name Registration ..................11
+ 9.2.3. carddav Service Name Registration ..................11
+ 9.2.4. carddavs Service Name Registration .................12
+ 10. Acknowledgments ...............................................12
+ 11. References ....................................................12
+ 11.1. Normative References .....................................12
+ 11.2. Informative References ...................................14
+
+1. Introduction
+
+ [RFC4791] defines the CalDAV calendar access protocol, based on HTTP
+ [RFC2616], for accessing calendar data stored on a server. CalDAV
+ clients need to be able to discover appropriate CalDAV servers within
+ their local area network and at other domains, e.g., to minimize the
+ need for end users to know specific details such as the fully
+ qualified domain name (FQDN) and port number for their servers.
+
+ [RFC6352] defines the CardDAV address book access protocol based on
+ HTTP [RFC2616], for accessing contact data stored on a server. As
+ with CalDAV, clients also need to be able to discover CardDAV
+ servers.
+
+ [RFC2782] defines a DNS-based service discovery protocol that has
+ been widely adopted as a means of locating particular services within
+ a local area network and beyond, using DNS SRV Resource Records
+ (RRs). This has been enhanced to provide additional service meta-
+ data by use of DNS TXT RRs as per [RFC6763].
+
+
+
+
+
+
+Daboo Standards Track [Page 2]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+ This specification defines new SRV service types for the CalDAV
+ protocol and gives an example of how clients can use this together
+ with other protocol features to enable simple client configuration.
+ SRV service types for CardDAV are already defined in Section 11 of
+ [RFC6352].
+
+ Another issue with CalDAV or CardDAV service discovery is that the
+ service might not be located at the "root" URI of the HTTP server
+ hosting it. Thus, a client needs to be able to determine the
+ complete path component of the Request-URI to use in HTTP requests:
+ the "context path". For example, if CalDAV is implemented as a
+ "servlet" in a web server "container", the servlet "context path"
+ might be "/caldav/". So the URI for the CalDAV service would be,
+ e.g., "http://caldav.example.com/caldav/" rather than
+ "http://caldav.example.com/". SRV RRs by themselves only provide an
+ FQDN and port number for the service, not a path. Since the client
+ "bootstrapping" process requires initial access to the "context path"
+ of the service, there needs to be a simple way for clients to also
+ discover what that path is.
+
+ This specification makes use of the "well-known URI" feature
+ [RFC5785] of HTTP servers to provide a well-known URI for CalDAV or
+ CardDAV services that clients can use. The well-known URI will point
+ to a resource on the server that is simply a "stub" resource that
+ provides a redirect to the actual "context path" resource
+ representing the service endpoint.
+
+2. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. CalDAV SRV Service Labels
+
+ This specification adds two SRV service labels for use with CalDAV:
+
+ _caldav: Identifies a CalDAV server that uses HTTP without
+ Transport Layer Security (TLS) [RFC2818].
+
+ _caldavs: Identifies a CalDAV server that uses HTTP with TLS
+ [RFC2818].
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 3]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+ Clients MUST honor Priority and Weight values in the SRV RRs, as
+ described by [RFC2782].
+
+ Example: service record for server without TLS
+
+ _caldav._tcp SRV 0 1 80 calendar.example.com.
+
+ Example: service record for server with TLS
+
+ _caldavs._tcp SRV 0 1 443 calendar.example.com.
+
+4. CalDAV and CardDAV Service TXT Records
+
+ When SRV RRs are used to advertise CalDAV and CardDAV services, it is
+ also convenient to be able to specify a "context path" in the DNS to
+ be retrieved at the same time. To enable that, this specification
+ uses a TXT RR that follows the syntax defined in Section 6 of
+ [RFC6763] and defines a "path" key for use in that record. The value
+ of the key MUST be the actual "context path" to the corresponding
+ service on the server.
+
+ A site might provide TXT records in addition to SRV records for each
+ service. When present, clients MUST use the "path" value as the
+ "context path" for the service in HTTP requests. When not present,
+ clients use the ".well-known" URI approach described next.
+
+ Example: text record for service with TLS
+
+ _caldavs._tcp TXT path=/caldav
+
+5. CalDAV and CardDAV Service Well-Known URI
+
+ Two ".well-known" URIs are registered by this specification for
+ CalDAV and CardDAV services, "caldav" and "carddav" respectively (see
+ Section 9). These URIs point to a resource that the client can use
+ as the initial "context path" for the service they are trying to
+ connect to. The server MUST redirect HTTP requests for that resource
+ to the actual "context path" using one of the available mechanisms
+ provided by HTTP (e.g., using a 301, 303, or 307 response). Clients
+ MUST handle HTTP redirects on the ".well-known" URI. Servers MUST
+ NOT locate the actual CalDAV or CardDAV service endpoint at the
+ ".well-known" URI as per Section 1.1 of [RFC5785].
+
+ Servers SHOULD set an appropriate Cache-Control header value (as per
+ Section 14.9 of [RFC2616]) in the redirect response to ensure caching
+ occurs or does not occur as needed or as required by the type of
+ response generated. For example, if it is anticipated that the
+
+
+
+
+Daboo Standards Track [Page 4]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+ location of the redirect might change over time, then a "no-cache"
+ value would be used.
+
+ To facilitate "context paths" that might differ from user to user,
+ the server MAY require authentication when a client tries to access
+ the ".well-known" URI (i.e., the server would return a 401 status
+ response to the unauthenticated request from the client, then return
+ the redirect response only after a successful authentication by the
+ client).
+
+5.1. Example: Well-Known URI Redirects to Actual "Context Path"
+
+ A CalDAV server has a "context path" that is "/servlet/caldav". The
+ client will use "/.well-known/caldav" as the path for its
+ "bootstrapping" process after it has first found the FQDN and port
+ number via an SRV lookup or via manual entry of information by the
+ user, from which the client can parse suitable information. When the
+ client makes an HTTP request against "/.well-known/caldav", the
+ server would issue an HTTP redirect response with a Location response
+ header using the path "/servlet/caldav". The client would then
+ "follow" this redirect to the new resource and continue making HTTP
+ requests there to complete its "bootstrapping" process.
+
+6. Client "Bootstrapping" Procedures
+
+ This section describes a procedure that CalDAV or CardDAV clients
+ SHOULD use to do their initial configuration based on minimal user
+ input. The goal is to determine an http: or https: URI that
+ describes the full path to the user's principal-URL [RFC3744].
+
+ 1. Processing user input:
+
+ * For a CalDAV server:
+
+ + Minimal input from a user would consist of a calendar user
+ address and a password. A calendar user address is defined
+ by iCalendar [RFC5545] to be a URI [RFC3986]. Provided a
+ user identifier and a domain name can be extracted from the
+ URI, this simple "bootstrapping" configuration can be done.
+
+ + If the calendar user address is a "mailto:" [RFC6068] URI,
+ the "mailbox" portion of the URI is examined, and the
+ "local-part" and "domain" portions are extracted.
+
+ + If the calendar user address is an "http:" [RFC2616] or
+ "https:" [RFC2818] URI, the "userinfo" and "host" portion
+ of the URI [RFC3986] is extracted.
+
+
+
+
+Daboo Standards Track [Page 5]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+ * For a CardDAV server:
+
+ + Minimal input from a user would consist of their email
+ address [RFC5322] for the domain where the CardDAV service
+ is hosted, and a password. The "mailbox" portion of the
+ email address is examined, and the "local-part" and
+ "domain" portions are extracted.
+
+ 2. Determination of service FQDN and port number:
+
+ * An SRV lookup for _caldavs._tcp (for CalDAV) or _carddavs._tcp
+ (for CardDAV) is done with the extracted "domain" as the
+ service domain.
+
+ * If no result is found, the client can try _caldav._tcp (for
+ CalDAV) or _carddav._tcp (for CardDAV) provided non-TLS
+ connections are appropriate.
+
+ * If an SRV record is returned, the client extracts the target
+ FQDN and port number. If multiple SRV records are returned,
+ the client MUST use the Priority and Weight fields in the
+ record to determine which one to pick (as per [RFC2782]).
+
+ * If an SRV record is not found, the client will need to prompt
+ the user to enter the FQDN and port number information
+ directly or use some other heuristic, for example, using the
+ extracted "domain" as the FQDN and default HTTPS or HTTP port
+ numbers. In this situation, clients MUST first attempt an
+ HTTP connection with TLS.
+
+ 3. Determination of initial "context path":
+
+ * When an SRV lookup is done and a valid SRV record returned,
+ the client MUST also query for a corresponding TXT record and
+ check for the presence of a "path" key in its response. If
+ present, the value of the "path" key is used for the initial
+ "context path".
+
+ * When an initial "context path" has not been determined from a
+ TXT record, the initial "context path" is taken to be
+ "/.well-known/caldav" (for CalDAV) or "/.well-known/carddav"
+ (for CardDAV).
+
+ * If the initial "context path" derived from a TXT record
+ generates HTTP errors when targeted by requests, the client
+ SHOULD repeat its "bootstrapping" procedure using the
+ appropriate ".well-known" URI instead.
+
+
+
+
+Daboo Standards Track [Page 6]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+ 4. Determination of user identifier:
+
+ * The client will need to make authenticated HTTP requests to
+ the service. Typically, a "user identifier" is required for
+ some form of user/password authentication. When a user
+ identifier is required, clients MUST first use the "mailbox"
+ portion of the calendar user address provided by the user in
+ the case of a "mailto:" address and, if that results in an
+ authentication failure, SHOULD fall back to using the "local-
+ part" extracted from the "mailto:" address. For an "http:" or
+ "https:" calendar user address, the "userinfo" portion is used
+ as the user identifier for authentication. This is in line
+ with the guidance outlined in Section 7. If these user
+ identifiers result in authentication failure, the client
+ SHOULD prompt the user for a valid identifier.
+
+ 5. Connecting to the service:
+
+ * Subsequent to configuration, the client will make HTTP
+ requests to the service. When using "_caldavs" or "_carddavs"
+ services, a TLS negotiation is done immediately upon
+ connection. The client MUST do certificate verification using
+ the procedure outlined in Section 6 of [RFC6125] in regard to
+ verification with an SRV RR as the starting point.
+
+ * The client does a "PROPFIND" [RFC4918] request with the
+ request URI set to the initial "context path". The body of
+ the request SHOULD include the DAV:current-user-principal
+ [RFC5397] property as one of the properties to return. Note
+ that clients MUST properly handle HTTP redirect responses for
+ the request. The server will use the HTTP authentication
+ procedure outlined in [RFC2617] or use some other appropriate
+ authentication schemes to authenticate the user.
+
+ * If the server returns a 404 ("Not Found") HTTP status response
+ to the request on the initial "context path", clients MAY try
+ repeating the request on the "root" URI "/" or prompt the user
+ for a suitable path.
+
+ * If the DAV:current-user-principal property is returned on the
+ request, the client uses that value for the principal-URL of
+ the authenticated user. With that, it can execute a
+ "PROPFIND" request on the principal-URL and discover
+ additional properties for configuration (e.g., calendar or
+ address book "home" collections).
+
+
+
+
+
+
+Daboo Standards Track [Page 7]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+ * If the DAV:current-user-principal property is not returned,
+ then the client will need to request the principal-URL path
+ from the user in order to continue with configuration.
+
+ Once a successful account discovery step has been done, clients
+ SHOULD cache the service details that were successfully used (user
+ identity, principal-URL with full scheme/host/port details) and reuse
+ those when connecting again at a later time.
+
+ If a subsequent connection attempt fails, or authentication fails
+ persistently, clients SHOULD retry the SRV lookup and account
+ discovery to "refresh" the cached data.
+
+7. Guidance for Service Providers
+
+ Service providers wanting to offer CalDAV or CardDAV services that
+ can be configured by clients using SRV records need to follow certain
+ procedures to ensure proper operation.
+
+ o CalDAV or CardDAV servers SHOULD be configured to allow
+ authentication with calendar user addresses (just taking the
+ "mailbox" portion of any "mailto:" URI) or email addresses
+ respectively, or with "user identifiers" extracted from them. In
+ the former case, the addresses MUST NOT conflict with other forms
+ of a permitted user login name. In the latter case, the extracted
+ "user identifiers" need to be unique across the server and MUST
+ NOT conflict with any login name on the server.
+
+ o Servers MUST force authentication for "PROPFIND" requests that
+ retrieve the DAV:current-user-principal property to ensure that
+ the value of the DAV:current-user-principal property returned
+ corresponds to the principal-URL of the user making the request.
+
+ o If the service provider uses TLS, the service provider MUST ensure
+ a certificate is installed that can be verified by clients using
+ the procedure outlined in Section 6 of [RFC6125] in regard to
+ verification with an SRV RR as the starting point. In particular,
+ certificates SHOULD include SRV-ID and DNS-ID identifiers as
+ appropriate, as described in Section 8.
+
+ o Service providers should install the appropriate SRV records for
+ the offered services and optionally include TXT records.
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 8]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+8. Security Considerations
+
+ Clients that support TLS as defined by [RFC2818] SHOULD try the
+ "_caldavs" or "_carddavs" services first before trying the "_caldav"
+ or "_carddav" services respectively. If a user has explicitly
+ requested a connection with TLS, the client MUST NOT use any service
+ information returned for the "_caldav" or "_carddav" services.
+ Clients MUST follow the certificate-verification process specified in
+ [RFC6125].
+
+ A malicious attacker with access to the DNS server data, or that is
+ able to get spoofed answers cached in a recursive resolver, can
+ potentially cause clients to connect to any server chosen by the
+ attacker. In the absence of a secure DNS option, clients SHOULD
+ check that the target FQDN returned in the SRV record matches the
+ original service domain that was queried. If the target FQDN is not
+ in the queried domain, clients SHOULD verify with the user that the
+ SRV target FQDN is suitable for use before executing any connections
+ to the host. Alternatively, if TLS is being used for the service,
+ clients MUST use the procedure outlined in Section 6 of [RFC6125] to
+ verify the service. When the target FQDN does not match the original
+ service domain that was queried, clients MUST check the SRV-ID
+ identifier in the server's certificate. If the FQDN does match,
+ clients MUST check any SRV-ID identifiers in the server's certificate
+ or, if no SRV-ID identifiers are present, MUST check the DNS-ID
+ identifiers in the server's certificate.
+
+ Implementations of TLS [RFC5246], used as the basis for TLS
+ ([RFC2818]), typically support multiple versions of the protocol as
+ well as the older SSL (Secure Sockets Layer) protocol. Because of
+ known security vulnerabilities, clients and servers MUST NOT request,
+ offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further
+ details.
+
+9. IANA Considerations
+
+9.1. Well-Known URI Registrations
+
+ This document defines two ".well-known" URIs using the registration
+ procedure and template from Section 5.1 of [RFC5785].
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 9]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+9.1.1. caldav Well-Known URI Registration
+
+ URI suffix: caldav
+
+ Change controller: IETF
+
+ Specification document(s): This RFC
+
+ Related information: See also [RFC4791].
+
+9.1.2. carddav Well-Known URI Registration
+
+ URI suffix: carddav
+
+ Change controller: IETF
+
+ Specification document(s): This RFC
+
+ Related information: See also [RFC6352].
+
+9.2. Service Name Registrations
+
+ This document registers four new service names as per [RFC6335]. Two
+ are defined in this document, and two are defined in [RFC6352],
+ Section 11.
+
+9.2.1. caldav Service Name Registration
+
+ Service Name: caldav
+
+ Transport Protocol(s): TCP
+
+ Assignee: IESG <iesg at ietf.org>
+
+ Contact: IETF Chair <chair at ietf.org>
+
+ Description: Calendaring Extensions to WebDAV (CalDAV) - non-TLS
+
+ Reference: [RFC6764]
+
+ Assignment Note: This is an extension of the http service. Defined
+ TXT keys: path=<context path>
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 10]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+9.2.2. caldavs Service Name Registration
+
+ Service Name: caldavs
+
+ Transport Protocol(s): TCP
+
+ Assignee: IESG <iesg at ietf.org>
+
+ Contact: IETF Chair <chair at ietf.org>
+
+ Description: Calendaring Extensions to WebDAV (CalDAV) - over TLS
+
+ Reference: [RFC6764]
+
+ Assignment Note: This is an extension of the https service. Defined
+ TXT keys: path=<context path>
+
+9.2.3. carddav Service Name Registration
+
+ Service Name: carddav
+
+ Transport Protocol(s): TCP
+
+ Assignee: IESG <iesg at ietf.org>
+
+ Contact: IETF Chair <chair at ietf.org>
+
+ Description: vCard Extensions to WebDAV (CardDAV) - non-TLS
+
+ Reference: [RFC6352]
+
+ Assignment Note: This is an extension of the http service. Defined
+ TXT keys: path=<context path>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 11]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+9.2.4. carddavs Service Name Registration
+
+ Service Name: carddavs
+
+ Transport Protocol(s): TCP
+
+ Assignee: IESG <iesg at ietf.org>
+
+ Contact: IETF Chair <chair at ietf.org>
+
+ Description: vCard Extensions to WebDAV (CardDAV) - over TLS
+
+ Reference: [RFC6352]
+
+ Assignment Note: This is an extension of the https service. Defined
+ TXT keys: path=<context path>
+
+10. Acknowledgments
+
+ This specification was suggested by discussion that took place within
+ the Calendaring and Scheduling Consortium's CalDAV Technical
+ Committee. The author thanks the following for their contributions:
+ Stuart Cheshire, Bernard Desruisseaux, Eran Hammer-Lahav, Helge Hess,
+ Arnaud Quillaud, Wilfredo Sanchez, and Joe Touch.
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+ Leach, P., Luotonen, A., and L. Stewart, "HTTP
+ Authentication: Basic and Digest Access Authentication",
+ RFC 2617, June 1999.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+
+
+
+
+Daboo Standards Track [Page 12]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+ [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
+ Distributed Authoring and Versioning (WebDAV)
+ Access Control Protocol", RFC 3744, May 2004.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, January 2005.
+
+ [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
+ "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
+ March 2007.
+
+ [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
+ Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ October 2008.
+
+ [RFC5397] Sanchez, W. and C. Daboo, "WebDAV Current Principal
+ Extension", RFC 5397, December 2008.
+
+ [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
+ Uniform Resource Identifiers (URIs)", RFC 5785,
+ April 2010.
+
+ [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
+ URI Scheme", RFC 6068, October 2010.
+
+ [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
+ Verification of Domain-Based Application Service Identity
+ within Internet Public Key Infrastructure Using X.509
+ (PKIX) Certificates in the Context of Transport Layer
+ Security (TLS)", RFC 6125, March 2011.
+
+ [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
+ Cheshire, "Internet Assigned Numbers Authority (IANA)
+ Procedures for the Management of the Service Name and
+ Transport Protocol Port Number Registry", BCP 165,
+ RFC 6335, August 2011.
+
+ [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed
+ Authoring and Versioning (WebDAV)", RFC 6352, August 2011.
+
+ [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
+ Discovery", RFC 6763, February 2013.
+
+
+
+Daboo Standards Track [Page 13]
+
+RFC 6764 SRV for CalDAV & CardDAV February 2013
+
+
+11.2. Informative References
+
+ [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
+ Core Object Specification (iCalendar)", RFC 5545,
+ September 2009.
+
+Author's Address
+
+ Cyrus Daboo
+ Apple Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+ USA
+
+ EMail: cyrus at daboo.name
+ URI: http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 14]
+
Copied: CalendarServer/branches/users/gaya/directorybacker/doc/calendarserver_config.8 (from rev 10934, CalendarServer/trunk/doc/calendarserver_config.8)
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/doc/calendarserver_config.8 (rev 0)
+++ CalendarServer/branches/users/gaya/directorybacker/doc/calendarserver_config.8 2013-03-20 19:04:17 UTC (rev 10956)
@@ -0,0 +1,59 @@
+.\"
+.\" Copyright (c) 2006-2013 Apple Inc. All rights reserved.
+.\"
+.\" Licensed under the Apache License, Version 2.0 (the "License");
+.\" you may not use this file except in compliance with the License.
+.\" You may obtain a copy of the License at
+.\"
+.\" http://www.apache.org/licenses/LICENSE-2.0
+.\"
+.\" Unless required by applicable law or agreed to in writing, software
+.\" distributed under the License is distributed on an "AS IS" BASIS,
+.\" WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+.\" See the License for the specific language governing permissions and
+.\" limitations under the License.
+.\"
+.\" The following requests are required for all man pages.
+.Dd January 14, 2013
+.Dt CALENDARSERVER_CONFIG 8
+.Os
+.Sh NAME
+.Nm calendarserver_config
+.Nd Calendar Server Configuration Utility
+.Sh SYNOPSIS
+.Nm
+.Op Fl -config Ar file
+.Op key ...
+.Sh DESCRIPTION
+.Nm
+stores and retrieves configuration values for calendar server. It's primary
+purpose is to carry out operations on behalf of the Apple OS X Server
+administration application; in this mode of operation is reads stdin for
+keys provided in plist format, and writes results to stdout, also in plist
+form. For interactive use, you can list one or more keys as command line
+arguments.
+.Pp
+.Sh OPTIONS
+.Bl -tag -width flag
+.It Fl h, -help
+Displays usage information
+.It Fl f, -config Ar FILE
+Use the Calendar Server configuration specified in the given file.
+Defaults to /Applications/Server.app/Contents/ServerRoot/private/etc/caldavd/caldavd-apple.plist on Apple servers, /etc/caldavd/caldavd.plist on other servers.
+.El
+.Sh EXAMPLES
+Retrieve the value for EnableCalDAV
+.Pp
+.Dl "calendarserver_config EnableCalDAV"
+.Pp
+Set EnableCalDAV to True
+.Pp
+.Dl "calendarserver_config EnableCalDAV=True"
+.Pp
+.Sh FILES
+.Bl -tag -width flag
+.It /Applications/Server.app/Contents/ServerRoot/private/etc/caldavd/caldavd-apple.plist
+The static Calendar Server configuration file (not to be edited).
+.It /Library/Server/Calendar and Contacts/Config/caldavd-system.plist
+The configuration file which stores local overriding values (which calendarserver_config modifies).
+.El
Modified: CalendarServer/branches/users/gaya/directorybacker/support/Makefile.Apple
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/support/Makefile.Apple 2013-03-20 03:35:56 UTC (rev 10955)
+++ CalendarServer/branches/users/gaya/directorybacker/support/Makefile.Apple 2013-03-20 19:04:17 UTC (rev 10956)
@@ -36,7 +36,6 @@
Extra_Environment += PATH="$(SIPP)/usr/bin:$$PATH"
CALDAVDSUBDIR = /caldavd
-WEBAPPSSUBDIR = /apache2/webapps
PYTHON = $(USRBINDIR)/python
PY_HOME = $(SIPP)$(SHAREDIR)$(CALDAVDSUBDIR)
@@ -86,9 +85,6 @@
$(_v) for so in $$(find "$(DSTROOT)$(PY_HOME)/lib" -type f -name '*.so'); do $(STRIP) -Sx "$${so}"; done
$(_v) $(INSTALL_DIRECTORY) "$(DSTROOT)$(SIPP)$(ETCDIR)$(CALDAVDSUBDIR)"
$(_v) $(INSTALL_FILE) "$(Sources)/conf/caldavd-apple.plist" "$(DSTROOT)$(SIPP)$(ETCDIR)$(CALDAVDSUBDIR)/caldavd-apple.plist"
- $(_v) $(INSTALL_DIRECTORY) "$(DSTROOT)$(SIPP)$(ETCDIR)$(WEBAPPSSUBDIR)"
- $(_v) $(INSTALL_FILE) "$(Sources)/contrib/migration/com.apple.webapp.contacts.plist" "$(DSTROOT)$(SIPP)$(ETCDIR)$(WEBAPPSSUBDIR)/com.apple.webapp.contacts.plist"
- $(_v) $(INSTALL_FILE) "$(Sources)/contrib/migration/com.apple.webapp.contactsssl.plist" "$(DSTROOT)$(SIPP)$(ETCDIR)$(WEBAPPSSUBDIR)/com.apple.webapp.contactsssl.plist"
$(_v) chmod -R ugo+r "$(DSTROOT)$(PY_HOME)"
$(_v) for f in $$(find "$(DSTROOT)$(SIPP)$(ETCDIR)" -type f ! -name '*.default'); do cp "$${f}" "$${f}.default"; done
@@ -116,10 +112,6 @@
$(_v) $(INSTALL_DIRECTORY) "$(DSTROOT)$(SIPP)$(LIBEXECDIR)/changeip"
$(_v) $(INSTALL_FILE) "$(Sources)/calendarserver/tools/changeip_calendar.py" "$(DSTROOT)$(SIPP)$(LIBEXECDIR)/changeip/changeip_calendar.py"
$(_v) chmod ugo+x "$(DSTROOT)$(SIPP)$(LIBEXECDIR)/changeip/changeip_calendar.py"
- @echo "Installing certificate update scripts..."
- $(_v) $(INSTALL_DIRECTORY) "$(DSTROOT)$(SIPP)$(LIBEXECDIR)/certupdate"
- $(_v) $(INSTALL_FILE) "$(Sources)/contrib/certupdate/calendarcertupdate.py" "$(DSTROOT)$(SIPP)$(LIBEXECDIR)/certupdate/calendarcertupdate.py"
- $(_v) chmod ugo+x "$(DSTROOT)$(SIPP)$(LIBEXECDIR)/certupdate/calendarcertupdate.py"
install::
@echo "Installing CalDAVTester package..."
Modified: CalendarServer/branches/users/gaya/directorybacker/testserver
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/testserver 2013-03-20 03:35:56 UTC (rev 10955)
+++ CalendarServer/branches/users/gaya/directorybacker/testserver 2013-03-20 19:04:17 UTC (rev 10956)
@@ -26,6 +26,7 @@
verbose="";
serverinfo="${cdt}/scripts/server/serverinfo.xml";
printres="";
+subdir="";
usage ()
{
@@ -33,7 +34,8 @@
echo "Usage: ${program} [-v] [-s serverinfo]";
echo "Options:";
echo " -h Print this help and exit";
- echo " -d Set the CalDAVTester directory";
+ echo " -t Set the CalDAVTester directory";
+ echo " -d Set the script subdirectory";
echo " -s Set the serverinfo.xml";
echo " -r Print request and response";
echo " -v Verbose.";
@@ -42,11 +44,12 @@
exit 64;
}
-while getopts 'hvrd:s:' option; do
+while getopts 'hvrt:s:d:' option; do
case "$option" in
'?') usage; ;;
'h') usage -; exit 0; ;;
- 'd') cdt="${OPTARG}"; serverinfo="${OPTARG}/scripts/server/serverinfo.xml"; ;;
+ 't') cdt="${OPTARG}"; serverinfo="${OPTARG}/scripts/server/serverinfo.xml"; ;;
+ 'd') subdir="--subdir ${OPTARG} "; ;;
's') serverinfo="${OPTARG}"; ;;
'r') printres="--always-print-request --always-print-response"; ;;
'v') verbose="v"; ;;
@@ -65,5 +68,5 @@
source "${wd}/support/shell.sh";
-cd "${cdt}" && "${python}" testcaldav.py --print-details-onfail ${printres} -s "${serverinfo}" "$@";
+cd "${cdt}" && "${python}" testcaldav.py --print-details-onfail ${printres} -s "${serverinfo}" "${subdir}""$@";
Modified: CalendarServer/branches/users/gaya/directorybacker/twext/python/sendfd.py
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/twext/python/sendfd.py 2013-03-20 03:35:56 UTC (rev 10955)
+++ CalendarServer/branches/users/gaya/directorybacker/twext/python/sendfd.py 2013-03-20 19:04:17 UTC (rev 10956)
@@ -15,7 +15,7 @@
# limitations under the License.
##
-from struct import pack, unpack
+from struct import pack, unpack, calcsize
from socket import SOL_SOCKET
from twext.python.sendmsg import sendmsg, recvmsg, SCM_RIGHTS
@@ -62,5 +62,10 @@
# cmsg_level and cmsg_type really need to be SOL_SOCKET / SCM_RIGHTS, but
# since those are the *only* standard values, there's not much point in
# checking.
- [unpackedFD] = unpack("i", packedFD)
+ unpackedFD = 0
+ int_size = calcsize("i")
+ if len(packedFD) > int_size: # [ar]happens on 64 bit architecture (FreeBSD)
+ [unpackedFD] = unpack("i", packedFD[0:int_size])
+ else:
+ [unpackedFD] = unpack("i", packedFD)
return (unpackedFD, data)
Modified: CalendarServer/branches/users/gaya/directorybacker/twistedcaldav/scheduling/ischedule/utils.py
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/twistedcaldav/scheduling/ischedule/utils.py 2013-03-20 03:35:56 UTC (rev 10955)
+++ CalendarServer/branches/users/gaya/directorybacker/twistedcaldav/scheduling/ischedule/utils.py 2013-03-20 19:04:17 UTC (rev 10956)
@@ -41,10 +41,13 @@
@return: a C{set} of IPs
"""
ips = set()
- for family in (socket.AF_INET, socket.AF_INET6):
- results = socket.getaddrinfo(host, None, family, socket.SOCK_STREAM)
- for _ignore_family, _ignore_socktype, _ignore_proto, _ignore_canonname, sockaddr in results:
- ips.add(sockaddr[0])
+ # Use AF_UNSPEC rather than iterating (socket.AF_INET, socket.AF_INET6)
+ # because getaddrinfo() will raise an exception if no match is found for
+ # the specified family
+ # TODO: potentially use twext.internet.gaiendpoint instead
+ results = socket.getaddrinfo(host, None, socket.AF_UNSPEC, socket.SOCK_STREAM)
+ for _ignore_family, _ignore_socktype, _ignore_proto, _ignore_canonname, sockaddr in results:
+ ips.add(sockaddr[0])
return ips
Modified: CalendarServer/branches/users/gaya/directorybacker/txdav/base/propertystore/xattr.py
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/txdav/base/propertystore/xattr.py 2013-03-20 03:35:56 UTC (rev 10955)
+++ CalendarServer/branches/users/gaya/directorybacker/txdav/base/propertystore/xattr.py 2013-03-20 19:04:17 UTC (rev 10956)
@@ -47,7 +47,7 @@
# expose. Its value is 93.
#
-if sys.platform in ("darwin", "freebsd8"):
+if sys.platform in ("darwin", "freebsd8", "freebsd9"):
_ERRNO_NO_ATTR = getattr(errno, "ENOATTR", 93)
else:
_ERRNO_NO_ATTR = errno.ENODATA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20130320/83e8198a/attachment-0001.html>
More information about the calendarserver-changes
mailing list