Hi list,
I was experimenting locally written schema with a recent build of slapd. I added the schema ldif with no problem using
ldapadd -QY EXTERNAL -H ldapi:/// ...
But then I realized I made a mistake, so I try to delete it with
ldapdelete -QY EXTERNAL -H ldapi:///
it says:
ldap_delete: Server is unwilling to perform (53)
what does it mean? The schema is not used by any data on the server. I can use slapmodify to remove it after server shutdown, but that kind of suck and not much different, or even worse than editing conf file?
Derek
--On Saturday, November 17, 2018 4:16 PM +0800 Derek Zhou derek@shannon-data.com wrote:
ldap_delete: Server is unwilling to perform (53)
what does it mean? The schema is not used by any data on the server. I can use slapmodify to remove it after server shutdown, but that kind of suck and not much different, or even worse than editing conf file?
Delete support for cn=config in many cases is part of the OpenLDAP 2.5 release vs OpenLDAP 2.4. It may be simpler to use ldapmodify to adjust the incorrect schema elements. Failing that, you'll want to slapcat the cn=config database, fix it by hand, and re-import via slapadd.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On November 18, 2018 6:06:16 AM GMT+08:00, Quanah Gibson-Mount quanah@symas.com wrote:
Delete support for cn=config in many cases is part of the OpenLDAP 2.5 release vs OpenLDAP 2.4. It may be simpler to use ldapmodify to adjust the incorrect schema elements. Failing that, you'll want to slapcat the cn=config database, fix it by hand, and re-import via slapadd.
Understood. How do I find out what can be changed on the fly, what cannot as of the current git head? Document, pointer to source code all ok.
Thanks
Derek Zhou wrote:
On November 18, 2018 6:06:16 AM GMT+08:00, Quanah Gibson-Mount quanah@symas.com wrote:
Delete support for cn=config in many cases is part of the OpenLDAP 2.5 release vs OpenLDAP 2.4. It may be simpler to use ldapmodify to adjust the incorrect schema elements. Failing that, you'll want to slapcat the cn=config database, fix it by hand, and re-import via slapadd.
Understood. How do I find out what can be changed on the fly, what cannot as of the current git head? Document, pointer to source code all ok.
Everything can be modified. Deleting entries is unsupported in 2.4.
On Sun, Nov 18, 2018 at 09:29:10PM +0000, Howard Chu wrote:
Derek Zhou wrote:
Understood. How do I find out what can be changed on the fly, what cannot as of the current git head? Document, pointer to source code all ok.
Everything can be modified. Deleting entries is unsupported in 2.4.
Very cool. Let me clarify one more thing, if a schema is being modified, and if the current data is imcompatible with the modified schema, will it reject the modification or accept it, and the schema is only enforced for newer data?
Derek
Derek Zhou wrote:
On Sun, Nov 18, 2018 at 09:29:10PM +0000, Howard Chu wrote:
Derek Zhou wrote:
Understood. How do I find out what can be changed on the fly, what cannot as of the current git head? Document, pointer to source code all ok.
Everything can be modified. Deleting entries is unsupported in 2.4.
Very cool. Let me clarify one more thing, if a schema is being modified, and if the current data is imcompatible with the modified schema, will it reject the modification or accept it, and the schema is only enforced for newer data?
It's your responsibility to ensure that no existing data uses the schema you're modifying. The modification will simply be accepted. If you have data in your database using the old definition, and it uses a syntax with different normalization rules than the new version, your database will most likely be corrupted.
On Monday, November 19, 2018 01:49:14 AM Howard Chu wrote:
Derek Zhou wrote:
On Sun, Nov 18, 2018 at 09:29:10PM +0000, Howard Chu wrote:
Derek Zhou wrote:
Understood. How do I find out what can be changed on the fly, what cannot as of the current git head? Document, pointer to source code all ok.
Everything can be modified. Deleting entries is unsupported in 2.4.
Very cool. Let me clarify one more thing, if a schema is being modified, and if the current data is imcompatible with the modified schema, will it reject the modification or accept it, and the schema is only enforced for newer data?
It's your responsibility to ensure that no existing data uses the schema you're modifying. The modification will simply be accepted. If you have data in your database using the old definition, and it uses a syntax with different normalization rules than the new version, your database will most likely be corrupted.
I see. So, is adding an optional (MAY) attribute to an objectClass ok?
Derek Zhou wrote:
On Monday, November 19, 2018 01:49:14 AM Howard Chu wrote:
Derek Zhou wrote:
On Sun, Nov 18, 2018 at 09:29:10PM +0000, Howard Chu wrote:
Derek Zhou wrote:
Understood. How do I find out what can be changed on the fly, what cannot as of the current git head? Document, pointer to source code all ok.
Everything can be modified. Deleting entries is unsupported in 2.4.
Very cool. Let me clarify one more thing, if a schema is being modified, and if the current data is imcompatible with the modified schema, will it reject the modification or accept it, and the schema is only enforced for newer data?
It's your responsibility to ensure that no existing data uses the schema you're modifying. The modification will simply be accepted. If you have data in your database using the old definition, and it uses a syntax with different normalization rules than the new version, your database will most likely be corrupted.
I see. So, is adding an optional (MAY) attribute to an objectClass ok?
Sure, that has no impact on any existing data.
Derek Zhou derek@shannon-data.com schrieb am 17.11.2018 um 09:16 in
Nachricht 9075966.SfyVec2SPM@aaron:
Hi list,
I was experimenting locally written schema with a recent build of slapd. I added the schema ldif with no problem using
ldapadd ‑QY EXTERNAL ‑H ldapi:/// ...
But then I realized I made a mistake, so I try to delete it with
ldapdelete ‑QY EXTERNAL ‑H ldapi:///
it says:
ldap_delete: Server is unwilling to perform (53)
what does it mean? The schema is not used by any data on the server. I can use slapmodify to remove it after server shutdown, but that kind of suck and not
much different, or even worse than editing conf file?
A similar issue exists with olcModuleLoad: You cannot replace it, even if the same modules are there before and afterwards.
Derek
openldap-technical@openldap.org
-
Derek Zhou -
Howard Chu -
Quanah Gibson-Mount -
Ulrich Windl