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@f1-outsourcing.eu -----Original Message----- From: Axel Rau [mailto:Axel.Rau@Chaos1.DE] Sent: woensdag 20 februari 2013 13:13 To: calendarserver-dev@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