[CalendarServer-dev] [CalendarServer] #260: OpenLDAP
CalendarServer
trac at macosforge.org
Fri Jun 26 11:13:58 PDT 2009
#260: OpenLDAP
---------------------------------------+------------------------------------
Reporter: jusiskin@… | Owner: wsanchez@…
Type: Feature | Status: new
Priority: 3: Important | Milestone: CalendarServer-2.x
Component: Calendar Server | Severity: Other
Keywords: |
---------------------------------------+------------------------------------
Comment(by oxullo@…):
Dear Aymeric,[[br]]
thanks to the suggestion, I've successfully implemented groups, based on
groupOfNames schema.
I think that the configuration is fine, at least with these assumptions:
1. the 'attr' key of every rdnSchema entries has to be the rdn of the
element (wasn't so implicit to me!)
2. locations and resources don't work unless few lines are added to the
method that create LDAP->principal mappings (patch follows)
This patch is a lame way to have a quick working support for resources and
locations. If there is no need at all for code redundancy (dunno if check
against cn is enough), the branch can be integrated with the group's one.
{{{
--- ldapdirectory.py.orig 2009-06-26 19:54:12.000000000 +0200
+++ ldapdirectory.py 2009-06-26 19:54:44.000000000 +0200
@@ -165,6 +165,12 @@
fullName = self._getUniqueLdapAttribute(attrs, 'cn')
calendarUserAddresses = emailAddresses
enabledForCalendaring = True
+ elif (recordType == DirectoryService.recordType_resources or
+ recordType == DirectoryService.recordType_locations):
+ shortName = self._getUniqueLdapAttribute(attrs, 'cn')
+ fullName = self._getUniqueLdapAttribute(attrs, 'cn')
+ calendarUserAddresses = emailAddresses
+ enabledForCalendaring = True
return LdapDirectoryRecord(
service = self,
}}}
Can you kindly suggest an example LDIF so we can refer ourselves to a
specific and suggested schema? Right now I'm using:
* context containers (groups, locations, resources, users):
''organizationalUnit''
* users: ''inetOrgPerson'' + ''simpleSecurityObject''
* groups: ''groupOfNames''
* resources: ''device''
* locations: (suggestions? why ''room'' 's cn is "commonName"?)
Then, I gave a quick look to attendees support, which seems to be broken.
Probably due to a missing email'S 'mailto:' specification for a fully
qualified url. I will give a look to that tomorrow.
Finally, about delegates: this is the mechanism which allows one principal
to have access to another principal. Right now, for instance and on a
XMLDirectory instance, I have two locations and one resource configured as
delegates to a group. Every person on this group can add each location and
resource's calendar at ease and with no other credential set.
I wish that is worthy for someone to get this snippet published here as a
template (avoiding pydict to plist boring mapping):
{{{
<key>DirectoryService</key>
<dict>
<key>type</key>
<string>twistedcaldav.directory.ldapdirectory.LdapDirectoryService</string>
<key>params</key>
<dict>
<key>credentials</key>
<dict>
<key>dn</key>
<string>cn=admin,dc=example,dc=com</string>
<key>password</key>
<string>secretWord</string>
</dict>
<key>groupSchema</key>
<dict>
<key>membersAttr</key>
<string>member</string>
<key>memberIdAttr</key>
<string></string>
</dict>
<key>rdnSchema</key>
<dict>
<key>base</key>
<string>dc=example,dc=com</string>
<key>users</key>
<dict>
<key>rdn</key>
<string>ou=users</string>
<key>attr</key>
<string>cn</string>
<key>emailSuffix</key>
<string></string>
</dict>
<key>groups</key>
<dict>
<key>rdn</key>
<string>ou=groups</string>
<key>attr</key>
<string>cn</string>
<key>emailSuffix</key>
<string></string>
</dict>
<key>resources</key>
<dict>
<key>rdn</key>
<string>ou=resources</string>
<key>attr</key>
<string>cn</string>
<key>emailSuffix</key>
<string></string>
</dict>
<key>locations</key>
<dict>
<key>rdn</key>
<string>ou=locations</string>
<key>attr</key>
<string>cn</string>
<key>emailSuffix</key>
<string></string>
</dict>
</dict>
</dict>
</dict>
}}}
--
Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:20>
CalendarServer </>
HTTP/WebDAV/CalDAV Server
More information about the calendarserver-dev
mailing list