--On Monday, March 8, 2021 11:04 PM +0100 "A. Schulze"
Am 08.03.21 um 19:08 schrieb Michael Ströder:
>> Am 02.03.21 um 13:19 schrieb A. Schulze:
>>> Q: does it make sense to enforce schema checking on a LDAP consumer,
> Maybe it's easier to answer if you explain which problem you want to
thanks to Quanah I've to clarify first: I'm not using cn=config.
As Michael already noted, it applies to slapd.conf as well. That's why I
said "especially" in regards to cn=config, but not "exclusively". ;)
my initial situation was a well running setup "single provider,
consumer" At one point in time, there is a request to extend the schema:
add new attribute types, extend existing objectClasses
Even with automation it takes time to activate the new schema on multiple
consumer: - planing changes
- getting change dates
- get systems offline, update, check
- get systems online again
After that is done, the new scheme could be activated at the provider and
new data could be added.
So my question is more: could I avoid updating multiple consumer to save
time and effort and get requests for schema updates done faster.
There's no downsides to enabling schema checking on the consumers. I'd
generally consider it mandatory. If the consumer receives an attribute it
doesn't know about in the schema, it won't know how to correctly store the
data in the db, particularly if you want to later use it for indexing,
since it won't know the syntax. I.e., I generally would consider it
mandatory to have schema checking on the consumer side.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: