Hello,
I'm running a LDAP provider and multiple LDAP consumer and like to ask for your opinions to such a setup: While writing data to the LDAP provider, schema-checking is enforced. Currently also the LDAP consumer enforce schema checking.
Q: does it make sense to enforce schema checking on a LDAP consumer, too?
What pros and cons do you see?
Thanks! Andreas
Am 02.03.21 um 13:19 schrieb A. Schulze:
I'm running a LDAP provider and multiple LDAP consumer and like to ask for your opinions to such a setup: While writing data to the LDAP provider, schema-checking is enforced. Currently also the LDAP consumer enforce schema checking.
Q: does it make sense to enforce schema checking on a LDAP consumer, too?
would be helpful if you could share experience/suggestion/opinion
Andreas
On 3/7/21 11:36 PM, A. Schulze wrote:
Am 02.03.21 um 13:19 schrieb A. Schulze:
I'm running a LDAP provider and multiple LDAP consumer and like to ask for your opinions to such a setup: While writing data to the LDAP provider, schema-checking is enforced. Currently also the LDAP consumer enforce schema checking.
Q: does it make sense to enforce schema checking on a LDAP consumer, too?
would be helpful if you could share experience/suggestion/opinion
Personally I'm in the camp check-everything-everywhere and fail-soon-fail-hard. But that's a pretty general statement.
Maybe it's easier to answer if you explain which problem you want to solve?
Ciao, Michael.
--On Sunday, March 7, 2021 11:36 PM +0100 "A. Schulze" sca@andreasschulze.de wrote:
Am 02.03.21 um 13:19 schrieb A. Schulze:
I'm running a LDAP provider and multiple LDAP consumer and like to ask for your opinions to such a setup: While writing data to the LDAP provider, schema-checking is enforced. Currently also the LDAP consumer enforce schema checking.
Q: does it make sense to enforce schema checking on a LDAP consumer, too?
would be helpful if you could share experience/suggestion/opinion
Yes, it makes sense, particularly when using cn=config. I.e., if the master has had a schema update prior to the consumer being modified similarly, it prevents changes with unknown schema elements from being replicated.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 3/8/21 7:13 PM, Quanah Gibson-Mount wrote:
--On Sunday, March 7, 2021 11:36 PM +0100 "A. Schulze" sca@andreasschulze.de wrote:
Am 02.03.21 um 13:19 schrieb A. Schulze:
I'm running a LDAP provider and multiple LDAP consumer and like to ask for your opinions to such a setup: While writing data to the LDAP provider, schema-checking is enforced. Currently also the LDAP consumer enforce schema checking.
Q: does it make sense to enforce schema checking on a LDAP consumer, too?
would be helpful if you could share experience/suggestion/opinion
Yes, it makes sense, particularly when using cn=config. I.e., if the master has had a schema update prior to the consumer being modified similarly, it prevents changes with unknown schema elements from being replicated.
This reasoning is not limited to cn=config. Same with static config with slapd.conf.
Ciao, Michael.
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, too?
Maybe it's easier to answer if you explain which problem you want to solve?
Hi Michael,
thanks to Quanah I've to clarify first: I'm not using cn=config.
my initial situation was a well running setup "single provider, multiple 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.
Andreas
--On Monday, March 8, 2021 11:04 PM +0100 "A. Schulze" sca@andreasschulze.de wrote:
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, too?
Maybe it's easier to answer if you explain which problem you want to solve?
Hi Michael,
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, multiple 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.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 3/8/21 11:17 PM, Quanah Gibson-Mount wrote:
There's no downsides to enabling schema checking on the consumers.
AFAICT schema checking cannot be disabled for slapd in general. Not sure since which version the schemacheck directive was dropped. I guess since 2.4.x.
So schema checking can only be disabled with "schemachecking=off" within syncrepl directive. slapd.conf(5) says "off" is the default and as use-case it mentions partial replication.
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.
Yes, indexing won't work without correct SYNTAX in attribute type description.
So I agree schema should be correct on consumers. Everything else is asking for trouble.
The new schema including new indexing should be installed on consumers before the first new attribute values hits the consumer. This can get pretty tricky in corner cases though, e.g. new MUST attributes in existing object classes.
Ciao, Michael.
On Mar 9, 2021, at 00:46, Michael Ströder michael@stroeder.com wrote:
On 3/8/21 11:17 PM, Quanah Gibson-Mount wrote:
There's no downsides to enabling schema checking on the consumers.
AFAICT schema checking cannot be disabled for slapd in general. Not sure since which version the schemacheck directive was dropped. I guess since 2.4.x.
So schema checking can only be disabled with "schemachecking=off" within syncrepl directive. slapd.conf(5) says "off" is the default and as use-case it mentions partial replication.
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.
Yes, indexing won't work without correct SYNTAX in attribute type description.
So I agree schema should be correct on consumers. Everything else is asking for trouble.
The new schema including new indexing should be installed on consumers before the first new attribute values hits the consumer.
I’d also note the new schemas need to be added in the same order on all nodes. I’ve hit an issue a couple years ago were 2 new schemas took different numbers in cn=config style setting and openldap started complaining. Took quite a while to figure out.
This can get pretty tricky in corner cases though, e.g. new MUST attributes in existing object classes.
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 08.03.2021 um 19:08 in
Nachricht 4f6e08fe-dfdd-57e1-9694-c7565f54ebd3@stroeder.com:
On 3/7/21 11:36 PM, A. Schulze wrote:
Am 02.03.21 um 13:19 schrieb A. Schulze:
I'm running a LDAP provider and multiple LDAP consumer and like to ask for your opinions to such a setup: While writing data to the LDAP provider, schema-checking is enforced. Currently also the LDAP consumer enforce schema checking.
Q: does it make sense to enforce schema checking on a LDAP consumer, too?
Put the question the other way: When would it make sense not to check the schema on the consumer when generally checking the schema? The situation that comes in my mind would be non-delta-syncrepl when the schma could be temporarily broken. I haven't seen such in the last years however.
would be helpful if you could share experience/suggestion/opinion
Personally I'm in the camp check-everything-everywhere and fail-soon-fail-hard. But that's a pretty general statement.
Maybe it's easier to answer if you explain which problem you want to solve?
Ciao, Michael.
"A. Schulze" sca@andreasschulze.de schrieb am 08.03.2021 um 23:04 in
Nachricht ad89bcd6-33bd-623c-51a6-28e844bd3b8e@andreasschulze.de:
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,
too?
Maybe it's easier to answer if you explain which problem you want to
solve?
Hi Michael,
thanks to Quanah I've to clarify first: I'm not using cn=config.
my initial situation was a well running setup "single provider, multiple 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.
I think it mostly depends on the "type of schema update": If the update is compatible with existing data, it's easy, if the data needs adjustment you'll have the problem: What to update first? Data or schema? In both cases the data will look inconsistent.
Andreas
openldap-technical@openldap.org
-
A. Schulze -
Michael Ströder -
Quanah Gibson-Mount -
Sami Ait Ali Oulahcen -
Ulrich Windl