Le 12/10/16 à 02:40, Ryan Tandy a écrit : > On Thu, Sep 29, 2016 at 06:03:38PM +0000, [email protected] 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.
