Re: [CalendarServer-users] Locations & resources in LDAP in version 3.2?
My guess is your caldavd plist settings for LDAP don't match your LDAP server settings. See this page for an example DirectoryService plist section:
To clarify: I can see my locations as defined in LDAP in both the web interface and with the calendarserver_manage_principals. The only difference is (AFAIK), that I'm not able to lookup the locations by typing in the locations field of an event in the Apple iCal client. Tobias
On Thu, Aug 23, 2012 at 6:24 PM, tobiasbp <tobiasbp@gmail.com> wrote:
My guess is your caldavd plist settings for LDAP don't match your LDAP server settings. See this page for an example DirectoryService plist section:
Correct. I had not set up fullName. I have now, and I can look up locations and resources from my iCal clients. I can not however set autoSchedule to true for my locations and resources. I have set up mu resourceSchema like this: <key>resourceSchema</key> <dict> <key>resourceInfoAttr</key> <string></string> <key>autoScheduleAttr</key> <string>employeeType</string> <key>autoScheduleEnabledValue</key> <string>yes</string> <key>proxyAttr</key> <string>uid</string> <key>readOnlyProxyAttr</key> <string>uid</string> </dict> Comments in ldapdirectory.py led me to believe i HAVE to have something in proxAttr and readOnlyProxy. Proxies are not a functionality I need, so I just put in uid. Looking at my resources/locations with calendarserver_manage_principals, auto-schedule is always false even though I have employeeType=yes for the entity in the LDAP database? I have watched the traffic with tcpdump, and I can see that employeeType=yes is being returned from LDAP. I have trued to hard code autoSchedule = True in ldapdirectory.py, but I still get auto-schedule = false with calendarserver_manage_principals when I look up the resource/location. Any pointers to a good place in the code to force auto-schedule = true for all resources/locations? Regards, Tobias
On Aug 28, 2012, at 2:54 AM, tobiasbp <tobiasbp@gmail.com> wrote:
On Thu, Aug 23, 2012 at 6:24 PM, tobiasbp <tobiasbp@gmail.com> wrote:
My guess is your caldavd plist settings for LDAP don't match your LDAP server settings. See this page for an example DirectoryService plist section:
Correct. I had not set up fullName. I have now, and I can look up locations and resources from my iCal clients.
I can not however set autoSchedule to true for my locations and resources.
I have set up mu resourceSchema like this: <key>resourceSchema</key> <dict> <key>resourceInfoAttr</key> <string></string> <key>autoScheduleAttr</key> <string>employeeType</string> <key>autoScheduleEnabledValue</key> <string>yes</string> <key>proxyAttr</key> <string>uid</string> <key>readOnlyProxyAttr</key> <string>uid</string> </dict>
Comments in ldapdirectory.py led me to believe i HAVE to have something in proxAttr and readOnlyProxy. Proxies are not a functionality I need, so I just put in uid.
No, you actually shouldn't need to put in any values within resourceSchema; just leave all those strings blank. You see, there are two ways to tell calendar server about location/resource auto-schedule and proxy information... A) augments.xml B) the external directory service (LDAP, OpenDirectory, etc) The "resourceSchema" section is for configuring (B), but I think you just want to use (A). Unless you've explicitly set the "AugmentService" key in your caldavd.plist, you should have an augments.xml file in your data directory. That file contains settings which augment what you have in LDAP; for example, whether a principal is enabled for calendaring and/or addressbooks, and the auto-schedule flag. There should be a "Default" entry in augments.xml which applies to any principal that doesn't have a specific matching entry. You can also add type-specific entries, so if you want all locations and resources to be auto-scheduled, you should add this to your augments.xml: <record> <uid>Location-Default</uid> <enable>true</enable> <enable-calendar>true</enable-calendar> <enable-addressbook>true</enable-addressbook> <auto-schedule>true</auto-schedule> </record> <record> <uid>Resource-Default</uid> <enable>true</enable> <enable-calendar>true</enable-calendar> <enable-addressbook>true</enable-addressbook> <auto-schedule>true</auto-schedule> </record> Now, the typical deployment on an OS X Server nowadays is to have users/groups come from the directory service, while locations/resources come from resources.xml. Locations/resources are added/removed/edited via either the OS X Server UI, or with the calendarserver_manage_principals command line utility which is included in the open-source project. If you want to go that route, you configure your caldavd.plist DirectoryService to handle users/groups, and configure the ResourceService to handle locations/resources. However, if you want to continue keeping locations/resources in your LDAP, then adding the Location-Default and Resource-Default entries into augments.xml should work. ~morgen
Looking at my resources/locations with calendarserver_manage_principals, auto-schedule is always false even though I have employeeType=yes for the entity in the LDAP database?
I have watched the traffic with tcpdump, and I can see that employeeType=yes is being returned from LDAP.
I have trued to hard code autoSchedule = True in ldapdirectory.py, but I still get auto-schedule = false with calendarserver_manage_principals when I look up the resource/location.
Any pointers to a good place in the code to force auto-schedule = true for all resources/locations?
Regards, Tobias _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/calendarserver-users
Hello Morgen. Thank you for your thorough explanation. Much appreciated. I have managed to change the default for auto-scheduling in augments.xml to true. This works as expected. I can not however change the auto-schedule setting: 1. Using calendarserver_manage_proxies I get errors as it tries to manipulate data in LDAP (I don't want to give the calendarserver write access to the LDAP database, so that's "OK"). 2. Using the webinterface to change the auto-schedule setting for an entity produces weird (to me results). An entry with the new setting is added to agments.xml, but the setting appears to not be honored. Both the web interface and calendarserver_manage_proxies show the old setting? The "inconsistency" survives a restart of caldavd. As my resources & locations will probably all be auto-schedule=true for ever, it would still be nice to be able to change the setting. Regards, Tobias
You see, there are two ways to tell calendar server about location/resource auto-schedule and proxy information...
A) augments.xml B) the external directory service (LDAP, OpenDirectory, etc)
On Sep 3, 2012, at 1:35 AM, tobiasbp <tobiasbp@gmail.com> wrote:
Hello Morgen.
Thank you for your thorough explanation. Much appreciated.
I have managed to change the default for auto-scheduling in augments.xml to true. This works as expected.
I can not however change the auto-schedule setting: 1. Using calendarserver_manage_proxies I get errors as it tries to manipulate data in LDAP (I don't want to give the calendarserver write access to the LDAP database, so that's "OK").
calendarserver_manage_principals should never try to write to LDAP. Something must still be misconfigured. Email me your caldavd.plist and I'll take a look.
2. Using the webinterface to change the auto-schedule setting for an entity produces weird (to me results). An entry with the new setting is added to agments.xml, but the setting appears to not be honored. Both the web interface and calendarserver_manage_proxies show the old setting? The "inconsistency" survives a restart of caldavd.
As my resources & locations will probably all be auto-schedule=true for ever, it would still be nice to be able to change the setting.
Regards, Tobias
You see, there are two ways to tell calendar server about location/resource auto-schedule and proxy information...
A) augments.xml B) the external directory service (LDAP, OpenDirectory, etc)
Hello Morgen. Thank you for all your help.
calendarserver_manage_principals should never try to write to LDAP. Something must still be misconfigured. Email me your caldavd.plist and I'll take a look.
I have attached my (sanitized) caldavd.plist. Regards, Tobias
The plist looks ok, although you might want to change the DirectoryService cacheTimeout to at least 1 minute (you have it set to 0, which as far as I know is untested). Can you provide an example of how you are trying to use calendarserver_manage_principals to change the auto-schedule setting for a location/resource? Also, if an augments.xml entry doesn't seem to be having an effect, that could mean a mismatch between the <uid> value in augments.xml and your guidAttr in LDAP. You caldavd.plist has guidAttr set to "entryUUID" -- do your locations and resources have entryUUID values in LDAP? The case must match exactly between LDAP and augments.xml. On Sep 4, 2012, at 8:25 AM, tobiasbp <tobiasbp@gmail.com> wrote:
Hello Morgen.
Thank you for all your help.
calendarserver_manage_principals should never try to write to LDAP. Something must still be misconfigured. Email me your caldavd.plist and I'll take a look.
I have attached my (sanitized) caldavd.plist.
Regards, Tobias <caldavd.plist>
On Tue, Sep 4, 2012 at 5:53 PM, Morgen Sagen <sagen@apple.com> wrote:
The plist looks ok, although you might want to change the DirectoryService cacheTimeout to at least 1 minute (you have it set to 0, which as far as I know is untested).
I had it off for testing. You are right, I should change it back to 1.
Can you provide an example of how you are trying to use calendarserver_manage_principals to change the auto-schedule setting for a location/resource?
I can't get to the machine at the moment. But, actually it's more like two errors: 1: The object does not have an update function, and some LDAP-access error which I can understand since I'm using anonymous access to the LDAP-server. I'll post the actual error once I can get to the machine again.
Also, if an augments.xml entry doesn't seem to be having an effect, that could mean a mismatch between the <uid> value in augments.xml and your guidAttr in LDAP.
That does not seem to be the problem. The entries match the UUIDs in LDAP.
You caldavd.plist has guidAttr set to "entryUUID" -- do your locations and resources have entryUUID values in LDAP?
Yes they do. Thank you, Tobias
Can you provide an example of how you are trying to use calendarserver_manage_principals to change the auto-schedule setting for a location/resource?
List locations: root@wheezy32:~# su caldavd -p -c "calendarserver_manage_principals --list-principals location" Full name Record name UUID --------- ----------- ---- Møde: Biblioteket loc_biblioteket 49c633e4-87b0-1031-800b-738d39f6458d Møde: Hjørnet loc_hjornet 68846530-87b0-1031-800d-738d39f6458d Møde: Kantinen loc_kantinen 82b24c74-87b0-1031-800e-738d39f6458d Møde: Kantinen arbejdsborde loc_kantinen_arbejdsborde a39ee172-87b0-1031-800f-738d39f6458d Møde: Ved Illum loc_ved_illum d096c190-87b0-1031-8010-738d39f6458d Møde: Ved kirken loc_ved_kirken ec66ef9e-87b0-1031-8011-738d39f6458d See the current setting of auto schedule for a location. By name: OK root@wheezy32:~# su caldavd -p -c "calendarserver_manage_principals --get-auto-schedule locations:loc_hjornet" Autoschedule for "Møde: Hjørnet" (locations:loc_hjornet) is true By UUID: OK root@wheezy32:~# su caldavd -p -c "calendarserver_manage_principals --get-auto-schedule 68846530-87b0-1031-800d-738d39f6458d" Autoschedule for "Møde: Hjørnet" (locations:loc_hjornet) is true Attempt to change auto-schedule to false: root@wheezy32:~# su caldavd -p -c "calendarserver_manage_principals --set-auto-schedule=false 68846530-87b0-1031-800d-738d39f6458d" Setting auto-schedule to false for "Møde: Hjørnet" (locations:loc_hjornet) Unhandled error in Deferred: Unhandled error in Deferred: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1187, in unwindGenerator return _inlineCallbacks(None, gen, Deferred()) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, in _inlineCallbacks result = g.send(result) File "/usr/lib/python2.7/dist-packages/calendarserver/tools/principals.py", line 695, in action_setAutoSchedule **principal.record.extras File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1187, in unwindGenerator return _inlineCallbacks(None, gen, Deferred()) --- <exception caught here> --- File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, in _inlineCallbacks result = g.send(result) File "/usr/lib/python2.7/dist-packages/calendarserver/tools/principals.py", line 810, in updateRecord record = directory.updateRecord(recordType, **kwargs) File "/usr/lib/python2.7/dist-packages/twistedcaldav/directory/aggregate.py", line 251, in updateRecord password=password, **kwargs) File "/usr/lib/python2.7/dist-packages/twistedcaldav/directory/directory.py", line 406, in updateRecord raise NotImplementedError("Subclass must implement updateRecord") exceptions.NotImplementedError: Subclass must implement updateRecord Unhandled Error Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1187, in unwindGenerator return _inlineCallbacks(None, gen, Deferred()) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, in _inlineCallbacks result = g.send(result) File "/usr/lib/python2.7/dist-packages/calendarserver/tools/principals.py", line 695, in action_setAutoSchedule **principal.record.extras File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1187, in unwindGenerator return _inlineCallbacks(None, gen, Deferred()) --- <exception caught here> --- File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, in _inlineCallbacks result = g.send(result) File "/usr/lib/python2.7/dist-packages/calendarserver/tools/principals.py", line 810, in updateRecord record = directory.updateRecord(recordType, **kwargs) File "/usr/lib/python2.7/dist-packages/twistedcaldav/directory/aggregate.py", line 251, in updateRecord password=password, **kwargs) File "/usr/lib/python2.7/dist-packages/twistedcaldav/directory/directory.py", line 406, in updateRecord raise NotImplementedError("Subclass must implement updateRecord") exceptions.NotImplementedError: Subclass must implement updateRecord Main loop terminated.
When I try this with the most recent calendar server code it works. Auto-schedule flags get stored in the augments.xml file. Your error makes it appear that your XML-based augments service is disabled, and therefore it is trying to write to the LDAP service. I don't know if that's because the code you're running is older, but I guess you'll just have to edit the augments.xml by hand to change auto-schedule flags. On Sep 11, 2012, at 6:05 AM, tobiasbp <tobiasbp@gmail.com> wrote:
Can you provide an example of how you are trying to use calendarserver_manage_principals to change the auto-schedule setting for a location/resource?
List locations:
root@wheezy32:~# su caldavd -p -c "calendarserver_manage_principals --list-principals location" Full name Record name UUID --------- ----------- ---- Møde: Biblioteket loc_biblioteket 49c633e4-87b0-1031-800b-738d39f6458d Møde: Hjørnet loc_hjornet 68846530-87b0-1031-800d-738d39f6458d Møde: Kantinen loc_kantinen 82b24c74-87b0-1031-800e-738d39f6458d Møde: Kantinen arbejdsborde loc_kantinen_arbejdsborde a39ee172-87b0-1031-800f-738d39f6458d Møde: Ved Illum loc_ved_illum d096c190-87b0-1031-8010-738d39f6458d Møde: Ved kirken loc_ved_kirken ec66ef9e-87b0-1031-8011-738d39f6458d
See the current setting of auto schedule for a location.
By name: OK
root@wheezy32:~# su caldavd -p -c "calendarserver_manage_principals --get-auto-schedule locations:loc_hjornet" Autoschedule for "Møde: Hjørnet" (locations:loc_hjornet) is true
By UUID: OK
root@wheezy32:~# su caldavd -p -c "calendarserver_manage_principals --get-auto-schedule 68846530-87b0-1031-800d-738d39f6458d" Autoschedule for "Møde: Hjørnet" (locations:loc_hjornet) is true
Attempt to change auto-schedule to false:
root@wheezy32:~# su caldavd -p -c "calendarserver_manage_principals --set-auto-schedule=false 68846530-87b0-1031-800d-738d39f6458d" Setting auto-schedule to false for "Møde: Hjørnet" (locations:loc_hjornet) Unhandled error in Deferred: Unhandled error in Deferred: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1187, in unwindGenerator return _inlineCallbacks(None, gen, Deferred()) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, in _inlineCallbacks result = g.send(result) File "/usr/lib/python2.7/dist-packages/calendarserver/tools/principals.py", line 695, in action_setAutoSchedule **principal.record.extras File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1187, in unwindGenerator return _inlineCallbacks(None, gen, Deferred()) --- <exception caught here> --- File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, in _inlineCallbacks result = g.send(result) File "/usr/lib/python2.7/dist-packages/calendarserver/tools/principals.py", line 810, in updateRecord record = directory.updateRecord(recordType, **kwargs) File "/usr/lib/python2.7/dist-packages/twistedcaldav/directory/aggregate.py", line 251, in updateRecord password=password, **kwargs) File "/usr/lib/python2.7/dist-packages/twistedcaldav/directory/directory.py", line 406, in updateRecord raise NotImplementedError("Subclass must implement updateRecord") exceptions.NotImplementedError: Subclass must implement updateRecord Unhandled Error Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1187, in unwindGenerator return _inlineCallbacks(None, gen, Deferred()) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, in _inlineCallbacks result = g.send(result) File "/usr/lib/python2.7/dist-packages/calendarserver/tools/principals.py", line 695, in action_setAutoSchedule **principal.record.extras File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1187, in unwindGenerator return _inlineCallbacks(None, gen, Deferred()) --- <exception caught here> --- File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, in _inlineCallbacks result = g.send(result) File "/usr/lib/python2.7/dist-packages/calendarserver/tools/principals.py", line 810, in updateRecord record = directory.updateRecord(recordType, **kwargs) File "/usr/lib/python2.7/dist-packages/twistedcaldav/directory/aggregate.py", line 251, in updateRecord password=password, **kwargs) File "/usr/lib/python2.7/dist-packages/twistedcaldav/directory/directory.py", line 406, in updateRecord raise NotImplementedError("Subclass must implement updateRecord") exceptions.NotImplementedError: Subclass must implement updateRecord Main loop terminated.
participants (2)
-
Morgen Sagen
-
tobiasbp