On Feb 21, 2013, at 8:01 AM, Marc Roos <m.r...@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: m...@f1-outsourcing.eu > > > -----Original Message----- > From: Axel Rau [mailto:axel....@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 _______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
