3:02 a.m.
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
8:57 a.m.
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.
9:20 a.m.
--On Wednesday, September 25, 2019 6:57 PM +0200 Michael Ströder
<michael(a)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>
1:19 a.m.
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(a)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
3:34 p.m.
--On Thursday, September 26, 2019 11:19 AM +0200 Tobias Hachmer
<tobias(a)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(a)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>
1:28 a.m.
On 9/27/19 12:34 AM, Quanah Gibson-Mount wrote:
--On Thursday, September 26, 2019 11:19 AM +0200 Tobias Hachmer
<tobias(a)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
8:23 a.m.
--On Friday, September 27, 2019 11:28 AM +0200 Tobias Hachmer
<tobias(a)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(a)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>
8:38 a.m.
Am September 27, 2019 3:23:35 PM UTC schrieb Quanah Gibson-Mount
<quanah(a)symas.com>:
--On Friday, September 27, 2019 11:28 AM +0200 Tobias Hachmer
<tobias(a)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(a)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
6:01 a.m.
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(a)symas.com>:
> --On Friday, September 27, 2019 11:28 AM +0200 Tobias Hachmer
> <tobias(a)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(a)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
8:32 a.m.
--On Monday, September 30, 2019 4:01 PM +0200 Tobias Hachmer
<tobias(a)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>
561
days inactive
566
days old
openldap-technical@openldap.org
9 comments
3 participants
participants (3)
-
Michael Ströder -
Quanah Gibson-Mount -
Tobias Hachmer