[CalendarServer-dev] Different base dn for users , groups and resources
dre at apple.com
Mon Feb 25 10:18:05 PST 2013
On Feb 21, 2013, at 8:01 AM, Marc Roos <M.Roos at f1-outsourcing.eu> wrote:
> Is it possible to configure different base dn's for users and groups?
> I have them stored at different locations in the ldap directory and I
> dont want to give to much rights to the binddn
Sorry for the late reply.
This might work. The effective DN used by Calendar Server for a given record type is derived from the base DN and the rdn for each record type, as configured in caldavd.plist. So for example, if your ldap config has:
base : dc=example,dc=com
users rdn: ou=People
This is (should be) effectively the same as:
base : dc=example
users rdn: dc=com,ou=People
As long as you have at least one common top-level component in the 'path' to your record types, this might be an effective strategy.
Let us know how it works out.
> Thanks in advance,
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -.
> F1 Outsourcing Development Sp. z o.o.
> t: +48 (0)124466845
> f: +48 (0)124466843
> e: marc at f1-outsourcing.eu
> -----Original Message-----
> From: Axel Rau [mailto:Axel.Rau at Chaos1.DE]
> Sent: woensdag 20 februari 2013 13:13
> To: calendarserver-dev at lists.macosforge.org
> Subject: Re: [CalendarServer-dev] Exception in recvfd --was: Re:
> continuing work on FreeBSD ports
> Am 20.02.2013 um 10:51 schrieb Axel Rau:
>>> Like... no ancillary data is being *passed to sendmsg*?
>> Yes. My debug print at the beginning of sendmsg always shows 0.
>>> Or no data is being received from recvmsg? Does tracing the relevant
> processes with something like strace or dtruss confirm this? What
> process is being debugged here; master, worker, or both?
>> Both, because the unpack error pointed at a platform/compatibility
> issue in sendmsg.c, which is used by all parts.
>> I will try to get a trace with dtruss.
> truss trace of the handling of the http accept attached.
>>> The debug messages which you've added seem like they might be missing
> some data, since they just truncate after 'return from sendmsg with',
> rather than printing a string (even an empty one) after.
>> Yes, the code was not finished. should display sendmsg_result, which
> was always 1. See attached diff.
>>>> Without ancillary data, no fd can be shipped.
>>>> The only place where ancillary data could be provided seems to be
>>>> I would be happy for any hint where to dig...
>>> Well, hrm. This code works fine on other platforms, so, one thing to
> check would be to see if previous versions of the FreeBSD kernel have
> the same issue. What exact versions of everything are you testing?
>> 8.2 and 9.1. Both show same bug.
> Both platforms are 64-bit.
> calendarserver-dev mailing list
> calendarserver-dev at lists.macosforge.org
More information about the calendarserver-dev