I am trying to add the "inetOrgPerson" objectClass, but some users already have the "account" objectClass.
After a long search, I found that you cannot have both. So I am trying to remove "account", and add "inetOrgPerson". But I cannot do that either. I just get the following error :
err=69 text=structural object class modification from 'account' to 'inetOrgPerson' not allowed
If I just try to remove "account", I get
entry failed schema check: no structural object class provided
So, how can I add "inetOrgPerson" and remove "account" ?
Also, I notice that I don't have "account" listed under dn: cn=schema,cn=config. What I have is:
{0}core {1}cosine {2}nis {3}inetorgperson {4}samba {5}apple
Thanks for any help
mi
PS: I just need a "mail" attribute. Maybe there is a simpler way than to add inetOrgPerson with all it's ridiculous attributes like "audio" or "carLicense" ?
On Sep 7, 2011, at 2:26 PM, Mi wrote:
I am trying to add the "inetOrgPerson" objectClass, but some users already have the "account" objectClass.
After a long search, I found that you cannot have both. So I am trying to remove "account", and add "inetOrgPerson". But I cannot do that either. I just get the following error :
err=69 text=structural object class modification from 'account' to 'inetOrgPerson' not allowed
If I just try to remove "account", I get
entry failed schema check: no structural object class provided
So, how can I add "inetOrgPerson" and remove "account" ?
The only way I know is you export the entry, modify the ldif and reimport. I just did that for all our groups, because we extended the schema and wanted that our own objectClass has sup of groupOfUniqueNames.
Also, I notice that I don't have "account" listed under dn: cn=schema,cn=config. What I have is:
{0}core {1}cosine {2}nis {3}inetorgperson {4}samba {5}apple
The account objectClass is in the cosine schema.
Thanks for any help
mi
PS: I just need a "mail" attribute. Maybe there is a simpler way than to add inetOrgPerson with all it's ridiculous attributes like "audio" or "carLicense" ?
I had the same issue when I found I needed the mail attribute 'after the fact'. You can add the extensibleObject objectClass to the account, then you should be able to add the email attr.
Thanks, John
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Marco Schirrmeister Sent: Wednesday, September 07, 2011 7:44 AM To: Mi Cc: openldap-technical@openldap.org Subject: Re: How to replace account with inetOrgPerson?
On Sep 7, 2011, at 2:26 PM, Mi wrote:
I am trying to add the "inetOrgPerson" objectClass, but some users
already have the "account" objectClass.
After a long search, I found that you cannot have both. So I am trying
to remove "account", and add "inetOrgPerson". But I cannot do that either. I just get the following error :
err=69 text=structural object class modification from 'account' to
'inetOrgPerson' not allowed
If I just try to remove "account", I get
entry failed schema check: no structural object class provided
So, how can I add "inetOrgPerson" and remove "account" ?
The only way I know is you export the entry, modify the ldif and reimport. I just did that for all our groups, because we extended the schema and wanted that our own objectClass has sup of groupOfUniqueNames.
Also, I notice that I don't have "account" listed under dn:
cn=schema,cn=config. What I have is:
{0}core {1}cosine {2}nis {3}inetorgperson {4}samba {5}apple
The account objectClass is in the cosine schema.
Thanks for any help
mi
PS: I just need a "mail" attribute. Maybe there is a simpler way than
to add inetOrgPerson with all it's ridiculous attributes like "audio" or "carLicense" ?
This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
Mi wrote:
You can add the extensibleObject objectClass to the account, then you should be able to add the email attr.
That was indeed a very simple workaround for my immediate problem of adding a mail attribute.
While it's simple it's bad practice since it circumenvents schema checking. extensibleObject allows any attribute in an entry!
Ciao, Michael.
On 09/07/2011 02:44 PM, Marco Schirrmeister wrote:
On Sep 7, 2011, at 2:26 PM, Mi wrote:
I am trying to add the "inetOrgPerson" objectClass, but some users already have the "account" objectClass.
After a long search, I found that you cannot have both. So I am trying to remove "account", and add "inetOrgPerson". But I cannot do that either. I just get the following error :
err=69 text=structural object class modification from 'account' to 'inetOrgPerson' not allowedIf I just try to remove "account", I get
entry failed schema check: no structural object class providedSo, how can I add "inetOrgPerson" and remove "account" ?
The only way I know is you export the entry, modify the ldif and reimport. I just did that for all our groups, because we extended the schema and wanted that our own objectClass has sup of groupOfUniqueNames.
Or, to use the "relax" control <draft-zeilenga-ldap-relax>; you need "manage" access to do that (or act as the rootdn). Please read that document carefully before acting.
p.
On Sep 7, 2011, at 3:56 PM, Pierangelo Masarati wrote:
On 09/07/2011 02:44 PM, Marco Schirrmeister wrote:
On Sep 7, 2011, at 2:26 PM, Mi wrote:
I am trying to add the "inetOrgPerson" objectClass, but some users already have the "account" objectClass.
After a long search, I found that you cannot have both. So I am trying to remove "account", and add "inetOrgPerson". But I cannot do that either. I just get the following error :
err=69 text=structural object class modification from 'account' to 'inetOrgPerson' not allowed
If I just try to remove "account", I get
entry failed schema check: no structural object class provided
So, how can I add "inetOrgPerson" and remove "account" ?
The only way I know is you export the entry, modify the ldif and reimport. I just did that for all our groups, because we extended the schema and wanted that our own objectClass has sup of groupOfUniqueNames.
Or, to use the "relax" control <draft-zeilenga-ldap-relax>; you need "manage" access to do that (or act as the rootdn). Please read that document carefully before acting.
That sounds interesting and I just tried that on my lab env. It was not working. The error was, ldap_modify: Protocol error (2) additional info: relax control value not absent
The OID for relax that I found and used is 1.3.6.1.4.1.4203.666.5.12. Is this oid wrong? Or is it not supported in the latest version of OpenLDAP?
If I query my base for the supported controls, I see 9 oids, but none of it is related to a relax control. I'm running version 2.4.26
-- Marco
On Sep 7, 2011, at 3:56 PM, Pierangelo Masarati wrote:
On 09/07/2011 02:44 PM, Marco Schirrmeister wrote:
On Sep 7, 2011, at 2:26 PM, Mi wrote:
I am trying to add the "inetOrgPerson" objectClass, but some users already have the "account" objectClass.
After a long search, I found that you cannot have both. So I am trying to remove "account", and add "inetOrgPerson". But I cannot do that either. I just get the following error :
err=69 text=structural object class modification from 'account' to 'inetOrgPerson' not allowed
If I just try to remove "account", I get
entry failed schema check: no structural object class provided
So, how can I add "inetOrgPerson" and remove "account" ?
The only way I know is you export the entry, modify the ldif and reimport. I just did that for all our groups, because we extended the schema and wanted that our own objectClass has sup of groupOfUniqueNames.
Or, to use the "relax" control <draft-zeilenga-ldap-relax>; you need "manage" access to do that (or act as the rootdn). Please read that document carefully before acting.
That sounds interesting and I just tried that on my lab env. It was not working. The error was, ldap_modify: Protocol error (2) additional info: relax control value not absent
That's a protocol error; the control request was incorrectly formed. It works fine here. In any case, if you can run test037 successfully, it works.
The OID for relax that I found and used is 1.3.6.1.4.1.4203.666.5.12. Is this oid wrong? Or is it not supported in the latest version of OpenLDAP?
If I query my base for the supported controls, I see 9 oids, but none of it is related to a relax control. I'm running version 2.4.26
It is supported (you would get "Critical extension is unavailable (12)" otherwise). Only, it is "hidden", since its specification is still in draft.
p.
Marco Schirrmeister wrote:
On Sep 7, 2011, at 3:56 PM, Pierangelo Masarati wrote:
Or, to use the "relax" control <draft-zeilenga-ldap-relax>;
That sounds interesting and I just tried that on my lab env. It was not working. The error was, ldap_modify: Protocol error (2) additional info: relax control value not absent
How did you send the relax rules control? I assume the LDAP client (which one?) did something wrong.
Ciao, Michael.
On Sep 8, 2011, at 11:26 AM, Michael Ströder wrote:
Marco Schirrmeister wrote:
On Sep 7, 2011, at 3:56 PM, Pierangelo Masarati wrote:
Or, to use the "relax" control <draft-zeilenga-ldap-relax>;
That sounds interesting and I just tried that on my lab env. It was not working. The error was, ldap_modify: Protocol error (2) additional info: relax control value not absent
How did you send the relax rules control? I assume the LDAP client (which one?) did something wrong.
The relex control was specified in the ldif.
dn: cn=test1,ou=groups,dc=company,dc=com control: 1.3.6.1.4.1.4203.666.5.12 changetype: modify delete: objectClass objectClass: groupOfUniqueNames - add: objectClass objectClass: companyGroup -
I used yesterday the ldapmodify client on my Mac. I just tried it with the ldapmodify on the server it self. Which aborts.
ldapmodify2.4 -x -H ldaps://localhost -D cn=manager,dc=company,dc=com -W -f testgroup-mod.ldif Enter LDAP Password:
modifying entry "cn=test1,ou=groups,dc=company,dc=com" ldapmodify2.4: update failed: cn=test1,ou=groups,dc=company,dc=com ldap_modify: Encoding error (-3)
*** glibc detected *** ldapmodify2.4: free(): invalid pointer: 0x00000000004015d2 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x75676)[0x7f25ef544676] /usr/lib64/oldap24/libldap-2.4.so.2(ldap_control_free+0x30)[0x7f25f06c9e10] /usr/lib64/oldap24/libldap-2.4.so.2(ldap_controls_free+0x25)[0x7f25f06ca085] ldapmodify2.4[0x403dc7] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f25ef4edc5d] ldapmodify2.4[0x402ab9] ======= Memory map: ======== 00400000-0040f000 r-xp 00000000 08:01 18317 /usr/bin/ldapmodify2.4 0060f000-00610000 rw-p 0000f000 08:01 18317 /usr/bin/ldapmodify2.4 01f0f000-01ff5000 rw-p 00000000 00:00 0 [heap] 7f25ed8af000-7f25ed8c5000 r-xp 00000000 08:01 38 /lib64/libgcc_s-4.4.4-20100726.so.1 7f25ed8c5000-7f25edac4000 ---p 00016000 08:01 38 /lib64/libgcc_s-4.4.4-20100726.so.1 7f25edac4000-7f25edac5000 rw-p 00015000 08:01 38 /lib64/libgcc_s-4.4.4-20100726.so.1 7f25edac5000-7f25edad1000 r-xp 00000000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edad1000-7f25edcd0000 ---p 0000c000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edcd0000-7f25edcd1000 r--p 0000b000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edcd1000-7f25edcd2000 rw-p 0000c000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edcd2000-7f25edcef000 r-xp 00000000 08:01 3727 /lib64/libselinux.so.1 7f25edcef000-7f25edeee000 ---p 0001d000 08:01 3727 /lib64/libselinux.so.1 7f25edeee000-7f25edeef000 r--p 0001c000 08:01 3727 /lib64/libselinux.so.1 7f25edeef000-7f25edef0000 rw-p 0001d000 08:01 3727 /lib64/libselinux.so.1 7f25edef0000-7f25edef1000 rw-p 00000000 00:00 0 7f25edef1000-7f25edf08000 r-xp 00000000 08:01 3198 /lib64/libpthread-2.12.so 7f25edf08000-7f25ee108000 ---p 00017000 08:01 3198 /lib64/libpthread-2.12.so 7f25ee108000-7f25ee109000 r--p 00017000 08:01 3198 /lib64/libpthread-2.12.so 7f25ee109000-7f25ee10a000 rw-p 00018000 08:01 3198 /lib64/libpthread-2.12.so 7f25ee10a000-7f25ee10e000 rw-p 00000000 00:00 0 7f25ee10e000-7f25ee110000 r-xp 00000000 08:01 5990 /lib64/libkeyutils.so.1.3 7f25ee110000-7f25ee30f000 ---p 00002000 08:01 5990 /lib64/libkeyutils.so.1.3 7f25ee30f000-7f25ee310000 rw-p 00001000 08:01 5990 /lib64/libkeyutils.so.1.3 7f25ee310000-7f25ee31a000 r-xp 00000000 08:01 6000 /lib64/libkrb5support.so.0.1 7f25ee31a000-7f25ee519000 ---p 0000a000 08:01 6000 /lib64/libkrb5support.so.0.1 7f25ee519000-7f25ee51a000 rw-p 00009000 08:01 6000 /lib64/libkrb5support.so.0.1 7f25ee51a000-7f25ee572000 r-xp 00000000 08:01 3157 /lib64/libfreebl3.so 7f25ee572000-7f25ee771000 ---p 00058000 08:01 3157 /lib64/libfreebl3.so 7f25ee771000-7f25ee773000 rw-p 00057000 08:01 3157 /lib64/libfreebl3.so 7f25ee773000-7f25ee777000 rw-p 00000000 00:00 0 7f25ee777000-7f25ee78c000 r-xp 00000000 08:01 3592 /lib64/libz.so.1.2.3 7f25ee78c000-7f25ee98b000 ---p 00015000 08:01 3592 /lib64/libz.so.1.2.3 7f25ee98b000-7f25ee98c000 rw-p 00014000 08:01 3592 /lib64/libz.so.1.2.3 7f25ee98c000-7f25ee9b3000 r-xp 00000000 08:01 5996 /lib64/libk5crypto.so.3.1 7f25ee9b3000-7f25eebb3000 ---p 00027000 08:01 5996 /lib64/libk5crypto.so.3.1 7f25eebb3000-7f25eebb5000 rw-p 00027000 08:01 5996 /lib64/libk5crypto.so.3.1 7f25eebb5000-7f25eebb8000 r-xp 00000000 08:01 3719 /lib64/libcom_err.so.2.1 7f25eebb8000-7f25eedb7000 ---p 00003000 08:01 3719 /lib64/libcom_err.so.2.1 7f25eedb7000-7f25eedb8000 rw-p 00002000 08:01 3719 /lib64/libcom_err.so.2.1 7f25eedb8000-7f25eee88000 r-xp 00000000 08:01 5998 /lib64/libkrb5.so.3.3 7f25eee88000-7f25ef087000 ---p 000d0000 08:01 5998 /lib64/libkrb5.so.3.3 7f25ef087000-7f25ef092000 rw-p 000cf000 08:01 5998 /lib64/libkrb5.so.3.3 7f25ef092000-7f25ef0ca000 r-xp 00000000 08:01 5992 /lib64/libgssapi_krb5.so.2.2 7f25ef0ca000-7f25ef2c9000 ---p 00038000 08:01 5992 /lib64/libgssapi_krb5.so.2.2 7f25ef2c9000-7f25ef2cb000 rw-p 00037000 08:01 5992 /lib64/libgssapi_krb5.so.2.2 7f25ef2cb000-7f25ef2cd000 r-xp 00000000 08:01 3180 /lib64/libdl-2.12.so 7f25ef2cd000-7f25ef4cd000 ---p 00002000 08:01 3180 /lib64/libdl-2.12.so 7f25ef4cd000-7f25ef4ce000 r--p 00002000 08:01 3180 /lib64/libdl-2.12.so 7f25ef4ce000-7f25ef4cf000 rw-p 00003000 08:01 3180 /lib64/libdl-2.12.so 7f25ef4cf000-7f25ef644000 r-xp 00000000 08:01 3174 /lib64/libc-2.12.so 7f25ef644000-7f25ef844000 ---p 00175000 08:01 3174 /lib64/libc-2.12.so 7f25ef844000-7f25ef848000 r--p 00175000 08:01 3174 /lib64/libc-2.12.so 7f25ef848000-7f25ef849000 rw-p 00179000 08:01 3174 /lib64/libc-2.12.so 7f25ef849000-7f25ef84e000 rw-p 00000000 00:00 0 7f25ef84e000-7f25ef864000 r-xp 00000000 08:01 3200 /lib64/libresolv-2.12.so 7f25ef864000-7f25efa64000 ---p 00016000 08:01 3200 /lib64/libresolv-2.12.so 7f25efa64000-7f25efa65000 r--p 00016000 08:01 3200 /lib64/libresolv-2.12.so 7f25efa65000-7f25efa66000 rw-p 00017000 08:01 3200 /lib64/libresolv-2.12.so 7f25efa66000-7f25efa68000 rw-p 00000000 00:00 0 7f25efa68000-7f25efa6f000 r-xp 00000000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efa6f000-7f25efc6f000 ---p 00007000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efc6f000-7f25efc70000 r--p 00007000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efc70000-7f25efc71000 rw-p 00008000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efc71000-7f25efc9f000 rw-p 00000000 00:00 0 7f25efc9f000-7f25efe10000 r-xp 00000000 08:01 6038 /usr/lib64/libcrypto.so.1.0.0 7f25efe10000-7f25f000f000 ---p 00171000 08:01 6038 /usr/lib64/libcrypto.so.1.0.0 7f25f000f000-7f25f0032000 rw-p 00170000 08:01 6038 /usr/lib64/libcrypto.so.1.0.0 7f25f0032000-7f25f0035000 rw-p 00000000 00:00 0 7f25f0035000-7f25f0088000 r-xp 00000000 08:01 6040 /usr/lib64/libssl.so.1.0.0 7f25f0088000-7f25f0288000 ---p 00053000 08:01 6040 /usr/lib64/libssl.so.1.0.0 7f25f0288000-7f25f0290000 rw-p 00053000 08:01 6040 /usr/lib64/libssl.so.1.0.0 7f25f0290000-7f25f02a9000 r-xp 00000000 08:01 4381 /usr/lib64/libsasl2.so.2.0.23 7f25f02a9000-7f25f04a9000 ---p 00019000 08:01 4381 /usr/lib64/libsasl2.so.2.0.23 7f25f04a9000-7f25f04aa000 rw-p 00019000 08:01 4381 /usr/lib64/libsasl2.so.2.0.23 7f25f04aa000-7f25f04b7000 r-xp 00000000 08:01 11379 /usr/lib64/oldap24/liblber-2.4.so.2.7.1 7f25f04b7000-7f25f06b7000 ---p 0000d000 08:01 11379 /usr/lib64/oldap24/liblber-2.4.so.2.7.1 7f25f06b7000-7f25f06b8000 rw-p 0000d000 08:01 11379 /usr/lib64/oldap24/liblber-2.4.so.2.7.1 7f25f06b8000-7f25f06fd000 r-xp 00000000 08:01 11381 /usr/lib64/oldap24/libldap-2.4.so.2.7.1 7f25f06fd000-7f25f08fd000 ---p 00045000 08:01 11381 /usr/lib64/oldap24/libldap-2.4.so.2.7.1 7f25f08fd000-7f25f08ff000 rw-p 00045000 08:01 11381 /usr/lib64/oldap24/libldap-2.4.so.2.7.1 7f25f08ff000-7f25f091d000 r-xp 00000000 08:01 3167 /lib64/ld-2.12.so 7f25f0b0d000-7f25f0b16000 rw-p 00000000 00:00 0 7f25f0b19000-7f25f0b1d000 rw-p 00000000 00:00 0 7f25f0b1d000-7f25f0b1e000 r--p 0001e000 08:01 3167 /lib64/ld-2.12.so 7f25f0b1e000-7f25f0b1f000 rw-p 0001f000 08:01 3167 /lib64/ld-2.12.so 7f25f0b1f000-7f25f0b20000 rw-p 00000000 00:00 0 7fff2c57e000-7fff2c593000 rw-p 00000000 00:00 0 [stack] 7fff2c5ff000-7fff2c600000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted
-- Marco
On Sep 8, 2011, at 11:26 AM, Michael Ströder wrote:
Marco Schirrmeister wrote:
On Sep 7, 2011, at 3:56 PM, Pierangelo Masarati wrote:
Or, to use the "relax" control <draft-zeilenga-ldap-relax>;
That sounds interesting and I just tried that on my lab env. It was not working. The error was, ldap_modify: Protocol error (2) additional info: relax control value not absent
How did you send the relax rules control? I assume the LDAP client (which one?) did something wrong.
The relex control was specified in the ldif.
dn: cn=test1,ou=groups,dc=company,dc=com control: 1.3.6.1.4.1.4203.666.5.12 changetype: modify delete: objectClass objectClass: groupOfUniqueNames
add: objectClass objectClass: companyGroup
I used yesterday the ldapmodify client on my Mac. I just tried it with the ldapmodify on the server it self. Which aborts.
ldapmodify2.4 -x -H ldaps://localhost -D cn=manager,dc=company,dc=com -W -f testgroup-mod.ldif Enter LDAP Password:
modifying entry "cn=test1,ou=groups,dc=company,dc=com" ldapmodify2.4: update failed: cn=test1,ou=groups,dc=company,dc=com ldap_modify: Encoding error (-3)
*** glibc detected *** ldapmodify2.4: free(): invalid pointer: 0x00000000004015d2 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x75676)[0x7f25ef544676] /usr/lib64/oldap24/libldap-2.4.so.2(ldap_control_free+0x30)[0x7f25f06c9e10] /usr/lib64/oldap24/libldap-2.4.so.2(ldap_controls_free+0x25)[0x7f25f06ca085] ldapmodify2.4[0x403dc7] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f25ef4edc5d] ldapmodify2.4[0x402ab9] ======= Memory map: ======== 00400000-0040f000 r-xp 00000000 08:01 18317 /usr/bin/ldapmodify2.4 0060f000-00610000 rw-p 0000f000 08:01 18317 /usr/bin/ldapmodify2.4 01f0f000-01ff5000 rw-p 00000000 00:00 0 [heap] 7f25ed8af000-7f25ed8c5000 r-xp 00000000 08:01 38 /lib64/libgcc_s-4.4.4-20100726.so.1 7f25ed8c5000-7f25edac4000 ---p 00016000 08:01 38 /lib64/libgcc_s-4.4.4-20100726.so.1 7f25edac4000-7f25edac5000 rw-p 00015000 08:01 38 /lib64/libgcc_s-4.4.4-20100726.so.1 7f25edac5000-7f25edad1000 r-xp 00000000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edad1000-7f25edcd0000 ---p 0000c000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edcd0000-7f25edcd1000 r--p 0000b000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edcd1000-7f25edcd2000 rw-p 0000c000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edcd2000-7f25edcef000 r-xp 00000000 08:01 3727 /lib64/libselinux.so.1 7f25edcef000-7f25edeee000 ---p 0001d000 08:01 3727 /lib64/libselinux.so.1 7f25edeee000-7f25edeef000 r--p 0001c000 08:01 3727 /lib64/libselinux.so.1 7f25edeef000-7f25edef0000 rw-p 0001d000 08:01 3727 /lib64/libselinux.so.1 7f25edef0000-7f25edef1000 rw-p 00000000 00:00 0 7f25edef1000-7f25edf08000 r-xp 00000000 08:01 3198 /lib64/libpthread-2.12.so 7f25edf08000-7f25ee108000 ---p 00017000 08:01 3198 /lib64/libpthread-2.12.so 7f25ee108000-7f25ee109000 r--p 00017000 08:01 3198 /lib64/libpthread-2.12.so 7f25ee109000-7f25ee10a000 rw-p 00018000 08:01 3198 /lib64/libpthread-2.12.so 7f25ee10a000-7f25ee10e000 rw-p 00000000 00:00 0 7f25ee10e000-7f25ee110000 r-xp 00000000 08:01 5990 /lib64/libkeyutils.so.1.3 7f25ee110000-7f25ee30f000 ---p 00002000 08:01 5990 /lib64/libkeyutils.so.1.3 7f25ee30f000-7f25ee310000 rw-p 00001000 08:01 5990 /lib64/libkeyutils.so.1.3 7f25ee310000-7f25ee31a000 r-xp 00000000 08:01 6000 /lib64/libkrb5support.so.0.1 7f25ee31a000-7f25ee519000 ---p 0000a000 08:01 6000 /lib64/libkrb5support.so.0.1 7f25ee519000-7f25ee51a000 rw-p 00009000 08:01 6000 /lib64/libkrb5support.so.0.1 7f25ee51a000-7f25ee572000 r-xp 00000000 08:01 3157 /lib64/libfreebl3.so 7f25ee572000-7f25ee771000 ---p 00058000 08:01 3157 /lib64/libfreebl3.so 7f25ee771000-7f25ee773000 rw-p 00057000 08:01 3157 /lib64/libfreebl3.so 7f25ee773000-7f25ee777000 rw-p 00000000 00:00 0 7f25ee777000-7f25ee78c000 r-xp 00000000 08:01 3592 /lib64/libz.so.1.2.3 7f25ee78c000-7f25ee98b000 ---p 00015000 08:01 3592 /lib64/libz.so.1.2.3 7f25ee98b000-7f25ee98c000 rw-p 00014000 08:01 3592 /lib64/libz.so.1.2.3 7f25ee98c000-7f25ee9b3000 r-xp 00000000 08:01 5996 /lib64/libk5crypto.so.3.1 7f25ee9b3000-7f25eebb3000 ---p 00027000 08:01 5996 /lib64/libk5crypto.so.3.1 7f25eebb3000-7f25eebb5000 rw-p 00027000 08:01 5996 /lib64/libk5crypto.so.3.1 7f25eebb5000-7f25eebb8000 r-xp 00000000 08:01 3719 /lib64/libcom_err.so.2.1 7f25eebb8000-7f25eedb7000 ---p 00003000 08:01 3719 /lib64/libcom_err.so.2.1 7f25eedb7000-7f25eedb8000 rw-p 00002000 08:01 3719 /lib64/libcom_err.so.2.1 7f25eedb8000-7f25eee88000 r-xp 00000000 08:01 5998 /lib64/libkrb5.so.3.3 7f25eee88000-7f25ef087000 ---p 000d0000 08:01 5998 /lib64/libkrb5.so.3.3 7f25ef087000-7f25ef092000 rw-p 000cf000 08:01 5998 /lib64/libkrb5.so.3.3 7f25ef092000-7f25ef0ca000 r-xp 00000000 08:01 5992 /lib64/libgssapi_krb5.so.2.2 7f25ef0ca000-7f25ef2c9000 ---p 00038000 08:01 5992 /lib64/libgssapi_krb5.so.2.2 7f25ef2c9000-7f25ef2cb000 rw-p 00037000 08:01 5992 /lib64/libgssapi_krb5.so.2.2 7f25ef2cb000-7f25ef2cd000 r-xp 00000000 08:01 3180 /lib64/libdl-2.12.so 7f25ef2cd000-7f25ef4cd000 ---p 00002000 08:01 3180 /lib64/libdl-2.12.so 7f25ef4cd000-7f25ef4ce000 r--p 00002000 08:01 3180 /lib64/libdl-2.12.so 7f25ef4ce000-7f25ef4cf000 rw-p 00003000 08:01 3180 /lib64/libdl-2.12.so 7f25ef4cf000-7f25ef644000 r-xp 00000000 08:01 3174 /lib64/libc-2.12.so 7f25ef644000-7f25ef844000 ---p 00175000 08:01 3174 /lib64/libc-2.12.so 7f25ef844000-7f25ef848000 r--p 00175000 08:01 3174 /lib64/libc-2.12.so 7f25ef848000-7f25ef849000 rw-p 00179000 08:01 3174 /lib64/libc-2.12.so 7f25ef849000-7f25ef84e000 rw-p 00000000 00:00 0 7f25ef84e000-7f25ef864000 r-xp 00000000 08:01 3200 /lib64/libresolv-2.12.so 7f25ef864000-7f25efa64000 ---p 00016000 08:01 3200 /lib64/libresolv-2.12.so 7f25efa64000-7f25efa65000 r--p 00016000 08:01 3200 /lib64/libresolv-2.12.so 7f25efa65000-7f25efa66000 rw-p 00017000 08:01 3200 /lib64/libresolv-2.12.so 7f25efa66000-7f25efa68000 rw-p 00000000 00:00 0 7f25efa68000-7f25efa6f000 r-xp 00000000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efa6f000-7f25efc6f000 ---p 00007000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efc6f000-7f25efc70000 r--p 00007000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efc70000-7f25efc71000 rw-p 00008000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efc71000-7f25efc9f000 rw-p 00000000 00:00 0 7f25efc9f000-7f25efe10000 r-xp 00000000 08:01 6038 /usr/lib64/libcrypto.so.1.0.0 7f25efe10000-7f25f000f000 ---p 00171000 08:01 6038 /usr/lib64/libcrypto.so.1.0.0 7f25f000f000-7f25f0032000 rw-p 00170000 08:01 6038 /usr/lib64/libcrypto.so.1.0.0 7f25f0032000-7f25f0035000 rw-p 00000000 00:00 0 7f25f0035000-7f25f0088000 r-xp 00000000 08:01 6040 /usr/lib64/libssl.so.1.0.0 7f25f0088000-7f25f0288000 ---p 00053000 08:01 6040 /usr/lib64/libssl.so.1.0.0 7f25f0288000-7f25f0290000 rw-p 00053000 08:01 6040 /usr/lib64/libssl.so.1.0.0 7f25f0290000-7f25f02a9000 r-xp 00000000 08:01 4381 /usr/lib64/libsasl2.so.2.0.23 7f25f02a9000-7f25f04a9000 ---p 00019000 08:01 4381 /usr/lib64/libsasl2.so.2.0.23 7f25f04a9000-7f25f04aa000 rw-p 00019000 08:01 4381 /usr/lib64/libsasl2.so.2.0.23 7f25f04aa000-7f25f04b7000 r-xp 00000000 08:01 11379 /usr/lib64/oldap24/liblber-2.4.so.2.7.1 7f25f04b7000-7f25f06b7000 ---p 0000d000 08:01 11379 /usr/lib64/oldap24/liblber-2.4.so.2.7.1 7f25f06b7000-7f25f06b8000 rw-p 0000d000 08:01 11379 /usr/lib64/oldap24/liblber-2.4.so.2.7.1 7f25f06b8000-7f25f06fd000 r-xp 00000000 08:01 11381 /usr/lib64/oldap24/libldap-2.4.so.2.7.1 7f25f06fd000-7f25f08fd000 ---p 00045000 08:01 11381 /usr/lib64/oldap24/libldap-2.4.so.2.7.1 7f25f08fd000-7f25f08ff000 rw-p 00045000 08:01 11381 /usr/lib64/oldap24/libldap-2.4.so.2.7.1 7f25f08ff000-7f25f091d000 r-xp 00000000 08:01 3167 /lib64/ld-2.12.so 7f25f0b0d000-7f25f0b16000 rw-p 00000000 00:00 0 7f25f0b19000-7f25f0b1d000 rw-p 00000000 00:00 0 7f25f0b1d000-7f25f0b1e000 r--p 0001e000 08:01 3167 /lib64/ld-2.12.so 7f25f0b1e000-7f25f0b1f000 rw-p 0001f000 08:01 3167 /lib64/ld-2.12.so 7f25f0b1f000-7f25f0b20000 rw-p 00000000 00:00 0 7fff2c57e000-7fff2c593000 rw-p 00000000 00:00 0 [stack] 7fff2c5ff000-7fff2c600000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted
If this happened with OpenLDAP 2.4.26 you should file an ITS; otherwise I suggest you upgrade, since I recall some recent changes in this area, including fixing memory-related issues.
p.
On Sep 8, 2011, at 9:26 PM, masarati@aero.polimi.it wrote:
On Sep 8, 2011, at 11:26 AM, Michael Ströder wrote:
Marco Schirrmeister wrote:
On Sep 7, 2011, at 3:56 PM, Pierangelo Masarati wrote:
Or, to use the "relax" control <draft-zeilenga-ldap-relax>;
That sounds interesting and I just tried that on my lab env. It was not working. The error was, ldap_modify: Protocol error (2) additional info: relax control value not absent
How did you send the relax rules control? I assume the LDAP client (which one?) did something wrong.
The relex control was specified in the ldif.
dn: cn=test1,ou=groups,dc=company,dc=com control: 1.3.6.1.4.1.4203.666.5.12 changetype: modify delete: objectClass objectClass: groupOfUniqueNames
add: objectClass objectClass: companyGroup
I used yesterday the ldapmodify client on my Mac. I just tried it with the ldapmodify on the server it self. Which aborts.
ldapmodify2.4 -x -H ldaps://localhost -D cn=manager,dc=company,dc=com -W -f testgroup-mod.ldif Enter LDAP Password:
modifying entry "cn=test1,ou=groups,dc=company,dc=com" ldapmodify2.4: update failed: cn=test1,ou=groups,dc=company,dc=com ldap_modify: Encoding error (-3)
*** glibc detected *** ldapmodify2.4: free(): invalid pointer: 0x00000000004015d2 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x75676)[0x7f25ef544676] /usr/lib64/oldap24/libldap-2.4.so.2(ldap_control_free+0x30)[0x7f25f06c9e10] /usr/lib64/oldap24/libldap-2.4.so.2(ldap_controls_free+0x25)[0x7f25f06ca085] ldapmodify2.4[0x403dc7] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f25ef4edc5d] ldapmodify2.4[0x402ab9] ======= Memory map: ======== 00400000-0040f000 r-xp 00000000 08:01 18317 /usr/bin/ldapmodify2.4 0060f000-00610000 rw-p 0000f000 08:01 18317 /usr/bin/ldapmodify2.4 01f0f000-01ff5000 rw-p 00000000 00:00 0 [heap] 7f25ed8af000-7f25ed8c5000 r-xp 00000000 08:01 38 /lib64/libgcc_s-4.4.4-20100726.so.1 7f25ed8c5000-7f25edac4000 ---p 00016000 08:01 38 /lib64/libgcc_s-4.4.4-20100726.so.1 7f25edac4000-7f25edac5000 rw-p 00015000 08:01 38 /lib64/libgcc_s-4.4.4-20100726.so.1 7f25edac5000-7f25edad1000 r-xp 00000000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edad1000-7f25edcd0000 ---p 0000c000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edcd0000-7f25edcd1000 r--p 0000b000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edcd1000-7f25edcd2000 rw-p 0000c000 08:01 3190 /lib64/libnss_files-2.12.so 7f25edcd2000-7f25edcef000 r-xp 00000000 08:01 3727 /lib64/libselinux.so.1 7f25edcef000-7f25edeee000 ---p 0001d000 08:01 3727 /lib64/libselinux.so.1 7f25edeee000-7f25edeef000 r--p 0001c000 08:01 3727 /lib64/libselinux.so.1 7f25edeef000-7f25edef0000 rw-p 0001d000 08:01 3727 /lib64/libselinux.so.1 7f25edef0000-7f25edef1000 rw-p 00000000 00:00 0 7f25edef1000-7f25edf08000 r-xp 00000000 08:01 3198 /lib64/libpthread-2.12.so 7f25edf08000-7f25ee108000 ---p 00017000 08:01 3198 /lib64/libpthread-2.12.so 7f25ee108000-7f25ee109000 r--p 00017000 08:01 3198 /lib64/libpthread-2.12.so 7f25ee109000-7f25ee10a000 rw-p 00018000 08:01 3198 /lib64/libpthread-2.12.so 7f25ee10a000-7f25ee10e000 rw-p 00000000 00:00 0 7f25ee10e000-7f25ee110000 r-xp 00000000 08:01 5990 /lib64/libkeyutils.so.1.3 7f25ee110000-7f25ee30f000 ---p 00002000 08:01 5990 /lib64/libkeyutils.so.1.3 7f25ee30f000-7f25ee310000 rw-p 00001000 08:01 5990 /lib64/libkeyutils.so.1.3 7f25ee310000-7f25ee31a000 r-xp 00000000 08:01 6000 /lib64/libkrb5support.so.0.1 7f25ee31a000-7f25ee519000 ---p 0000a000 08:01 6000 /lib64/libkrb5support.so.0.1 7f25ee519000-7f25ee51a000 rw-p 00009000 08:01 6000 /lib64/libkrb5support.so.0.1 7f25ee51a000-7f25ee572000 r-xp 00000000 08:01 3157 /lib64/libfreebl3.so 7f25ee572000-7f25ee771000 ---p 00058000 08:01 3157 /lib64/libfreebl3.so 7f25ee771000-7f25ee773000 rw-p 00057000 08:01 3157 /lib64/libfreebl3.so 7f25ee773000-7f25ee777000 rw-p 00000000 00:00 0 7f25ee777000-7f25ee78c000 r-xp 00000000 08:01 3592 /lib64/libz.so.1.2.3 7f25ee78c000-7f25ee98b000 ---p 00015000 08:01 3592 /lib64/libz.so.1.2.3 7f25ee98b000-7f25ee98c000 rw-p 00014000 08:01 3592 /lib64/libz.so.1.2.3 7f25ee98c000-7f25ee9b3000 r-xp 00000000 08:01 5996 /lib64/libk5crypto.so.3.1 7f25ee9b3000-7f25eebb3000 ---p 00027000 08:01 5996 /lib64/libk5crypto.so.3.1 7f25eebb3000-7f25eebb5000 rw-p 00027000 08:01 5996 /lib64/libk5crypto.so.3.1 7f25eebb5000-7f25eebb8000 r-xp 00000000 08:01 3719 /lib64/libcom_err.so.2.1 7f25eebb8000-7f25eedb7000 ---p 00003000 08:01 3719 /lib64/libcom_err.so.2.1 7f25eedb7000-7f25eedb8000 rw-p 00002000 08:01 3719 /lib64/libcom_err.so.2.1 7f25eedb8000-7f25eee88000 r-xp 00000000 08:01 5998 /lib64/libkrb5.so.3.3 7f25eee88000-7f25ef087000 ---p 000d0000 08:01 5998 /lib64/libkrb5.so.3.3 7f25ef087000-7f25ef092000 rw-p 000cf000 08:01 5998 /lib64/libkrb5.so.3.3 7f25ef092000-7f25ef0ca000 r-xp 00000000 08:01 5992 /lib64/libgssapi_krb5.so.2.2 7f25ef0ca000-7f25ef2c9000 ---p 00038000 08:01 5992 /lib64/libgssapi_krb5.so.2.2 7f25ef2c9000-7f25ef2cb000 rw-p 00037000 08:01 5992 /lib64/libgssapi_krb5.so.2.2 7f25ef2cb000-7f25ef2cd000 r-xp 00000000 08:01 3180 /lib64/libdl-2.12.so 7f25ef2cd000-7f25ef4cd000 ---p 00002000 08:01 3180 /lib64/libdl-2.12.so 7f25ef4cd000-7f25ef4ce000 r--p 00002000 08:01 3180 /lib64/libdl-2.12.so 7f25ef4ce000-7f25ef4cf000 rw-p 00003000 08:01 3180 /lib64/libdl-2.12.so 7f25ef4cf000-7f25ef644000 r-xp 00000000 08:01 3174 /lib64/libc-2.12.so 7f25ef644000-7f25ef844000 ---p 00175000 08:01 3174 /lib64/libc-2.12.so 7f25ef844000-7f25ef848000 r--p 00175000 08:01 3174 /lib64/libc-2.12.so 7f25ef848000-7f25ef849000 rw-p 00179000 08:01 3174 /lib64/libc-2.12.so 7f25ef849000-7f25ef84e000 rw-p 00000000 00:00 0 7f25ef84e000-7f25ef864000 r-xp 00000000 08:01 3200 /lib64/libresolv-2.12.so 7f25ef864000-7f25efa64000 ---p 00016000 08:01 3200 /lib64/libresolv-2.12.so 7f25efa64000-7f25efa65000 r--p 00016000 08:01 3200 /lib64/libresolv-2.12.so 7f25efa65000-7f25efa66000 rw-p 00017000 08:01 3200 /lib64/libresolv-2.12.so 7f25efa66000-7f25efa68000 rw-p 00000000 00:00 0 7f25efa68000-7f25efa6f000 r-xp 00000000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efa6f000-7f25efc6f000 ---p 00007000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efc6f000-7f25efc70000 r--p 00007000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efc70000-7f25efc71000 rw-p 00008000 08:01 3178 /lib64/libcrypt-2.12.so 7f25efc71000-7f25efc9f000 rw-p 00000000 00:00 0 7f25efc9f000-7f25efe10000 r-xp 00000000 08:01 6038 /usr/lib64/libcrypto.so.1.0.0 7f25efe10000-7f25f000f000 ---p 00171000 08:01 6038 /usr/lib64/libcrypto.so.1.0.0 7f25f000f000-7f25f0032000 rw-p 00170000 08:01 6038 /usr/lib64/libcrypto.so.1.0.0 7f25f0032000-7f25f0035000 rw-p 00000000 00:00 0 7f25f0035000-7f25f0088000 r-xp 00000000 08:01 6040 /usr/lib64/libssl.so.1.0.0 7f25f0088000-7f25f0288000 ---p 00053000 08:01 6040 /usr/lib64/libssl.so.1.0.0 7f25f0288000-7f25f0290000 rw-p 00053000 08:01 6040 /usr/lib64/libssl.so.1.0.0 7f25f0290000-7f25f02a9000 r-xp 00000000 08:01 4381 /usr/lib64/libsasl2.so.2.0.23 7f25f02a9000-7f25f04a9000 ---p 00019000 08:01 4381 /usr/lib64/libsasl2.so.2.0.23 7f25f04a9000-7f25f04aa000 rw-p 00019000 08:01 4381 /usr/lib64/libsasl2.so.2.0.23 7f25f04aa000-7f25f04b7000 r-xp 00000000 08:01 11379 /usr/lib64/oldap24/liblber-2.4.so.2.7.1 7f25f04b7000-7f25f06b7000 ---p 0000d000 08:01 11379 /usr/lib64/oldap24/liblber-2.4.so.2.7.1 7f25f06b7000-7f25f06b8000 rw-p 0000d000 08:01 11379 /usr/lib64/oldap24/liblber-2.4.so.2.7.1 7f25f06b8000-7f25f06fd000 r-xp 00000000 08:01 11381 /usr/lib64/oldap24/libldap-2.4.so.2.7.1 7f25f06fd000-7f25f08fd000 ---p 00045000 08:01 11381 /usr/lib64/oldap24/libldap-2.4.so.2.7.1 7f25f08fd000-7f25f08ff000 rw-p 00045000 08:01 11381 /usr/lib64/oldap24/libldap-2.4.so.2.7.1 7f25f08ff000-7f25f091d000 r-xp 00000000 08:01 3167 /lib64/ld-2.12.so 7f25f0b0d000-7f25f0b16000 rw-p 00000000 00:00 0 7f25f0b19000-7f25f0b1d000 rw-p 00000000 00:00 0 7f25f0b1d000-7f25f0b1e000 r--p 0001e000 08:01 3167 /lib64/ld-2.12.so 7f25f0b1e000-7f25f0b1f000 rw-p 0001f000 08:01 3167 /lib64/ld-2.12.so 7f25f0b1f000-7f25f0b20000 rw-p 00000000 00:00 0 7fff2c57e000-7fff2c593000 rw-p 00000000 00:00 0 [stack] 7fff2c5ff000-7fff2c600000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted
If this happened with OpenLDAP 2.4.26 you should file an ITS; otherwise I suggest you upgrade, since I recall some recent changes in this area, including fixing memory-related issues.
Yes, it is a 2.4.26 rpm on a 64bit CentOS 6. I will try so see if I get more info with gdb before I file an ITS.
-- Marco
If this happened with OpenLDAP 2.4.26 you should file an ITS; otherwise I suggest you upgrade, since I recall some recent changes in this area, including fixing memory-related issues.
Yes, it is a 2.4.26 rpm on a 64bit CentOS 6. I will try so see if I get more info with gdb before I file an ITS.
Thanks for the feedback. I think I spotted the bug; I'll file an ITS about it. I would appreciate if you could test code out of git after the fix is committed. Instructions here http://www.openldap.org/software/repo.html.
Thanks, p.
On Sep 8, 2011, at 11:28 PM, masarati@aero.polimi.it wrote:
If this happened with OpenLDAP 2.4.26 you should file an ITS; otherwise I suggest you upgrade, since I recall some recent changes in this area, including fixing memory-related issues.
Yes, it is a 2.4.26 rpm on a 64bit CentOS 6. I will try so see if I get more info with gdb before I file an ITS.
Thanks for the feedback. I think I spotted the bug; I'll file an ITS about it. I would appreciate if you could test code out of git after the fix is committed. Instructions here http://www.openldap.org/software/repo.html.
Just compiled my git clone and tested the ldapmodify. It works great without an error and I was able to change the structural object class with the relax control online.
ldapmodify -VV ldapmodify: @(#) $OpenLDAP: ldapmodify 2.X (Sep 9 2011 10:39:12) $
Thank you very much.
-- Marco
So, how can I add "inetOrgPerson" and remove "account" ?
The only way I know is you export the entry, modify the ldif and reimport.
I will try that. But I still have the feeling there must be a "better" way of doing it, and I just don't know it...
The account objectClass is in the cosine schema.
So I tried to just delete cosine under cn=config, but that doesn't work. The log shows
DEL dn="cn={1}cosine,cn=schema,cn=config" RESULT tag=107 err=53 text=
and my LDAP browser gives an "Unwilling to Perform" error.
I also tried to remove the apple schema which I had added at one point but don't need any more, and never actually used. Same error.
But, don't you already have the mail attribute that you need through the core.schema.
Looking at the core schema, yes I do see 'mail' in there. However, I cannot populate it. The log shows:
MOD attr=mail RESULT tag=103 err=65 text=attribute 'mail' not allowed
So 'mail' is indeed in core, but cannot be used. Maybe because inetOrgPerson is also part of the schemas?
Hi,
On Wednesday, 7. September 2011, Mi wrote:
So, how can I add "inetOrgPerson" and remove "account" ?
The only way I know is you export the entry, modify the ldif and reimport.
I will try that. But I still have the feeling there must be a "better" way of doing it, and I just don't know it...
Indeed, there is another way. This way even allows you to keep both objectclasses at the objects, and do it all without taking the LDAP server down.
If I remember corrctly, these are the steps:
1) Aquire an OID arc from IANA http://pen.iana.org/pen/PenApplication.page
2) Define a schema file [gere in the slapd.conf form] similar to the one below
# symbolic names for sub-arcs of your OID arc objectIdentifier myOIDroot 1.3.6.1.4.1.YOUR_OID_NO_FROM_IANA objectIdentifier myOIDldap myOIDroot:1 objectIdentifier myOIDattributeType myOIDldap:1 objectIdentifier myOIDobjectClass myOIDldap:2
# objectclass definition objectClass ( myOIDobjectClass:1 'myOIDPerson' DESC 'Person inheriting from account and inetOrgPerson' SUP ( account $ inetOrgPerson ) MUST ( uid $ cn ) )
3) add the missing uid / cn attributes where necessary
4) add the objectclass 'myOIDperson' to all objects you want to have both objectclasses.
5) If you want to have both objectclases mentioned explicitly, you may add the missing one to the myOIDPerson objects
Best Peter
--On Wednesday, September 07, 2011 7:03 PM +0200 Peter Marschall peter@adpm.de wrote:
# objectclass definition objectClass ( myOIDobjectClass:1 'myOIDPerson' DESC 'Person inheriting from account and inetOrgPerson' SUP ( account $ inetOrgPerson ) MUST ( uid $ cn ) )
Is it valid to inherit from two different structural objectClasses? I don't believe so.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On Sep 7, 2011, at 10:18 PM, Quanah Gibson-Mount wrote:
--On Wednesday, September 07, 2011 7:03 PM +0200 Peter Marschall peter@adpm.de wrote:
# objectclass definition objectClass ( myOIDobjectClass:1 'myOIDPerson' DESC 'Person inheriting from account and inetOrgPerson' SUP ( account $ inetOrgPerson ) MUST ( uid $ cn ) )
Is it valid to inherit from two different structural objectClasses? I don't believe so.
I just read about this the other day. Looks like it is valid. (Or was?) I was also surprised when I read this. http://www.zytrax.com/books/ldap/apa/inheritance.html
Not sure how often this is used in practice.
-- Marco
Quanah Gibson-Mount wrote:
--On Wednesday, September 07, 2011 7:03 PM +0200 Peter Marschall peter@adpm.de wrote:
# objectclass definition objectClass ( myOIDobjectClass:1 'myOIDPerson' DESC 'Person inheriting from account and inetOrgPerson' SUP ( account $ inetOrgPerson ) MUST ( uid $ cn ) )
Is it valid to inherit from two different structural objectClasses? I don't believe so.
Of course it is valid.
Ciao, Michael.
Hi,
On Wednesday, 7. September 2011, Quanah Gibson-Mount wrote:
Is it valid to inherit from two different structural objectClasses? I don't believe so.
Works for me with OpenLDAP 2.6.25 (and did so since the 2.[23].x days) See also "pilotOrganization" in cosine.schema.
The only thing I was insecure about in my original mail was the part about the "everything can be done online".
I faintly remember something about a change that required the structural object class of an object to be determined at object creation time, and that it cannot be changed afterwards. As the memory is very faint, it is absolutely possible that it is unrelated to OpenLDAP and refers to another LDAP server implementation.
Best Peter
On 09/08/2011 03:08 PM, Peter Marschall wrote:
Hi,
On Wednesday, 7. September 2011, Quanah Gibson-Mount wrote:
Is it valid to inherit from two different structural objectClasses? I don't believe so.
Works for me with OpenLDAP 2.6.25 (and did so since the 2.[23].x days) See also "pilotOrganization" in cosine.schema.
The only thing I was insecure about in my original mail was the part about the "everything can be done online".
I faintly remember something about a change that required the structural object class of an object to be determined at object creation time, and that it cannot be changed afterwards. As the memory is very faint, it is absolutely possible that it is unrelated to OpenLDAP and refers to another LDAP server implementation.
The structural objectClass of an entry cannot be changed. Period. This is LDAP, not related to the implementation. However, OpenLDAP allows to change it provided the user has "manage" privileges, the "relax" control (draft-zeilenga-ldap-relax) is used, and the resulting entry complies with the data model (i.e. any other change required to comply with the new structural objectclass is performed within the same modification).
p.
Am Wed, 07 Sep 2011 13:18:39 -0700 schrieb Quanah Gibson-Mount quanah@zimbra.com:
--On Wednesday, September 07, 2011 7:03 PM +0200 Peter Marschall peter@adpm.de wrote:
# objectclass definition objectClass ( myOIDobjectClass:1 'myOIDPerson' DESC 'Person inheriting from account and inetOrgPerson' SUP ( account $ inetOrgPerson ) MUST ( uid $ cn ) )
Is it valid to inherit from two different structural objectClasses? I don't believe so.
RFC-4512, section 2.4
An object class may be derived from two or more direct superclasses (superclasses not part of the same superclass chain). This feature of subclassing is termed multiple inheritance.
-Dieter
I am trying to add the "inetOrgPerson" objectClass, but some users already have the "account" objectClass.
After a long search, I found that you cannot have both. So I am trying to remove "account", and add "inetOrgPerson". But I cannot do that either. I just get the following error :
err=69 text=structural object class modification from 'account' to'inetOrgPerson' not allowed
If I just try to remove "account", I get
entry failed schema check: no structural object class providedSo, how can I add "inetOrgPerson" and remove "account" ?
Also, I notice that I don't have "account" listed under dn: cn=schema,cn=config. What I have is:
{0}core {1}cosine {2}nis {3}inetorgperson {4}samba {5}apple
Thanks for any help
mi
PS: I just need a "mail" attribute. Maybe there is a simpler way than to add inetOrgPerson with all it's ridiculous attributes like "audio" or "carLicense" ?
IF your goal is to simply add the 'mail' attr to existing accounts, why not just use the extensibleObject objectClass to each account. Once that is added, you should be able to add the needed attribute. This is what I did and it seems to work fine.
To the OpenLDAP gurus; should this method not be used?
jk
This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
John Kane wrote:
IF your goal is to simply add the 'mail' attr to existing accounts, why not just use the extensibleObject objectClass to each account. Once that is added, you should be able to add the needed attribute. This is what I did and it seems to work fine.
extensibleObject allows any attribute in an entry! This circumvents schema checking.
To the OpenLDAP gurus; should this method not be used?
I consider it bad practice.
Ciao, Michael.
John Kane wrote:
IF your goal is to simply add the 'mail' attr to existing accounts, why not just use the extensibleObject objectClass to each account. Once that is added, you should be able to add the needed attribute. This is what I did and it seems to work fine.
extensibleObject allows any attribute in an entry! This circumvents schema checking.
Thanks for the input, Michael. It is my understanding, from RFC 2252, that adding extensibleObject simply, in effect, adds a wild card to the 'MAY' attribute list for any other object classes included in this DN, and other normal schema checking will still occur (i.e. mandatory attributes for the other object classes will still be required, etc.).
To the OpenLDAP gurus; should this method not be used?
I consider it bad practice.
When I went this route, I assumed it may not be 'best practice', but 'bad practice'? Are there areas in the code where this might be a problem?
Out of curiosity, when might using the extensibeObject be considered 'good practice'? (not trying to 'beat a dead horse', just trying to expand my knowledge)
Ciao, Michael.
Thanks, John
This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
John Kane wrote:
I consider it bad practice.
When I went this route, I assumed it may not be 'best practice', but 'bad practice'? Are there areas in the code where this might be a problem?
If a client application does something wrong there is one barrier less to prevent bad data from being added.
If an entry has object class 'extensibleObject' a generic schema-aware client has to present all attribute types found in the schema in an input form which can get huge then.
etc.
=> Everybody should learn how to define custom object classes and how to use relax rules control for online migration of existing entries.
Ciao, Michael.
openldap-technical@openldap.org
-
Dieter Klünter -
John Kane -
Marco Schirrmeister -
masarati＠aero.polimi.it -
Mi -
Michael Ströder -
Peter Marschall -
Pierangelo Masarati
-
Quanah Gibson-Mount