Hello,
running here OpenLDAP 2.4.42 on Ubuntu 16.04 with a hdb Database.
Some old admin have added 2 custom attributes to the standard nis.schema, years ago. For this OIDs from nis schema has been chosen (1.3.6.1.1.1.1.2.x).
I would like to fix that: Is it possible to move these custom Attributes to our custom Schema, while changing OIDs, also? Or do we have to clear the data DB, move the attrs and reimport a data backup?
Thanks in advance, Tobias
On 9/25/19 12:02 PM, Tobias Hachmer wrote:
running here OpenLDAP 2.4.42 on Ubuntu 16.04 with a hdb Database.
Some old admin have added 2 custom attributes to the standard nis.schema, years ago. For this OIDs from nis schema has been chosen (1.3.6.1.1.1.1.2.x).
I would like to fix that: Is it possible to move these custom Attributes to our custom Schema, while changing OIDs, also? Or do we have to clear the data DB, move the attrs and reimport a data backup?
It might work with back-hdb to change the OID.
IIRC back-mdb needs export / re-import to make the OID change.
Test, test, test... ;-)
Ciao, Michael.
--On Wednesday, September 25, 2019 6:57 PM +0200 Michael Ströder michael@stroeder.com wrote:
IIRC back-mdb needs export / re-import to make the OID change.
Why would back-mdb require an export/import for an OID change in the schema? OpenLDAP does not store the OID internally in the binary databases.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi,
On 9/25/19 6:20 PM, Quanah Gibson-Mount wrote:
--On Wednesday, September 25, 2019 6:57 PM +0200 Michael Ströder michael@stroeder.com wrote:
IIRC back-mdb needs export / re-import to make the OID change.
Why would back-mdb require an export/import for an OID change in the schema? OpenLDAP does not store the OID internally in the binary databases.
Thanks for the replies, but the database backend is "hdb".
The attributes in question were placed in the nis schema cn={3}nis,cn=schema,cn=config: --- {25}( 1.3.6.1.1.1.1.28 NAME 'groupMemberShip' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) {26}( 1.3.6.1.1.1.1.29 NAME 'apple-generateduid' DESC 'generated unique ID' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ---
I have moved these attributes via ldapmodify with this ldif:
--- dn: cn={3}nis,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: #...copy off all schema attributes but the two I want to move...#
dn: cn={5}kerio-mail-server,cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: {15}(1.3.6.1.4.1.10311.1.2.2.29 NAME 'groupMemberShip' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) olcAttributeTypes: {16}(1.3.6.1.4.1.10311.1.2.2.30 NAME 'apple-generateduid' DESC 'generated unique ID' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE) ---
But after that the existing groupMemberShip attributes were purged from the user objects. We use VMs and I have done snapshots before this change, so I could roll back.
Did I move the attributes the wrong way?
Kind regards, Tobias
--On Thursday, September 26, 2019 11:19 AM +0200 Tobias Hachmer tobias@hachmer.de wrote:
Hi,
On 9/25/19 6:20 PM, Quanah Gibson-Mount wrote:
--On Wednesday, September 25, 2019 6:57 PM +0200 Michael Ströder michael@stroeder.com wrote:
IIRC back-mdb needs export / re-import to make the OID change.
Why would back-mdb require an export/import for an OID change in the schema? OpenLDAP does not store the OID internally in the binary databases.
Thanks for the replies, but the database backend is "hdb". Did I move the attributes the wrong way?
It's likely the related objectClass was also modified in the NIS schema, so this is not surprising. You'd need to adjust objectClasses according to the changes as well as the attribute list.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 9/27/19 12:34 AM, Quanah Gibson-Mount wrote:
--On Thursday, September 26, 2019 11:19 AM +0200 Tobias Hachmer tobias@hachmer.de wrote:
Thanks for the replies, but the database backend is "hdb". Did I move the attributes the wrong way?
It's likely the related objectClass was also modified in the NIS schema, so this is not surprising. You'd need to adjust objectClasses according to the changes as well as the attribute list.
Yeah, I recognized my mistake yesterday, also. So, I have tested with this LDIF: https://pastebin.com/kiHJdwfx
The schema was updated correctly, but the groupMemberShip attribute was purged from all objects, again.
This are two operations: 1. Delete the attributes + update objectclassin wrong schema 2. Add attributes + update objectclass in correct schema
Is this the problem that the attributes are purged from all objects after the first operation?
How can I achieve this without attributes get purged from all objects.
Thanks, Tobias
--On Friday, September 27, 2019 11:28 AM +0200 Tobias Hachmer tobias@hachmer.de wrote:
On 9/27/19 12:34 AM, Quanah Gibson-Mount wrote:
--On Thursday, September 26, 2019 11:19 AM +0200 Tobias Hachmer tobias@hachmer.de wrote:
Thanks for the replies, but the database backend is "hdb". Did I move the attributes the wrong way?
It's likely the related objectClass was also modified in the NIS schema, so this is not surprising. You'd need to adjust objectClasses according to the changes as well as the attribute list.
Yeah, I recognized my mistake yesterday, also. So, I have tested with this LDIF: https://pastebin.com/kiHJdwfx
The schema was updated correctly, but the groupMemberShip attribute was purged from all objects, again.
Does every object already have the "kerio-Mail-User" objectClass attached to it?
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Am September 27, 2019 3:23:35 PM UTC schrieb Quanah Gibson-Mount quanah@symas.com:
--On Friday, September 27, 2019 11:28 AM +0200 Tobias Hachmer tobias@hachmer.de wrote:
On 9/27/19 12:34 AM, Quanah Gibson-Mount wrote:
--On Thursday, September 26, 2019 11:19 AM +0200 Tobias Hachmer tobias@hachmer.de wrote:
Thanks for the replies, but the database backend is "hdb". Did I move the attributes the wrong way?
It's likely the related objectClass was also modified in the NIS
schema,
so this is not surprising. You'd need to adjust objectClasses
according
to the changes as well as the attribute list.
Yeah, I recognized my mistake yesterday, also. So, I have tested with this LDIF: https://pastebin.com/kiHJdwfx
The schema was updated correctly, but the groupMemberShip attribute
was
purged from all objects, again.
Does every object already have the "kerio-Mail-User" objectClass attached to it?
Yes, sorry for didn't mention this. When I was talking about the groupMemberShip attrs were purged from all objects. This happens for all objects, whose have the objectclass kerio-Mail-User attached.
Greetz, Tobias
Hi,
On 9/27/19 5:38 PM, Tobias Hachmer wrote:
Am September 27, 2019 3:23:35 PM UTC schrieb Quanah Gibson-Mount quanah@symas.com:
--On Friday, September 27, 2019 11:28 AM +0200 Tobias Hachmer tobias@hachmer.de wrote:
On 9/27/19 12:34 AM, Quanah Gibson-Mount wrote:
--On Thursday, September 26, 2019 11:19 AM +0200 Tobias Hachmer tobias@hachmer.de wrote:
Thanks for the replies, but the database backend is "hdb". Did I move the attributes the wrong way?
It's likely the related objectClass was also modified in the NIS
schema,
so this is not surprising. You'd need to adjust objectClasses
according
to the changes as well as the attribute list.
Yeah, I recognized my mistake yesterday, also. So, I have tested with this LDIF: https://pastebin.com/kiHJdwfx
The schema was updated correctly, but the groupMemberShip attribute
was
purged from all objects, again.
Does every object already have the "kerio-Mail-User" objectClass attached to it?
Yes, sorry for didn't mention this. When I was talking about the groupMemberShip attrs were purged from all objects. This happens for all objects, whose have the objectclass kerio-Mail-User attached.
I just have to restart slapd after schema modification. After that groupMemberShip attrs of "kerio-Mail-User" Objects appeared again.
Thanks, Tobias
--On Monday, September 30, 2019 4:01 PM +0200 Tobias Hachmer tobias@hachmer.de wrote:
Yes, sorry for didn't mention this. When I was talking about the groupMemberShip attrs were purged from all objects. This happens for all objects, whose have the objectclass kerio-Mail-User attached.
I just have to restart slapd after schema modification. After that groupMemberShip attrs of "kerio-Mail-User" Objects appeared again.
Ok, I think that makes some sense, since by changing around the objectClasses you're literally tweaking the data structures slapd had loaded. Glad it's working.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Michael Ströder -
Quanah Gibson-Mount -
Tobias Hachmer