[CalendarServer-changes] [10884] CalendarServer/branches/users/gaya/directorybacker/doc/Admin
source_changes at macosforge.org
source_changes at macosforge.org
Sat Mar 9 22:53:37 PST 2013
Revision: 10884
http://trac.calendarserver.org//changeset/10884
Author: gaya at apple.com
Date: 2013-03-09 22:53:37 -0800 (Sat, 09 Mar 2013)
Log Message:
-----------
merge from trunk
Added Paths:
-----------
CalendarServer/branches/users/gaya/directorybacker/doc/Admin/iSchedule.txt
Removed Paths:
-------------
CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-Apache.txt
CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-OpenDirectory.txt
CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-XML.txt
CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryServices.txt
CalendarServer/branches/users/gaya/directorybacker/doc/Admin/ExtendedLogItems.txt
CalendarServer/branches/users/gaya/directorybacker/doc/Admin/LoadSimulation.txt
CalendarServer/branches/users/gaya/directorybacker/doc/Admin/MultiServerDeployment.txt
Deleted: CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-Apache.txt
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-Apache.txt 2013-03-10 06:47:33 UTC (rev 10883)
+++ CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-Apache.txt 2013-03-10 06:53:37 UTC (rev 10884)
@@ -1,112 +0,0 @@
-Apache Directory Services
-=========================
-
-**WARNING:** *This directory service implementation is experimental,
-incomplete and not supported.*
-
-The Apache directory services provide principal information that is
-read from configuration files in the `same formats`_ as used by the
-`Apache HTTP server`_, allowing you to easily share user and group
-information with an Apache server.
-
-.. _same formats: http://httpd.apache.org/docs/2.3/howto/auth.html
-.. _Apache HTTP server: http://httpd.apache.org/
-
-The Apache directory services provide principal information for users
-and groups. They do not provide principal information for locations or
-resources.
-
-Configuring the Calendar Server
--------------------------------
-
-The full name of the service is either
-``twistedcaldav.directory.apache.BasicDirectoryService`` or
-``twistedcaldav.directory.apache.DigestDirectoryService``. These
-services implement `basic and digest HTTP authentication`_,
-respectively.
-
-.. _basic and digest HTTP authentication: http://www.ietf.org/rfc/rfc2617.txt
-
-Both services take a ``userFile`` parameter which contains the name of
-the file to read user principal information from and an optional
-``groupFile`` parameter which contains the name of the file to read
-group principal information from.
-
-For example, if you are using digest:
-
-::
-
- <!-- Apache-style Digest Directory Service -->
- <key>DirectoryService</key>
- <dict>
- <key>type</key>
- <string>twistedcaldav.directory.apache.DigestDirectoryService</string>
-
- <key>params</key>
- <dict>
- <key>userFile</key>
- <string>conf/digest</string>
- <key>groupFile</key>
- <string>conf/group</string>
- </dict>
- </dict>
-
-The service re-reads the user and group files if either file's
-timestamp changes, so edits to the files do not require a server
-restart.
-
-Note that basic authentication is highly insecure because it sends
-password information in plain text over the network (where is may be
-intercepted) and should not be enabled on a server unless all
-connections are somehow secured by another means, such as by enabling
-SSL and disabling non-SSL connections.
-
-Configuring Principals
-----------------------
-
-In the case of ``BasicDirectoryService``, the user file must be in the
-form generated by the Apache ``htpasswd`` command; in the case of
-``DigestDirectoryService``, the user file must be in the form
-generated by the Apache ``htdigest`` command.
-
-Both user file formats contain a single entry per line, with fields
-separated by the colon (``:``) character. The basic format has two
-fields, one containing a user identifier and the second containing the
-user's password in the UNIX crypt format. The digest format has three
-fields: a user identifier, a realm name, and the user's hashed
-password.
-
-An example basic user file:
-
-::
-
- wsanchez:Cytm0Bwm7CPJs
- cdaboo:I.Ef5FJl5GVh2
- dreid:LVhqAv4qSrYPs
- lecroy:/7/5VDrkrLxY.
-
-And an example digest user file:
-
-::
-
- wsanchez:Test:decbe233ab3d997cacc2fc058b19db8c
- cdaboo:Test:61164bf3d607d072fe8a7ac420b24aac
- dreid:Test:8ee67801004b2752f72b84e7064889a6
- lecroy:Test:60d4feb424430953be045738041e51be
-
-The group file is in a similar format, with one entry of
-colon-separated field per line. Each line has two fields: a group
-identifier, and a comma- (``,``) separated list of user identifiers
-which identify the members of the group.
-
-And example group file:
-
-::
-
- managers: lecroy
- grunts: wsanchez, cdaboo, dreid
- right_coast: cdaboo
- left_coast: wsanchez, dreid, lecroy
-
-The user files should be edited using the ``htpasswd`` and
-``htdigest`` tools. The group file is typically edited by hand.
Deleted: CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-OpenDirectory.txt
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-OpenDirectory.txt 2013-03-10 06:47:33 UTC (rev 10883)
+++ CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-OpenDirectory.txt 2013-03-10 06:53:37 UTC (rev 10884)
@@ -1,44 +0,0 @@
-Open Directory Service
-======================
-
-The Open Directory directory service provides principal information
-that is obtained using Apple's Open Directory service.
-
-Open Directory provides principal information for users, groups,
-locations, and resources.
-
-For more information about configuring Open Directory and running Open
-Directory services, see Apple's `Open Directory Administration`_
-document.
-
-.. _Open Directory Administration: http://images.apple.com/server/macosx/docs/Open_Directory_Admin_v10.6.pdf
-
-Configuring the Calendar Server
--------------------------------
-
-The full name of the service is
-``twistedcaldav.directory.appleopendirectory.OpenDirectoryService``
-and the service takes a ``node`` parameter which contains the name of
-the directory node to bind to.
-
-For example:
-
-::
-
- <!-- Open Directory Service -->
- <key>DirectoryService</key>
- <dict>
- <key>type</key>
- <string>twistedcaldav.directory.appleopendirectory.OpenDirectoryService</string>
-
- <key>params</key>
- <dict>
- <key>node</key>
- <string>/Search</string>
- </dict>
- </dict>
-
-The special Open Directory node ``/Search`` causes the server to use
-the default directory search path that the host system the server is
-running on is configured to use. To bind to a specific LDAP service, a
-node in the form ``/LDAPv3/ldapserver.example.com`` may be specified.
Deleted: CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-XML.txt
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-XML.txt 2013-03-10 06:47:33 UTC (rev 10883)
+++ CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryService-XML.txt 2013-03-10 06:53:37 UTC (rev 10884)
@@ -1,159 +0,0 @@
-XML Directory Service
-=====================
-
-The XML directory service provides principal information that is read
-from an XML file.
-
-The XML file provides principal information for users, groups,
-locations, and resources.
-
-One advantage to this directory service implementation is that it does
-not require a networked directory server to be running somewhere,
-instead simply relying on a file.
-
-Configuring the Calendar Server
--------------------------------
-
-The full name of the service is
-``twistedcaldav.directory.xmlfile.XMLDirectoryService`` and the
-service takes an ``xmlFile`` parameter which contains the name of the
-XML file to read principal information from.
-
-For example:
-
-::
-
- <!-- XML File Directory Service -->
- <key>DirectoryService</key>
- <dict>
- <key>type</key>
- <string>twistedcaldav.directory.xmlfile.XMLDirectoryService</string>
-
- <key>params</key>
- <dict>
- <key>xmlFile</key>
- <string>/etc/caldavd/accounts.xml</string>
- </dict>
- </dict>
-
-The service re-reads the XML file if it's timestamp changes, so edits
-to the XML file do not require a server restart.
-
-Configuring Principals
-----------------------
-
-Principals are expressed in an XML document. The root element
-``accounts`` has an attribute ``realm`` which describes the
-authentication realm. It contains principal elements which in turn
-contain elements describing the principal. The element itself
-(``user``, ``group``, ``location``, ``resource``) denotes the
-principal type.
-
-Principal elements can contain the following elements which provide
-information about the principal:
-
-``uid``
-
- The login identifier for the principal (ie. "user name" or "short
- name").
-
-``guid``
-
- A globally unique identifier for the principal. Must be a UUID
- string that complies with `RFC 4122`_.
-
- .. _RFC 4122: http://tools.ietf.org/html/rfc4122
-
-``password``
-
- The principal's password in plain text.
-
-``name``
-
- The principal's full name (or description).
-
-``members``
-
- A list of uids for the principals which are members of the principal
- being defined. Only group principals may have members. The
- ``members`` element has ``member`` sub-elements used to specify each
- member. The member element has a type attribute that defines the
- principal type of the member (one of ``users``, ``groups``,
- ``locations`` and ``resources``), and the text value inside the
- ``member`` element is the corresponding uid of the principal being
- referenced. Any principal may be a member of a group, including
- other groups. One should avoid creating "loops" by having two groups
- include each other.
-
-``cuaddr``
-
- A "calendar user address" for the principal. Principals may have
- multiple calendar user addresses, but a calendar user addresses must
- be unique to one principal. A calendar user address must be a URI_.
-
- .. _URI: http://tools.ietf.org/html/rfc2396
-
- Note that calendar user addresses here supplement any calendar user
- addresses that are assigned by the server based on other principal
- information.
-
-``disable-calendar``
-
- When present, this element indicates that the principal is able to
- login to the calendar server, but is not provided a calendar home
- and therefore cannot do scheduling. This type of principal is
- typically used to allow access to the calendars of other principals
- or other data on the server. This element may only pecified for user
- principals.
-
-``auto-schedule``
-
- Indicates that the server will automatically process scheduling
- messages for the corresponding principal. For example, when a
- scheduling message arrives, if it does not conflict with an existing
- meeting it will be automatically accepted into the principal's main
- calendar; if it does conflict it will be automatically
- declined. This element can only be defined on location and resource
- principals.
-
-``proxies``
-
- Contains a list of ``member`` elements that define which other
- principals have read-write proxy access to the corresponding
- principal's calendar data.
-
-An example:
-
-::
-
- <?xml version="1.0" encoding="utf-8"?>
- <accounts realm="Test Realm">
- <user>
- <uid>admin</uid>
- <password>admin</password>
- <name>Super User</name>
- </user>
- <user>
- <uid>test</uid>
- <password>test</password>
- <name>Test User</name>
- <cuaddr>mailto:testuser at example.com</cuaddr>
- </user>
- <group>
- <uid>users</uid>
- <password>users</password>
- <name>Users Group</name>
- <members>
- <member type="users">test</member>
- </members>
- </group>
- <location>
- <uid>mercury</uid>
- <password>mercury</password>
- <name>Mecury Conference Room, Building 1, 2nd Floor</name>
- <auto-schedule/>
- <proxies>
- <member type="users">test</member>
- </proxies>
- </location>
- </accounts>
Deleted: CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryServices.txt
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryServices.txt 2013-03-10 06:47:33 UTC (rev 10883)
+++ CalendarServer/branches/users/gaya/directorybacker/doc/Admin/DirectoryServices.txt 2013-03-10 06:53:37 UTC (rev 10884)
@@ -1,93 +0,0 @@
-Directory Services
-==================
-
-The Calendar Server needs to be able to obtain information about the
-users, groups and resources ("principals") which access and/or have a
-presence on the server.
-
-About Principals
-----------------
-
-All principals have a "principal resource" on the server which
-represents the principal in the form of an HTTP resource. This is
-useful for obtaining information about a principal, such as the URL of
-the principal's calendar home, the principal's members and/or
-memberships, and so on. This information is exposed via WebDAV
-properties on the principal resource.
-
-Principals can be used to configure access controls for resources on
-the server by granting or denying various privileges to the principal.
-Privileges granted or denied to group principals are also granted or
-denied to all members of the group.
-
-Some principals (often, but not necessarily all) are also given a
-calendar home collection on the server, in which the principal may
-have one or more calendar collections, as well as special collections
-which allow the principals to schedule meetings with others, and so
-on.
-
-The Role of a Directory Service
--------------------------------
-
-A "directory service" is simply an entity which contains information
-about principals.
-
-Directory services are interchangeable, which allows the server to
-obtain this information from a variety of data stores, such as
-configuration files or network directory systems like LDAP.
-
-Most directory services refer to principals as "records" in their
-databases. Internally, Calendar Server will map records from a
-directory service to WebDAV principals.
-
-A given directory service may classify records into "types" such as
-users, groups, resources, and so on. Calendar Server keeps this
-distinction, and some types are treated specially.
-
-Principal types commonly provided by directory services include:
-
-users
-
- Individual (typically human) users of the system.
-
-groups
-
- Principals that contain other principals ("members"). Members can be
- principals of any type, including other group principals.
-
-locations
-
- Locations that can be scheduled.
-
-resources
-
- Other resources (eg. projectors) which can be scheduled.
-
-For example, only user principals are allowed to authenticate with
-(log into) the server. Only group principals have members, and group
-principals do not have calendars.
-
-
-Configuration
-=============
-
-The directory service used by the server is configured in the
-``caldavd.plist`` file by specifying the directory service
-implementation to use, as well as its configuration options. Options
-are specified as a dictionary.
-
-The configuration syntax looks like this:
-
-::
-
- <key>DirectoryService</key>
- <dict>
- <key>type</key>
- <string>ExampleService</string>
-
- <key>params</key>
- <dict>
- <key>option</key>
- <string>value</string>
- </dict>
- </dict>
Deleted: CalendarServer/branches/users/gaya/directorybacker/doc/Admin/ExtendedLogItems.txt
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/doc/Admin/ExtendedLogItems.txt 2013-03-10 06:47:33 UTC (rev 10883)
+++ CalendarServer/branches/users/gaya/directorybacker/doc/Admin/ExtendedLogItems.txt 2013-03-10 06:53:37 UTC (rev 10884)
@@ -1,110 +0,0 @@
-Apache-style Access Log Extensions
-==================================
-
-Calendar Server extends the Apache log file format it uses by:
-
- * Adding a "sub-method" to the HTTP method field.
- * Adding key-value pairs at the end of log lines.
-
-The sub-method is adding by appending the name of the sub-method in
-parentheses to the original HTTP request method. This is used to
-clarify what operation is going on for HTTP methods that are commonly
-used to tunnel other operations, such as ``POST`` and ``REPORT``. For
-example, CalDAV uses ``POST`` for free/busy lookups, and ``REPORT``
-can be used to make any sort of query.
-
-Key-value pairs are used to provide additional details about the
-request. They are added to the end of the line as new fields in the
-form ``key=value``.
-
-These keys are always emitted:
-
- ``i``
-
- the port number of the server instance emitting the log
-
- ``t``
-
- the amount of time spent processing the request (in milliseconds).
-
- ``or``
-
- the number of outstanding requests enqueued for the server
- instance emitting the log entry.
-
-Keys that may be emitted depending on the client request and server
-response include:
-
- ``rcount``
-
- the number of resources specified in a ``MULTIGET`` request.
-
- ``responses``
-
- the number of responses included in a ``multi-status`` response to
- a ``PROPFIND`` request or a CalDAV ``calendar-query`` request.
-
- ``recipients``
-
- the number of recipients in a CalDAV scheduling request via
- ``POST`` (which are typically only free/busy requests).
-
- ``itip.requests``
-
- the number of attendees in a scheduling operation triggered by an
- Organizer.
-
- ``itip.refreshes``
-
- the number of attendee refreshes completed after a scheduling
- operation.
-
- ``itip.auto``
-
- the number of auto-accept attendees specified
-
- ``itip.reply``
-
- Either ``reply`` or ``cancel`` depending on...???
-
- ``fwd``
-
- the value of the X-Forwarded-For header, if present
-
-In the following example, we see a ``CalDAV:calendar-multiget``
-``REPORT`` for 32 resources in a user's calendar, which was handled by
-instance ``8459`` in 183.0ms, with one outstanding request (the one
-being logged):
-
-::
-
- 17.108.160.37 - scastillo [15/Sep/2009:20:10:23 +0000] "REPORT(CalDAV:calendar-multiget) /calendars/__uids__/B8CE9430-965B-11DE-B626-EC2E9DB52B69/calendar/ HTTP/1.1" 207 149285 "-" "DAVKit/4.0 (729); CalendarStore/4.0 (965); iCal/4.0 (1362); Mac OS X/10.6.1 (10B504)" i=8459 t=183.0 or=1 rcount=32
-
-
-
-**Fine-grained request time logging**
-
-If the configuration key EnableExtendedTimingAccessLog is set to true, additional key-value pairs will be logged with each request. The overall request time "t" is broken into four phases, and the elapsed time for each phase is logged. The new keys representing the four request phases are:
-
- ``t-req-proc``
-
- time elapsed from when a request object is created up until renderHTTP is about to be called.
- This is the overhead of parsing the request headers and locating the target resource.
-
- ``t-resp-gen``
-
- time elapsed from t-req-proc up until the response is ready to write
-
- ``t-resp-wr``
-
- time elapsed from t-resp-gen up until response is written
-
- ``t-log``
-
- time from t-resp-wr up until log entry is ready to write to master
-
-A sample log line with EnableExtendedTimingAccessLog enabled is shown below:
-
-::
-
- 17.209.103.42 - wsanchez [24/Jul/2012:17:51:29 +0000] "REPORT(CalDAV:calendar-multiget) /calendars/__uids__/F114CA1D-295F-42A5-A5BD-D1A1B19FC049/60E68E32-4C87-4E63-9BF2-12A25E8F2623/ HTTP/1.1" 207 114349 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50d)" i=7 or=1 t=764.7 t-req-proc=4.8 t-resp-gen=754.5 t-resp-wr=5.1 t-log=0.2 rcount=2
\ No newline at end of file
Deleted: CalendarServer/branches/users/gaya/directorybacker/doc/Admin/LoadSimulation.txt
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/doc/Admin/LoadSimulation.txt 2013-03-10 06:47:33 UTC (rev 10883)
+++ CalendarServer/branches/users/gaya/directorybacker/doc/Admin/LoadSimulation.txt 2013-03-10 06:53:37 UTC (rev 10884)
@@ -1,338 +0,0 @@
-==========================
-Load Simulation
-==========================
-
-Calendar Server includes a flexible, scalable, and easy to use `client simulator <http://trac.calendarserver.org/browser/CalendarServer/trunk/contrib/performance/loadtest>`_ that provides behaviors modeled after Apple's iCal client in Mac OS X 10.6. This sim has a highly modular architecture with the goal of making it as easy as possible to add new behaviors, or entirely new clients. The sim can be used to validate server correctness, and also for performance and scalability testing.
-
-This document contains the following sections:
-
-* `Quick Start`_: Instructions to get the sim up and running from an SVN checkout of Calendar Server
-
-* `Reporting`_: The sim emits both real-time logging during runtime, and also a summary at the end that includes quality of service evaluations
-
-* `Configuration`_: Describes the load sim's configuration options, how to enable / disable certain behaviors, adjust frequency of events, etc
-
-* `Scalability`_: Through the use of an AMP harness, you may easily add additional sim instances on the local host and / or remote hosts
-
----------------------
-Quick Start
----------------------
-
-The sim's default config is pre-configured to work against the Calendar Server's default config (caldavd-test.plist), so we'll use that for this quick start.
-
-- Start Calendar Server using the -test configuration. For further detail on this, see: http://trac.calendarserver.org/wiki/QuickStart
-- Open another shell and cd into the Calendar Server SVN root
-- Start the sim:
-
-::
-
- ./sim
-
-The sim should begin logging its activity, which might look something like:
-
-::
-
- Loaded 99 accounts.
- user01 - - - - - - - - - - - startup BEGIN
- user01 request 207✓[ 0.04 s] PROPFIND /principals/users/user01/
- user01 request 207✓[ 0.02 s] PROPFIND /principals/__uids__/user01/
- user01 request 200✓[ 0.01 s] REPORT /principals/
- user01 - - - - - - - - - - - poll BEGIN
- user01 request 207✓[ 0.19 s] PROPFIND /calendars/__uids__/user01/
- ...
-
-- To stop the sim, simply cntrl-c it.
-
----------------------
-Reporting
----------------------
-
-Runtime Reporting
------------------
-
-While running, the sim will log its activity to stdout. Simulator activity is organized into a two-level hierarchy: client behaviors (e.g. create event, poll, respond to events) which are composed of individual HTTP requests (e.g. GET, PUT, DELETE, etc).
-
-For example, the sim logs the following right at startup as it initializes the users:
-
-::
-
- user01 - - - - - - - - - - - startup BEGIN
- user01 request 207✓[ 0.04 s] PROPFIND /principals/users/user01/
- user01 request 207✓[ 0.02 s] PROPFIND /principals/__uids__/user01/
- user01 request 200✓[ 0.01 s] REPORT /principals/
- user01 - - - - - - - - - - - poll BEGIN
- user01 request 207✓[ 0.29 s] PROPFIND /calendars/__uids__/user01/
- user01 request 207✓[ 0.04 s] PROPFIND /calendars/__uids__/user01/calendar/
- user01 request 207✓[ 0.04 s] PROPFIND /calendars/__uids__/user01/inbox/
- user01 request 207✓[ 0.05 s] PROPFIND /calendars/__uids__/user01/tasks/
- user01 request 207✓[ 0.02 s] PROPFIND /calendars/__uids__/user01/outbox/
- user01 request 207✓[ 0.03 s] PROPFIND /calendars/__uids__/user01/dropbox/
- user01 request 207✓[ 0.03 s] PROPFIND /calendars/__uids__/user01/notification/
- user01 - - - - - - - - - - - poll END [ 0.51 s]
- user01 - - - - - - - - - - - startup END [ 0.59 s]
-
-The first token on each line is the username associated with the activity. Most of the time, client activity is interleaved, so to trace a specific client you may wish to filter for a specific username.
-
-Client operations are groups of requests that are surrounded by lines with many dashes, either BEGIN or END. 'END' lines also include the overall duration of the operation, which is the elapsed wall clock time since the operation started.
-
-Above, we see two behaviors that are nested; the 'startup' operation starts which includes a few requests and also triggers the 'poll' operation.
-
-Individual requests are logged with the word 'request', followed by the HTTP status, the request duration, the HTTP method of the request, and the URI that is being targeted. Successful requests are indicated by a ✓ while failed requests are indicated with —✗.
-
-Most client operations also log a 'lag' time when they start, e.g.
-
-::
-
- user12 - - - - - - - - - - - create BEGIN {lag 0.80 ms}
-
-'lag' in this context specifies the time elapsed between when the sim should have started this operation (based on internal timers / activity distributions) and when it actually did. This is intended to be a measure of client sim health; if the lag values begin to grow too high, that indicates that the client sim is 'slipping' and doesn't have enough CPU to perform its various activities at the rates specified in the config file. This is python, so a single instance of the client sim is limited to one CPU core. See the `Scalability`_ section for information about how to scale the load sim by combining multiple instances.
-
-Summary Reports
----------------
-When the sim stops or is killed, it emits a summary report that displays the total number of users that were active in this run, and overall counts for both individual requests and also the higher-level client operations. Also we display quality of service information used to grade the run as PASS or FAIL. An example report is shown below::
-
- Users : 20
- request count failed >3sec mean median
- DELETE 21 0 0 0.0186 0.0184
- GET 27 0 0 0.0341 0.0223
- POST 17 0 0 0.0709 0.0523
- PROPFIND 265 0 0 0.0593 0.0262
- PUT 44 0 2 0.3544 0.1735
- REPORT 107 0 0 0.0599 0.0280
-
- operation count failed >3sec mean median avglag (ms)
- accept 10 0 0 0.2808 0.2942 0.8490
- create 17 0 0 0.0560 0.0484 1.0024
- invite 17 0 2 0.8713 0.4774 0.9585
- poll 64 0 0 0.3856 0.3234 0.0000
- reply done 12 0 0 0.0177 0.0174 1.9181
- startup 20 0 0 0.7369 0.6023 0.0000
- PASS
-
-The pass / fail criteria are defined in `contrib/performance/loadtest/profiles.py <http://trac.calendarserver.org/browser/CalendarServer/trunk/contrib/performance/loadtest/profiles.py>`_ for operations and `contrib/performance/loadtest/population.py <http://trac.calendarserver.org/browser/CalendarServer/trunk/contrib/performance/loadtest/population.py>`_ for individual requests, and are generally derived from execution time and failure rate.
-
----------------------
-Configuration
----------------------
-
-The client sim's default configuration file is found here::
-
- contrib/performance/loadtest/config.plist
-
-The config file defines
-
-- how to connect to the server
-- which user accounts to use
-- client 'arrival' policy, which specifies how many of the available accounts to use, and how quickly they are initialized
-- which client behaviors are performed, along with optional configuration of each behavior
-
-Server Specification
----------------------
-
-Specify the URI to which the client sim should connect, e.g::
-
- <!-- Identify the server to be load tested. -->
- <key>server</key>
- <string>https://127.0.0.1:8443/</string>
-
-User Accounts
--------------
-
-User accounts are defined in the 'accounts' key of the plist:
-
-::
-
- <!-- Define the credentials of the clients which will be used to load test
- the server. These credentials must already be valid on the server. -->
- <key>accounts</key>
- <dict>
- <!-- The loader is the fully-qualified Python name of a callable which
- returns a list of directory service records defining all of the client accounts
- to use. contrib.performance.loadtest.sim.recordsFromCSVFile reads username,
- password, mailto triples from a CSV file and returns them as a list of faked
- directory service records. -->
- <key>loader</key>
- <string>contrib.performance.loadtest.sim.recordsFromCSVFile</string>
-
- <!-- Keyword arguments may be passed to the loader. -->
- <key>params</key>
- <dict>
- <!-- recordsFromCSVFile interprets the path relative to the config.plist,
- to make it independent of the script's working directory while still allowing
- a relative path. This isn't a great solution. -->
- <key>path</key>
- <string>contrib/performance/loadtest/accounts.csv</string>
- </dict>
- </dict>
-
-The accounts.csv file has lines like shown below::
-
- user01,user01,User 01,user01 at example.com
-
-Client Arrival
-----------------
-
-This section configures the number of accounts to use, and defines how quickly clients are initialized when the sim starts::
-
- <!-- Define how many clients will participate in the load test and how
- they will show up. -->
- <key>arrival</key>
- <dict>
-
- <!-- Specify a class which creates new clients and introduces them into
- the test. contrib.performance.loadtest.population.SmoothRampUp introduces
- groups of new clients at fixed intervals up to a maximum. The size of the
- group, interval, and maximum are configured by the parameters below. The
- total number of clients is groups * groupSize, which needs to be no larger
- than the number of credentials created in the accounts section. -->
- <key>factory</key>
- <string>contrib.performance.loadtest.population.SmoothRampUp</string>
-
- <key>params</key>
- <dict>
- <!-- groups gives the total number of groups of clients to introduce. -->
- <key>groups</key>
- <integer>20</integer>
-
- <!-- groupSize is the number of clients in each group of clients. It's
- really only a "smooth" ramp up if this is pretty small. -->
- <key>groupSize</key>
- <integer>1</integer>
-
- <!-- Number of seconds between the introduction of each group. -->
- <key>interval</key>
- <integer>3</integer>
- </dict>
-
- </dict>
-
-In the default configuration, one client is initialized every 3 seconds, until 20 clients are initialized. As soon as a client is initialized, it begins to perform its specified behaviors at the configured rates (see "Client Behaviors").
-
-To increase the client load, increase the number of groups.
-
-To increase the rate at which clients are initialized, reduce 'interval' and / or increase 'groupSize'
-
-Remember: **The total number of clients is groups * groupSize, which needs to be no larger than the number of credentials created in the accounts section**
-
-Client Behaviors
-----------------
-
-The 'clients' plist key is an array of dictionaries, where each dict has the keys:
-
-- 'software', which specifies the implementation class for this client. For example:
-
-::
-
- <key>software</key>
- <string>contrib.performance.loadtest.ical.SnowLeopard</string>
-
-- 'params', optionally specifying parameters accepted by this software. For example:
-
-::
-
- <!-- Arguments to use to initialize the SnowLeopard instance. -->
- <key>params</key>
- <dict>
- <!-- SnowLeopard can poll the calendar home at some interval. This is
- in seconds. -->
- <key>calendarHomePollInterval</key>
- <integer>30</integer>
-
- <!-- If the server advertises xmpp push, SnowLeopard can wait for notifications
- about calendar home changes instead of polling for them periodically. If
- this option is true, then look for the server advertisement for xmpp push
- and use it if possible. Still fall back to polling if there is no xmpp push
- advertised. -->
- <key>supportPush</key>
- <false />
- </dict>
-
-- 'profiles' is an array of dictionaries specifying individual behaviors of this software. Each dict has a 'class' key which specifies the implementation class for this behavior, and a 'params' dict with options specific to that behavior. For example:
-
-::
-
- <!-- This profile accepts invitations to events, handles cancels, and
- handles replies received. -->
- <dict>
- <key>class</key>
- <string>contrib.performance.loadtest.profiles.Accepter</string>
-
- <key>params</key>
- <dict>
- <key>enabled</key>
- <true/>
-
- <!-- Define how long to wait after seeing a new invitation before
- accepting it. -->
- <key>acceptDelayDistribution</key>
- <dict>
- <key>type</key>
- <string>contrib.performance.stats.NormalDistribution</string>
- <key>params</key>
- <dict>
- <!-- mean -->
- <key>mu</key>
- <integer>60</integer>
- <!-- standard deviation -->
- <key>sigma</key>
- <integer>60</integer>
- </dict>
- </dict>
- </dict>
- </dict>
-
-Some parameters may be safely modified to suit your purposes, for example you might choose to disable certain profiles (by setting 'enabled' to false) in order to simulate only specific types of activity. Also, you can edit the params for the various distributions to configure how often things happen.
-
-Motivated readers may also develop new behaviors for existing clients, or even entirely new clients. An example of adding a new behavior to an existing client can be found here: http://trac.calendarserver.org/changeset/8428. As of this writing, we have only the one Snow Leopard client simulator, and would happily accept patches that implement additional clients!
-
----------------------
-Scalability
----------------------
-
-A good amount of activity can be generated by a single client sim instance, and that should be suitable for most cases. However, if your task is performance or scalability testing, you will likely want to generate more load than can be presented by a single CPU core (which is all you can get from a single Python process). By adding a 'workers' array to the sim's config file you can specify the use of additional sim instances on the local host, and / or remote hosts. In this configuration, the master process will distribute work across all the workers. In general, you shouldn't need additional workers unless you are approaching CPU saturation for your existing sim instance(s). The "lag" statistic is another useful metric for determining whether the client sim is hitting its targets - if it gets too high, consider adding workers.
-
-The specific approach you take when configuring a high load depends on your goals and available resources. If your goal is to beat down a server until it melts into the floor, it is legitimate to use a less accurate simulation by reducing the timers and intervals in the client sim's behavior configuration. If instead you wish to see how many 'realistic' clients your server can service, you will want to stick with reasonable values for timers and intervals, and instead increase load by configuring more user accounts (in the 'arrival' section of the config file, and the separate user accounts file).
-
-To use four instances on the local host::
-
- <key>workers</key>
- <array>
- <string>./python contrib/performance/loadtest/ampsim.py</string>
- <string>./python contrib/performance/loadtest/ampsim.py</string>
- <string>./python contrib/performance/loadtest/ampsim.py</string>
- <string>./python contrib/performance/loadtest/ampsim.py</string>
- </array>
-
-To use four instances each on two different remote hosts, use something like::
-
- <key>workers</key>
- <array>
- <string>exec ssh blade2 'cd ~/ccs/CalendarServer ; exec ./python contrib/performance/loadtest/ampsim.py'</string>
- <string>exec ssh blade2 'cd ~/ccs/CalendarServer ; exec ./python contrib/performance/loadtest/ampsim.py'</string>
- <string>exec ssh blade2 'cd ~/ccs/CalendarServer ; exec ./python contrib/performance/loadtest/ampsim.py'</string>
- <string>exec ssh blade2 'cd ~/ccs/CalendarServer ; exec ./python contrib/performance/loadtest/ampsim.py'</string>
- <string>exec ssh blade3 'cd ~/ccs/CalendarServer ; exec ./python contrib/performance/loadtest/ampsim.py'</string>
- <string>exec ssh blade3 'cd ~/ccs/CalendarServer ; exec ./python contrib/performance/loadtest/ampsim.py'</string>
- <string>exec ssh blade3 'cd ~/ccs/CalendarServer ; exec ./python contrib/performance/loadtest/ampsim.py'</string>
- <string>exec ssh blade3 'cd ~/ccs/CalendarServer ; exec ./python contrib/performance/loadtest/ampsim.py'</string>
- </array>
-
-**When using remote hosts, the ssh commands must work in an unattended fashion, so configure SSH keys as needed**. Also, each remote host needs to have a Calendar Server SVN checkout. In this example, the hosts blade2 and blade3 need to have an SVN checkout of Calendar Server at ~/ccs/CalendarServer.
-
-Configuration of the additional workers is handled by the master, so you need not distribute the sim's config file to the other hosts. Each instance gets an identical copy of the config. The amount of work attempted by the sim is not changed by adding workers; instead, the master distributes work (i.e. user accounts) across the workers. To do more work, add user accounts.
-
-When running the sim using multiple instances, the standard output of each child instance is sent to the master. For example, when starting with four instances::
-
- Loaded 99 accounts.
- Initiating worker configuration
- Initiating worker configuration
- Initiating worker configuration
- Initiating worker configuration
- Worker configuration complete.
- Worker configuration complete.
- Worker configuration complete.
- Worker configuration complete.
- user01 - - - - - - - - - - - startup BEGIN
- ...
-
-
Deleted: CalendarServer/branches/users/gaya/directorybacker/doc/Admin/MultiServerDeployment.txt
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/doc/Admin/MultiServerDeployment.txt 2013-03-10 06:47:33 UTC (rev 10883)
+++ CalendarServer/branches/users/gaya/directorybacker/doc/Admin/MultiServerDeployment.txt 2013-03-10 06:53:37 UTC (rev 10884)
@@ -1,191 +0,0 @@
-==========================
-Multi-server Deployment
-==========================
-
-Calendar Server version 3 and later uses a database as the primary data store, instead of the filesystem store used by previous versions. This allows for a familiar profile of scalability to multiple servers by offloading the DB to a dedicated server or cluster, and then adding front-end Calendar Server hosts as needed. This document highlights the key elements of a multi-server Calendar Server deployment.
-
-* `Database Connectivity`_: By default, Calendar Server assumes the DB is hosted locally on a unix domain socket, so you must add configuration to connect to an external DB service over the network.
-
-* `Database Setup and Schema Management`_: When connecting to an external DB, the administrator is responsible for applying our database schema to initialize the database for use by Calendar Server, using the calendarserver_bootstrap_database tool.
-
-* `Memcached`_: All Calendar Server hosts need to share access to memcached
-
-* `Proxy Database`_: Normally the Proxy (delegation) database is kept in a local sqlite database, which is not sharable. Create an additional database on the DB server to hold the Proxy DB, then configure all the servers to use it.
-
-* `Directory Services`_: All servers should have access to the same directory services data that defines users, groups, resources, and locations. Calendar Server provides a highly flexible LDAP client to leverage existing directory servers, or you can use local XML files.
-
-* `Client Connectivity`_: Use either a load balancer or round robin dns, and configure all servers to use the same ServerHostName in caldavd.plist
-
-* `Shared Storage for Attachments`_: AttachmentsRoot should point to storage shared across all servers, e.g. an NFS mount. Used for file attachments to calendar events.
-
-* `General Advise`_: *No one wants advice - only corroboration.* --John Steinbeck
-
----------------------
-Database Connectivity
----------------------
-
-First, make sure your Postgres service is connectable over the network ; by default it may use only unix domain sockets. Accepting connections over TCP typically involves changes to `listen_address <http://www.postgresql.org/docs/current/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES>`_ in the main server config file to bind the network socket, and also edits to `pg_hga.conf <http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html>`_ to allow connections by IP or netmask. Additional discussion of database server setup and tuning is beyond the scope of this document.
-
-There are a few configuration parameters in caldavd.plist that control Calendar Server's behavior with respect to database use. The relevant caldavd.plist entries and their default values are shown and described below (as defined in `stdconfig.py <https://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/stdconfig.py>`_)
-
-::
-
- "UseDatabase" : True, # True: database; False: files
-
- "DBType" : "", # 2 possible values: empty, meaning 'spawn postgres
- # yourself', or 'postgres', meaning 'connect to a
- # postgres database as specified by the 'DSN'
- # configuration key. Will support more values in
- # the future.
-
- "DSN" : "", # Data Source Name. Used to connect to an external
- # database if DBType is non-empty. Format varies
- # depending on database type.
-
-All of the above are top-level keys in caldavd.plist.
-
-The DSN is a colon separated string defined in PyGreSQL-4.0/pgdb.py and has the following structure:
-
-::
-
- dbhost = params[0]
- dbbase = params[1]
- dbuser = params[2]
- dbpasswd = params[3]
- dbopt = params[4]
- dbtty = params[5]
-
-When no hostname is specified, Calendar Server assumes the use of a local unix domain socket (found in the directory defined by the RunRoot config key)
-
-Example of a 'remote postgres via TCP' configuration:
-
-::
-
- <key>DBType</key>
- <string>postgres</string>
- <key>DSN</key>
- <string>hostname:dbname:dbuser:dbpass::</string>
-
-
-------------------------------------
-Database Setup and Schema Management
-------------------------------------
-
-Whenever DBType is set, Calendar Server is not responsible for the lifecycle of the database, nor is it responsible for the setup and schema population - these tasks are now the responsibility of the administrator. Once caldavd.plist is configured for your database, use the `calendarserver_bootstrap_database <https://trac.calendarserver.org/browser/CalendarServer/trunk/bin/calendarserver_bootstrap_database>`_ `tool <https://trac.calendarserver.org/browser/CalendarServer/trunk/calendarserver/tools/bootstrapdatabase.py>`_ to populate calendar server `schema <https://trac.calendarserver.org/browser/CalendarServer/trunk/txdav/common/datastore/sql_schema>`_ in your database. Starting and stopping the database should be accomplished using native tools (e.g. pg_ctl). The database should be started before Calendar Server, and stopped after Calendar Server.
-
-It is critically important that your database server keeps updated statistics about your database, which allows the database query planner to select appropriate performance optimizations. Refer to your database server documentation for details.
-
---------------
-Memcached
---------------
-
-The default memcached settings are found in `stdconfig.py <https://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/stdconfig.py>`_. By default there is one memcached 'pool' that is automatically managed by Calendar Server, and memcache is started and stopped along with Calendar Server. For a multi-server deployment, you should manage the memcached lifecycle externally, to make it independent of your Calendar Server hosts. Also, all Calendar Server hosts must be configured to share this memcached instance. A sample configuration is shown below, which instructs Calendar Server to connect to the 'Default' pool at example.com port 11211.
-
-::
-
- <!-- 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>
- <true/>
- <key>ServerEnabled</key>
- <false/>
- <key>BindAddress</key>
- <string>EXAMPLE.COM</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 this configuration, the administrator is expected to ensure that there is a memcached instance running on host EXAMPLE.COM listening on port 11211 (Default). All calendar servers need to have the same memcache configuration. Memcache should start first and stop last, relative to calendar server and postgres. Note also that memcached should be as close to the Calendar Server hosts as possible to minimize network latency.
-
-----------------
-Proxy Database
-----------------
-
-The Proxy DB (for delegation) is typically stored on disk in an sqlite DB, which does not allow for concurrent access across multiple hosts. To address this, create an additional DB in the postgres server, then edit caldavd.plist to add something like the following, and disable any other ProxyDB configuration.
-
-::
-
- <!-- PostgreSQL ProxyDB Service -->
- <key>ProxyDBService</key>
- <dict>
- <key>type</key>
- <string>twistedcaldav.directory.calendaruserproxy.ProxyPostgreSQLDB</string>
- <key>params</key>
- <dict>
- <key>dbtype</key>
- <string>ProxyDB</string>
- <key>host</key>
- <string>PARADISE-FALLS</string>
- <key>database</key>
- <string>FOSSILS</string>
- <key>user</key>
- <string>MUNTZ</string>
- </dict>
- </dict>
-
-As with the memcache config, all calendar servers should have the same ProxyDBService config. In the shown example, the server will expect to access a database called FOSSILS as user MUNTZ on the postgres server PARADISE-FALLS. Unlike with the primary calendar data store, calendar server is prepared to initialize the schema of this database at runtime if it does not exist - so nothing is required beyond creating the empty db, creating the db user with appropriate access, and applying some caldavd.plist configuration.
-
--------------------
-Directory Services
--------------------
-
-It is critical that all servers use the same directory services data that defines users (and their passwords), groups, resources, and locations used by Calendar Server. By default, this data is stored in local XML files, which is not ideally suited for a multi-server deployment, although would still work fine if the administrator is willing to manage the workflow around updating and distributing those files to all servers.
-
-In addition, Calendar Server provides a very configurable LDAP client interface for accessing external directory services data. Administrators familiar with LDAP should need little more than to look at `twistedcaldav/stdconfig.py <https://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/stdconfig.py>`_ for the available options to get started. Calendar Server will perform standard LDAP bind authentication to authenticate clients.
-
-Open Directory is also available when running on Mac OS X or Mac OS X Server.
-
--------------------
-Client Connectivity
--------------------
-
-Use either a load balancer or round robin dns, and configure all servers to use the same ServerHostName in caldavd.plist. A load balancer provides the most optimal distribution of work across available servers, and greater resiliency incase of individual server failure. Round robin DNS is simpler, and should work fine - however be aware that DNS caches may result in a given client 'sticking' to a server for a while. Using the same ServerHostName everywhere allows for all servers to have the exact same caldavd.plist, which is strongly recommended for simplicity.
-
--------------------------------
-Shared Storage for Attachments
--------------------------------
-
-Set the caldavd.plist key AttachmentsRoot to a filesystem directory that is shared and writable by all Calendar Server machines, for example an NFS export. This will be used to store file attachements that users may attach to calendar events.
-
--------------------
-General Advise
--------------------
-
-* Ensure caldavd.plist is identical on all Calendar Server hosts. This is not strictly required, but recommended to keep things as predictable as possible. Since you already have shared storage for AttachmentsRoot, use that to host the 'conf' directory for all servers as well; this way you don't need to push config changes out to the servers.
-
-* Use the various `tools and utilities <https://trac.calendarserver.org/browser/CalendarServer/trunk/contrib/tools>`_ to monitor activity in real time, and also for post-processing access logs.
-
-* Be sure you are getting the most from an individual server before you decide you need additional hosts (other than for redundancy). To optimize the single-server configuration, play with the caldavd.plist keys MultiProcessCount (# of daemons spawned), and MaxRequests (# of requests a daemon will process concurrently). If your Calendar Server isn't above 80% CPU use for sustained periods, you most likely don't need more Calendar Server hosts.
-
-* Ensure that your database's table statistics are updated at a reasonable interval. "Reasonable" depends entirely on how quickly your data changes in shape and size. In particular, be sure to update stats after any bulk changes.
-
-* Tune the database for performance, using the methodologies appropriate for the database you are using. The DB server will need to accept up to MultiProcessCount * MaxRequests connections from each Calendar Server, unless MaxDBConnectionsPerPool is set, in which case the number is MultiProcessCount * MaxDBConnectionsPerPool per server, plus a handful more for other things like the notification sidecar or command line tools.
-
-* Test Scenario: With a well tuned multi-server deployment of identically configured caldav servers behind a load balancer, and a separate Postgres server with a fast RAID 0, in a low-latency lab environment using simulated iCal client load, it takes 5 or 6 caldav servers to saturate the postgres server (which becomes i/o bound at a load of about 55,000 simulated users in this test).
-
-* To eliminate all single points of failure, implement high-availability for memcache, the database, the directory service, the shared storage for AttachmentsRoot, and the network load balancer(s).
-
-* When using an external directory service such as LDAP or Open Directory, overall Calendar Server performance is highly dependent on the responsiveness of the directory service.
-
Copied: CalendarServer/branches/users/gaya/directorybacker/doc/Admin/iSchedule.txt (from rev 10883, CalendarServer/trunk/doc/Admin/iSchedule.txt)
===================================================================
--- CalendarServer/branches/users/gaya/directorybacker/doc/Admin/iSchedule.txt (rev 0)
+++ CalendarServer/branches/users/gaya/directorybacker/doc/Admin/iSchedule.txt 2013-03-10 06:53:37 UTC (rev 10884)
@@ -0,0 +1,55 @@
+iSchedule
+==================
+
+The iSchedule protocol is a server-to-server calendar protocol that allows servers to exchange
+iTIP (iCalendar-based) scheduling messages in real time over the HTTP protocol.
+
+About iSchedule
+----------------
+
+The basic protocol is this:
+
+1) Server detects a calendar user trying to schedule with another calendar user not hosted on that server.
+2) Server extracts "domain" portion of the non-hosted calendar user address and does a DNS SRV query for
+the _ischedules service.
+3) If no result is found, the server has to fall back to other options (e.g., iMIP - email invites).
+4) If the DNS record is found the server extracts a hostname and port and makes an HTTPS request on
+/.well-known/ischedule querying for capabilities of any iSchedule server there.
+5) Once legitimate service is discovered, the server constructs an iTIP message for the invite and
+sends that in an HTTP request to the iSchedule server, supplying Originator and Recipient headers in
+the HTTP request.
+6) The iSchedule server receiving the iTIP message immediately processes it and sends the status back
+in the HTTP response.
+
+Domain-level Security
+---------------------
+
+iSchedule uses DKIM (Domain-Keys Identified Mail) adapted for use with HTTP as a security protocol to
+allow iSchedule servers to verify that an iSchedule client (sender) is authorized to send iSchedule
+messages on behalf of the domain the client is operating in.
+
+To implement DKIM, the iSchedule client creates an HTTP request and adds a DKIM-Signature header containing
+various bits of information that include: a cryptographic hash of the request body, a cryptographic signature
+of select HTTP headers (including the DKIM-Signature header itself). The signature uses a private/public key
+pair. The public key is made available via a DNS TXT record (or through HTTP or a private exchange).
+
+Upon receipt of a DKIM signed iSchedule message, the iSchedule server will verify that the body hash value in
+the DKIM-Signature header matches the actual request body, and that the signature of the selected headers is
+also a match (it retrieves the specified public key for the client domain).
+
+Configuration of Calendar Server
+--------------------------------
+
+Configuring the server for iSchedule is done as follows:
+
+1) Create an RSA private/public key file stored with your server configuration:
+ a) bin/calendarserver_dkimtool -g -k <private path> -p <public path> -t
+ b) Add the TXT record output to your domain's DNS server
+
+2) Edit caldavd.plist and make the following changes:
+ a) Set Schedule.iSchedule to <true/>
+ b) Set Schedule.iSchedule.DKIM.PrivateKeyFile to the RSA private key
+ c) Set Schedule.iSchedule.DKIM.PublicKeyFile to the RSA public key
+ d) Set Schedule.iSchedule.DKIM.Domain to the domain portion of your users'
+ calendar user addresses if that is different from the ServerHostName value
+ in caldavd.plist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20130309/a6cda6fd/attachment-0001.html>
More information about the calendarserver-changes
mailing list