Michael Ströder wrote:
Howard Chu wrote:
> Hallvard B Furuseth wrote:
>> You also need to walk through the database and delete any attributes
>> object classes defined by the overlay. That'll be at least any
>> operational attributes since they must be hardcoded into the C source.
> I wouldn't bother with that, since the schema definitions are still
> present. Those attributes would simply stop being updated/generated...
Hmm, I'd consider this to be seriously flawed. It strikes me that there
might still exist operational attributes in some entries which are no
longer maintained by the DSA and there's no schema information available
Think of backup/restore situations where slapadd checks the schema...
That's a broken administrative process then. E.g., I backup my DB using
slapcat, then delete the overlay. Now the backup is essentially invalid,
unless I also backed up cn=config and restored everything together.
We can trigger a background thread to try to cleanup the DB contents, but if
the slapd is shutdown while the thread is running, then the job will only be
half done. There's no remedy for that situation.
No matter what, you have to be prepared to clean up the LDIF as a separate
step, if the slapadd runs into unknown schema.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/