[CalendarServer-dev] Different base dn for users , groups and resources

[Andre LaBranche]

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

Hi,

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.

HTH,
-dre

> 
> Thanks in advance,
> Marc
> 
> 
> 
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -. 
> F1 Outsourcing Development Sp. z o.o.
> Poland 
> 
> 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 
>>>> twext.internet.sendfdport._SubprocessSocket.doWrite.
>>>> 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.
> 
> Axel
> 
> 
> 
> _______________________________________________
> calendarserver-dev mailing list
> calendarserver-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/calendarserver-dev