Hi there,
here are a 3 member multimaster config with OpenLDAP 2.4.44 (Debian 9.3).
We need a custom schema, so I've made that - everithing has worked as well, but the customer said he needs to modify some attribute type in the new custom schema.
I've made an ldif:
dn: cn={5}cppm,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {0}( cppmAttrs:1 NAME 'cppmCreateTime' DESC 'Create time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) olcAttributeTypes: {5}( cppmAttrs:6 NAME 'cppmExpireTime' DESC 'Expire time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
# ldapmodify -Y EXTERNAL -H ldapi:/// -f mod1.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn={5}cppm,cn=schema,cn=config"
Then I'ld liked to add this new objectclass to a member of tree, but I got an error:
"cppmDomainName: attribute type undefined"
but - of corse - I've added this attribute to the original schema.
So, I'ld like to backup the config database, but the slapcat said:
# slapcat -b cn=config 5a562aa7 olcObjectClasses: value #0 olcObjectClasses: AttributeType not found: "cppmVisitorCompany" 5a562aa7 config error processing cn={5}cppm,cn=schema,cn=config: olcObjectClasses: AttributeType not found: "cppmVisitorCompany" slapcat: bad configuration file!
What's happenned? What em'I wrong? And what should I do now?
Thanks,
a.
To replace individual values of a multi-valued attribute you must explicitly delete the old value and then add the new one in the same transaction. You cannot use a replace operation to replace individual values of a multi-valued attribute. The replace operation removes all pre-existing values. After loading your ldif your custom schema will only contain the 3 attributes included in your ldif. All of your other custom attributes will be gone.
At this point you will need to create and load a new ldif that will add all of the missing attribute definitions. When I modify a custom schema I use the replace operation but my ldif contains all of the object class and attribute type definitions related to that schema. This way the schema can be maintained as a versioned artifact in my version control system.
JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER@AEP.COM | D:614.716.4970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Ervin Hegedüs Sent: Wednesday, January 10, 2018 10:17 AM To: openldap-technical@openldap.org Subject: [EXTERNAL] Incosistent config after schema modification
This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments. If suspicious please forward to incidents@aep.com for review.
********************************************************************** Hi there,
here are a 3 member multimaster config with OpenLDAP 2.4.44 (Debian 9.3).
We need a custom schema, so I've made that - everithing has worked as well, but the customer said he needs to modify some attribute type in the new custom schema.
I've made an ldif:
dn: cn={5}cppm,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {0}( cppmAttrs:1 NAME 'cppmCreateTime' DESC 'Create time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) olcAttributeTypes: {5}( cppmAttrs:6 NAME 'cppmExpireTime' DESC 'Expire time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
# ldapmodify -Y EXTERNAL -H ldapi:/// -f mod1.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn={5}cppm,cn=schema,cn=config"
Then I'ld liked to add this new objectclass to a member of tree, but I got an error:
"cppmDomainName: attribute type undefined"
but - of corse - I've added this attribute to the original schema.
So, I'ld like to backup the config database, but the slapcat said:
# slapcat -b cn=config 5a562aa7 olcObjectClasses: value #0 olcObjectClasses: AttributeType not found: "cppmVisitorCompany" 5a562aa7 config error processing cn={5}cppm,cn=schema,cn=config: olcObjectClasses: AttributeType not found: "cppmVisitorCompany" slapcat: bad configuration file!
What's happenned? What em'I wrong? And what should I do now?
Thanks,
a.
--On Wednesday, January 10, 2018 6:16 PM +0000 Jon C Kidder jckidder@aep.com wrote:
To replace individual values of a multi-valued attribute you must explicitly delete the old value and then add the new one in the same transaction. You cannot use a replace operation to replace individual values of a multi-valued attribute. The replace operation removes all pre-existing values. After loading your ldif your custom schema will only contain the 3 attributes included in your ldif. All of your other custom attributes will be gone. At this point you will need to create and load a new ldif that will add all of the missing attribute definitions. When I modify a custom schema I use the replace operation but my ldif contains all of the object class and attribute type definitions related to that schema. This way the schema can be maintained as a versioned artifact in my version control system.
As a side note, you can delete specific values by using their weight, as well. For example:
dn: <whatever> changetype: modify delete: olcAttributeTypes olcAttributeTypes: {7}
Would delete the 8th attribute (since the weights are zero based)
You can also use the weight to insert a value, like:
dn: <whatever> changetype: modify add: olcAttributeTypes olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
would insert cppmAttrs as the 8th value, and anything from what was the 8th value and up would be renumbered accordingly.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi Quanah,
thanks,
On Wed, Jan 10, 2018 at 10:24:22AM -0800, Quanah Gibson-Mount wrote:
--On Wednesday, January 10, 2018 6:16 PM +0000 Jon C Kidder
[...]
As a side note, you can delete specific values by using their weight, as well. For example:
dn: <whatever> changetype: modify delete: olcAttributeTypes olcAttributeTypes: {7}
Would delete the 8th attribute (since the weights are zero based)
You can also use the weight to insert a value, like:
dn: <whatever> changetype: modify add: olcAttributeTypes olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
would insert cppmAttrs as the 8th value, and anything from what was the 8th value and up would be renumbered accordingly.
is there any relevant difference between the replace and delete/add methods, which triggered this state in the DB?
What's the solution to avoid this?
Thanks,
a.
--On Wednesday, January 10, 2018 9:11 PM +0100 Ervin Hegedüs airween@gmail.com wrote:
is there any relevant difference between the replace and delete/add methods, which triggered this state in the DB?
Jon already answered that. When you use replace, it replaces *all* values with what you supply in the operation.
What's the solution to avoid this?
Don't use replace.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi,
On Wed, Jan 10, 2018 at 12:17:47PM -0800, Quanah Gibson-Mount wrote:
--On Wednesday, January 10, 2018 9:11 PM +0100 Ervin Hegedüs airween@gmail.com wrote:
is there any relevant difference between the replace and delete/add methods, which triggered this state in the DB?
Jon already answered that. When you use replace, it replaces *all* values with what you supply in the operation.
but he wrote the answer for MULTI-VALUE's attribute, but I'm useing SINGLE-VALUE - or em I missing?
What's the solution to avoid this?
Don't use replace.
right, after this issue I'll never use it :).
But I still don't understand, that when I replace the *all* values to the supplied type(s), then why disappears the "other" attributes, which weren't listed in transaction? And why allows this transaction the DB, and then gone to a wrong state?
a.
--On Wednesday, January 10, 2018 9:46 PM +0100 Ervin Hegedüs airween@gmail.com wrote:
Hi,
On Wed, Jan 10, 2018 at 12:17:47PM -0800, Quanah Gibson-Mount wrote:
--On Wednesday, January 10, 2018 9:11 PM +0100 Ervin Hegedüs airween@gmail.com wrote:
is there any relevant difference between the replace and delete/add methods, which triggered this state in the DB?
Jon already answered that. When you use replace, it replaces *all* values with what you supply in the operation.
but he wrote the answer for MULTI-VALUE's attribute, but I'm useing SINGLE-VALUE - or em I missing?
This is clearly multiple values for the "olcAttributeTypes" attribute:
dn: cn={5}cppm,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {0}( cppmAttrs:1 NAME 'cppmCreateTime' DESC 'Create time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) olcAttributeTypes: {5}( cppmAttrs:6 NAME 'cppmExpireTime' DESC 'Expire time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
You supplied 3 values for it with a replace operation. Which means *only* those 3 values now exist for that object.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi Quanah,
On Wed, Jan 10, 2018 at 01:03:42PM -0800, Quanah Gibson-Mount wrote:
but he wrote the answer for MULTI-VALUE's attribute, but I'm useing SINGLE-VALUE - or em I missing?
This is clearly multiple values for the "olcAttributeTypes" attribute:
dn: cn={5}cppm,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {0}( cppmAttrs:1 NAME 'cppmCreateTime' DESC 'Create time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) olcAttributeTypes: {5}( cppmAttrs:6 NAME 'cppmExpireTime' DESC 'Expire time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
You supplied 3 values for it with a replace operation. Which means *only* those 3 values now exist for that object.
thanks - now it's clear.
Just one question: is it possible to change its types with delete and re-add again, instead of replace?
a.
--On Wednesday, January 10, 2018 10:23 PM +0100 Ervin Hegedüs airween@gmail.com wrote:
thanks - now it's clear.
Just one question: is it possible to change its types with delete and re-add again, instead of replace?
Generally you want to use delete/add and not replace, as noted. I hope that answers the question, as I'm not 100% clear what you're asking. ;)
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi Quanah,
On Wed, Jan 10, 2018 at 01:29:05PM -0800, Quanah Gibson-Mount wrote:
--On Wednesday, January 10, 2018 10:23 PM +0100 Ervin Hegedüs airween@gmail.com wrote:
thanks - now it's clear.
Just one question: is it possible to change its types with delete and re-add again, instead of replace?
Generally you want to use delete/add and not replace, as noted. I hope that answers the question, as I'm not 100% clear what you're asking. ;)
sure :) - and sorry, I meant that if I want to change the type of few arguments, then I can do it with delete/add. Also I can do it with all arguments.
And in case of all arguments, I can use replace (as I did it today).
Thanks for your pation and help,
a.
Ervin Hegedüs wrote:
Hi,
On Wed, Jan 10, 2018 at 12:17:47PM -0800, Quanah Gibson-Mount wrote:
--On Wednesday, January 10, 2018 9:11 PM +0100 Ervin Hegedüs airween@gmail.com wrote:
is there any relevant difference between the replace and delete/add methods, which triggered this state in the DB?
Jon already answered that. When you use replace, it replaces *all* values with what you supply in the operation.
but he wrote the answer for MULTI-VALUE's attribute, but I'm useing SINGLE-VALUE - or em I missing?
While the attribute types you're defining might be SINGE-VALUE the attribute 'olcAttributeTypes' you're adding the attribute type descriptions to is indeed multi-valued. Otherwise you could not add multiple values (here attribute type descriptions) to it.
Don't use replace.
right, after this issue I'll never use it :).
But I still don't understand, that when I replace the *all* values to the supplied type(s), then why disappears the "other" attributes, which weren't listed in transaction?
Because that's how LDAP modify operations with MOD_REPLACE work.
See description of "operation" herein:
https://tools.ietf.org/html/rfc4511#section-4.6
Also it's a good idea to take a look at Howard's draft about ordered entries and values because 'olcAttributeTypes' is declared with X-ORDERED:
https://tools.ietf.org/html/draft-chu-ldap-xordered
Ciao, Michael.
Hi Michael,
On Thu, Jan 11, 2018 at 10:04:22AM +0100, Michael Ströder wrote:
Ervin Hegedüs wrote:
Hi,
On Wed, Jan 10, 2018 at 12:17:47PM -0800, Quanah Gibson-Mount wrote:
--On Wednesday, January 10, 2018 9:11 PM +0100 Ervin Hegedüs airween@gmail.com wrote:
is there any relevant difference between the replace and delete/add methods, which triggered this state in the DB?
Jon already answered that. When you use replace, it replaces *all* values with what you supply in the operation.
but he wrote the answer for MULTI-VALUE's attribute, but I'm useing SINGLE-VALUE - or em I missing?
While the attribute types you're defining might be SINGE-VALUE the attribute 'olcAttributeTypes' you're adding the attribute type descriptions to is indeed multi-valued. Otherwise you could not add multiple values (here attribute type descriptions) to it.
meantime turned out to me, that in first answer Jon talked about the more-that-one attributes, when he wrote "You cannot use a replace operation to replace individual values of a multi-valued attribute". I mixed out these concepts.
Don't use replace.
right, after this issue I'll never use it :).
But I still don't understand, that when I replace the *all* values to the supplied type(s), then why disappears the "other" attributes, which weren't listed in transaction?
Because that's how LDAP modify operations with MOD_REPLACE work.
See description of "operation" herein:
thanks, perhaps the relevant part is this:
replace: replace all existing values [...] A replace with no value will delete the entire attribute if it exists.
Also it's a good idea to take a look at Howard's draft about ordered entries and values because 'olcAttributeTypes' is declared with X-ORDERED:
I'll check it out - thanks.
Anyway, I'm doing fine the modifications of schema :).
thanks for all,
a.
Hi All,
Jon, thanks for the reply,
My first (off-topic) question: why did my e-mail came as "EXTERNAL"? Before I sent it, I've checked myself, and looks like I'm member of this list...
On Wed, Jan 10, 2018 at 06:16:59PM +0000, Jon C Kidder wrote:
To replace individual values of a multi-valued attribute you must explicitly delete the old value and then add the new one in the same transaction. You cannot use a replace operation to replace individual values of a multi-valued attribute. The replace operation removes all pre-existing values. After loading your ldif your custom schema will only contain the 3 attributes included in your ldif. All of your other custom attributes will be gone.
those attribute types are SINGLE-VALUE's. I don't understand this part of your answer.
At this point you will need to create and load a new ldif that will add all of the missing attribute definitions. When I modify a custom schema I use the replace operation but my ldif contains all of the object class and attribute type definitions related to that schema. This way the schema can be maintained as a versioned artifact in my version control system.
yes, I've found the solution as you descibed here.
But I'm curious, why occured this state in the DB?
When I run the ldapmodify, the modification replicated immediatelly to all nodes of cluster, and all db came as incosistent.
IMHO the expected result would be an error, when I run the ldapmodify command with these ldif.
Thanks again,
a.
openldap-technical@openldap.org
-
Ervin Hegedüs -
Jon C Kidder -
Michael Ströder -
Quanah Gibson-Mount