PenguinWhispererThe . wrote:

Once again thanks for taking your time to followup on this.

I've tried slapcat before to dump to a file and couldn't find the attributes that were mentioned. So today I did it again (just to make sure) and the dump doesn't seem to hold the attributes.

You're still not paying attention to Michael's advice. Wipe out your original DB and feed the slapcat output to slapadd.

Your current DB files still contain entries with the offending attributes.

What I did get is : The first database does not allow slapcat; using the first available one (2).

Apparently you have more than one database configured. You're probably not slapcat'ing the DB with the offending attributes.

So then I went to the directory and just grepped for the attribute name and it seems that it's matching on a binary file: cn=accesslog/log.000000123123 (changed the number to post).

This seems a good and a bad thing: good as in the actual data has no issues. Bad as in when I restart the service we get the message about the attributes. Is there something slapd does with those log files when it starts that explains it being printed on the screen/syslog?

I only have some "spare" time once in a while to further investigate this as it's not a high priority but I'd like to get rid of it.

2016-09-04 14:07 GMT+02:00 Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com>:

PenguinWhispererThe . wrote:
> Is "cleaning" my data somewhere like a slapcat and slapadd? This is a
> replicated environment. Will those changes be propagated? I'd think not as
> the import probably keeps the same timestamps.

You have to start from scratch like after a full restore (cleaning the
databases
before slapadd-ing the sanitized data).

Ciao, Michael.