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

[Marc Roos]

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

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