Le 12/10/16 à 02:40, Ryan Tandy a écrit :
> On Thu, Sep 29, 2016 at 06:03:38PM +0000, elecha...@apache.org wrote:
>> $ grep -ri "olcSpNoPresent" slapd.d
>> $ ...
>>
>> You can stop and restart the server, the attribute is still not present.
>
> It's system schema and not user schema, so I kind of expect this. The
> behaviour is the same when cn=config is initialized using slapadd -n0.
>
> 'ldapsearch -s base cn=schema,cn=config' does show these attributes.
>
>> Going back to the slapd.conf file, add the module :
>>
>> ...
>> # Uncomment the mululeloads as needed to enable additional
>> # functionalityi when configured. NOTE: We package many
>> # more modules options than those found below.
>> moduleload      back_mdb.la
>> moduleload      back_monitor.la
>> moduleload      syncprov.la        # Added module
>> ...
>>
>> and regenerate the slapd.d content :
>>
>> $ /etc/init.d/solserver stop
>> $ rm -rf /opt/symas/etc/openldap/slapd.d/*
>> $ /opt/symas/bin/slaptest -f /opt/symas/etc/openldap/slapd.conf -F
>> /opt/symas/etc/openldap/slapd.d
>> $ grep -ri "olcSpNoPresent" /opt/symas/etc/openldap/slapd.d
>> slapd.d/cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgOvAt:1.3 NAME
>> 'olcSpNoPresent' DESC 'Omit Present
>> slapd.d/cn=config/cn=schema.ldif:  $ olcSpSessionlog $ olcSpNoPresent $
>> olcSpReloadHint ) )
>> $...
>>
>> This is problematic...
>
> If there is a bug, I'd say it's the fact that the converter does write
> out these attributes.
>
> Actually slapd replaces the entire cn=schema entry at runtime. As far
> as I can tell, the the cn=schema.ldif file on disk is never used. So
> it would certainly be dangerous to rely on its contents for anything.

I must say that I can't reproduce this behavious with the latest
release, so I guess it was fixed since the test I did.




Reply via email to