On Feb 21, 2013, at 8:01 AM, Marc Roos <M.Roos@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@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

_______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev