change to acl_read module for supporting dirsync module

Nadezhda Ivanova nivanova at samba.org
Wed Mar 9 15:02:05 MST 2011


Hi Matthieu,
While I was working on the acl_read, the initial implementation used an
internal control, that the ldap server put so that the acl_read know if the
request came from ldap or otherwise. Make test took 120 minutes. When I
replaced the control with the trusted flag - make test again took 50
minutes, that;s why I decided searching for controls is slow. I may have
been mistaken. Perhaps someone else can give an opinion?

Regards,
Nadya

On Wed, Mar 9, 2011 at 11:51 PM, Matthieu Patou <mat at samba.org> wrote:

> On 09/03/2011 23:30, Matthias Dieter Wallnöfer wrote:
>
>> Nadya + Ekacnet,
>>
>> certainly I let it up to you both to find the best solution (I'm not
>> really competent here) but an internal flag sounds very good.
>>
>>  For me using module for inter module signaling is the way to do but I
> might be wrong, I don't know !
> For the flags I don't have an idea if it exists or not.
> The point that nadya pointed to me is that searching for a control is slow,
> which I'm not so sure at least when you have just a couple of controls (as
> it's mostly the case right now).
>
> In my patch I'm searching for the control once per request and not once per
> object returned (which here could be overkill).
>
> Instead of using a control I can use an ldb_opaque but in terms of cost I
> have the impression that it's as expensive as searching for an opaque is
> looping around opaque list and strcmping the different opaque names.
>
>
>  I simply would like to try to remove the number of controls (see my RELAX
>> discussion with abartlet & co.) which are often exposed on the outside and
>> therefore also error-prone.
>>
> So am I, and for the moment this control is a DSDB one so not accessible
> from ldap and only with the local:oid notation in python and ldb* tools.
>
>
>
>
> Matthieu Patou
> Samba Team        http://samba.org
> Private repo      http://git.samba.org/?p=mat/samba.git;a=summary
>
>
>


More information about the samba-technical mailing list