Hello,
I'm trying to delete some problematic entries from our 389 directory. The entry DNs contain < and > (probably found their way into the directory years ago). This causes problems with JNDI where DNs from search results are fed directly back into more searches because these particular DNs are somehow returned in in escaped form. E.g. ou=my<problematic>entry,dc=example,dc=com becomes ou=my<problematic>entry,dc=example,dc=com, causing error 32. I'm not sure if it's the directory server or JNDI adding the escaping, as ldapsearch from the command line doesn't seem to behave this way, but it doesn't really matter: I want to remove the entries and get rid of the issue. Unfortunately, I'm unable to:
$ ldapdelete -D "cn=directory manager" -WxH "ldap://example.com:389" "ou=my<problematic>entry,dc=example,dc=com" Enter LDAP Password: ldap_delete: Invalid DN syntax (34) additional info: DN value invalid per syntax
I've also tried deleting through Apache Directory Studio, error 34 there as well.
So, any ideas on how to get rid of them? The only thing I can think of is to db2ldif the entire directory, manually excise the entries from the LDIF file and then re-import. But I'd rather not take this step unless there's no other way.
-Audun
On 06/26/2014 07:50 AM, Audun Røe wrote:
Hello,
I'm trying to delete some problematic entries from our 389 directory. The entry DNs contain < and > (probably found their way into the directory years ago). This causes problems with JNDI where DNs from search results are fed directly back into more searches because these particular DNs are somehow returned in in escaped form. E.g. ou=my<problematic>entry,dc=example,dc=com becomes ou=my<problematic>entry,dc=example,dc=com, causing error 32. I'm not sure if it's the directory server or JNDI adding the escaping, as ldapsearch from the command line doesn't seem to behave this way, but it doesn't really matter: I want to remove the entries and get rid of the issue. Unfortunately, I'm unable to:
$ ldapdelete -D "cn=directory manager" -WxH "ldap://example.com:389 http://example.com:389" "ou=my<problematic>entry,dc=example,dc=com" Enter LDAP Password: ldap_delete: Invalid DN syntax (34) additional info: DN value invalid per syntax
I've also tried deleting through Apache Directory Studio, error 34 there as well.
So, any ideas on how to get rid of them? The only thing I can think of is to db2ldif the entire directory, manually excise the entries from the LDIF file and then re-import. But I'd rather not take this step unless there's no other way.
You could try disabling syntax checking - nsslapd-syntaxcheck
-Audun
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 06/26/2014 07:59 AM, Rich Megginson wrote:
On 06/26/2014 07:50 AM, Audun Røe wrote:
Hello,
I'm trying to delete some problematic entries from our 389 directory. The entry DNs contain < and > (probably found their way into the directory years ago). This causes problems with JNDI where DNs from search results are fed directly back into more searches because these particular DNs are somehow returned in in escaped form. E.g. ou=my<problematic>entry,dc=example,dc=com becomes ou=my<problematic>entry,dc=example,dc=com, causing error 32. I'm not sure if it's the directory server or JNDI adding the escaping, as ldapsearch from the command line doesn't seem to behave this way, but it doesn't really matter: I want to remove the entries and get rid of the issue. Unfortunately, I'm unable to:
$ ldapdelete -D "cn=directory manager" -WxH "ldap://example.com:389 http://example.com:389" "ou=my<problematic>entry,dc=example,dc=com" Enter LDAP Password: ldap_delete: Invalid DN syntax (34) additional info: DN value invalid per syntax
I've also tried deleting through Apache Directory Studio, error 34 there as well.
So, any ideas on how to get rid of them? The only thing I can think of is to db2ldif the entire directory, manually excise the entries from the LDIF file and then re-import. But I'd rather not take this step unless there's no other way.
You could try disabling syntax checking - nsslapd-syntaxcheck
Sorry - disable DN syntax checking - I believe that may be different than regular syntax checking
-Audun
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Rich, thanks for the suggestions.
I tested setting both nsslapd-dn-validate-strict and nsslapd-syntaxcheck to off, but no luck. Finally had a go at disabling "cn=Distinguished Name Syntax,cn=plugins,cn=config" entirely (nsslapd-pluginEnabled: off) but the server wouldn't start at all with this gone. Can't see any other attributes in dse.ldif that seem to apply.
-Audun
On Thu, Jun 26, 2014 at 4:01 PM, Rich Megginson rmeggins@redhat.com wrote:
On 06/26/2014 07:59 AM, Rich Megginson wrote:
On 06/26/2014 07:50 AM, Audun Røe wrote:
Hello,
I'm trying to delete some problematic entries from our 389 directory. The entry DNs contain < and > (probably found their way into the directory years ago). This causes problems with JNDI where DNs from search results are fed directly back into more searches because these particular DNs are somehow returned in in escaped form. E.g. ou=my<problematic>entry,dc=example,dc=com becomes ou=my<problematic>entry,dc=example,dc=com, causing error 32. I'm not sure if it's the directory server or JNDI adding the escaping, as ldapsearch from the command line doesn't seem to behave this way, but it doesn't really matter: I want to remove the entries and get rid of the issue. Unfortunately, I'm unable to:
$ ldapdelete -D "cn=directory manager" -WxH "ldap://example.com:389" "ou=my<problematic>entry,dc=example,dc=com" Enter LDAP Password: ldap_delete: Invalid DN syntax (34) additional info: DN value invalid per syntax
I've also tried deleting through Apache Directory Studio, error 34 there as well.
So, any ideas on how to get rid of them? The only thing I can think of is to db2ldif the entire directory, manually excise the entries from the LDIF file and then re-import. But I'd rather not take this step unless there's no other way.
You could try disabling syntax checking - nsslapd-syntaxcheck
Sorry - disable DN syntax checking - I believe that may be different than regular syntax checking
-Audun
-- 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 06/26/2014 08:21 AM, Audun Røe wrote:
Rich, thanks for the suggestions.
I tested setting both nsslapd-dn-validate-strict and nsslapd-syntaxcheck to off, but no luck. Finally had a go at disabling "cn=Distinguished Name Syntax,cn=plugins,cn=config" entirely (nsslapd-pluginEnabled: off) but the server wouldn't start at all with this gone. Can't see any other attributes in dse.ldif that seem to apply.
What is your version of 389-ds-base? rpm -q 389-ds-base
-Audun
On Thu, Jun 26, 2014 at 4:01 PM, Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
On 06/26/2014 07:59 AM, Rich Megginson wrote:
On 06/26/2014 07:50 AM, Audun Røe wrote:
Hello, I'm trying to delete some problematic entries from our 389 directory. The entry DNs contain < and > (probably found their way into the directory years ago). This causes problems with JNDI where DNs from search results are fed directly back into more searches because these particular DNs are somehow returned in in escaped form. E.g. ou=my<problematic>entry,dc=example,dc=com becomes ou=my\<problematic\>entry,dc=example,dc=com, causing error 32. I'm not sure if it's the directory server or JNDI adding the escaping, as ldapsearch from the command line doesn't seem to behave this way, but it doesn't really matter: I want to remove the entries and get rid of the issue. Unfortunately, I'm unable to: $ ldapdelete -D "cn=directory manager" -WxH "ldap://example.com:389 <http://example.com:389>" "ou=my<problematic>entry,dc=example,dc=com" Enter LDAP Password: ldap_delete: Invalid DN syntax (34) additional info: DN value invalid per syntax I've also tried deleting through Apache Directory Studio, error 34 there as well. So, any ideas on how to get rid of them? The only thing I can think of is to db2ldif the entire directory, manually excise the entries from the LDIF file and then re-import. But I'd rather not take this step unless there's no other way.
You could try disabling syntax checking - nsslapd-syntaxcheck
Sorry - disable DN syntax checking - I believe that may be different than regular syntax checking
-Audun -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
$ rpm -q 389-ds-base 389-ds-base-1.2.11.15-32.el6_5.x86_64
-Audun
On Thu, Jun 26, 2014 at 4:26 PM, Rich Megginson rmeggins@redhat.com wrote:
On 06/26/2014 08:21 AM, Audun Røe wrote:
Rich, thanks for the suggestions.
I tested setting both nsslapd-dn-validate-strict and nsslapd-syntaxcheck to off, but no luck. Finally had a go at disabling "cn=Distinguished Name Syntax,cn=plugins,cn=config" entirely (nsslapd-pluginEnabled: off) but the server wouldn't start at all with this gone. Can't see any other attributes in dse.ldif that seem to apply.
What is your version of 389-ds-base? rpm -q 389-ds-base
Hi, This works for me: more inv.txt
dn: ou=ny<group>mmm,dc=redhat,dc=com changetype: add objectclass: organizationalunit
ldapmodify -x -h localhost -p 1390 -D "cn=directory manager" -w secret12 -f inv.txt adding new entry "ou=ny<group>mmm,dc=redhat,dc=com"
[ludwig@elkris ~]$ ldapdelete -x -h localhost -p 1390 -D "cn=directory manager" -w secret12 ou=ny<group>mmm,dc=redhat,dc=com
[26/Jun/2014:16:53:26 +0200] conn=9 op=1 ADD dn="ou=ny\3Cgroup\3Emmm,dc=redhat,dc=com" [26/Jun/2014:16:53:27 +0200] conn=9 op=1 RESULT err=0 tag=105 nentries=0 etime=1 [ [26/Jun/2014:16:54:23 +0200] conn=10 op=1 DEL dn="ou=ny\3Cgroup\3Emmm,dc=redhat,dc=com" [26/Jun/2014:16:54:26 +0200] conn=10 op=1 RESULT err=0 tag=107 nentries=0 etime=3
On 06/26/2014 04:21 PM, Audun Røe wrote:
Rich, thanks for the suggestions.
I tested setting both nsslapd-dn-validate-strict and nsslapd-syntaxcheck to off, but no luck. Finally had a go at disabling "cn=Distinguished Name Syntax,cn=plugins,cn=config" entirely (nsslapd-pluginEnabled: off) but the server wouldn't start at all with this gone. Can't see any other attributes in dse.ldif that seem to apply.
-Audun
On Thu, Jun 26, 2014 at 4:01 PM, Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
On 06/26/2014 07:59 AM, Rich Megginson wrote:
On 06/26/2014 07:50 AM, Audun Røe wrote:
Hello, I'm trying to delete some problematic entries from our 389 directory. The entry DNs contain < and > (probably found their way into the directory years ago). This causes problems with JNDI where DNs from search results are fed directly back into more searches because these particular DNs are somehow returned in in escaped form. E.g. ou=my<problematic>entry,dc=example,dc=com becomes ou=my\<problematic\>entry,dc=example,dc=com, causing error 32. I'm not sure if it's the directory server or JNDI adding the escaping, as ldapsearch from the command line doesn't seem to behave this way, but it doesn't really matter: I want to remove the entries and get rid of the issue. Unfortunately, I'm unable to: $ ldapdelete -D "cn=directory manager" -WxH "ldap://example.com:389 <http://example.com:389>" "ou=my<problematic>entry,dc=example,dc=com" Enter LDAP Password: ldap_delete: Invalid DN syntax (34) additional info: DN value invalid per syntax I've also tried deleting through Apache Directory Studio, error 34 there as well. So, any ideas on how to get rid of them? The only thing I can think of is to db2ldif the entire directory, manually excise the entries from the LDIF file and then re-import. But I'd rather not take this step unless there's no other way.
You could try disabling syntax checking - nsslapd-syntaxcheck
Sorry - disable DN syntax checking - I believe that may be different than regular syntax checking
-Audun -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
This works for me as well. However, when added with (what I assume to be) proper escaping in the first place like in this case, the entries also appear with visible escaping when browsing the directory. The problematic entries don't.
I also can't add more entries of the latter type, as the server responds with 34 - syntax error, just like when attempting to delete the ones that are already there. In any case, I guess I'll just go for the big hammer, re-import and be done with it :)
-Audun
On Thu, Jun 26, 2014 at 4:58 PM, Ludwig Krispenz lkrispen@redhat.com wrote:
Hi, This works for me: more inv.txt
dn: ou=ny<group>mmm,dc=redhat,dc=com changetype: add objectclass: organizationalunit
ldapmodify -x -h localhost -p 1390 -D "cn=directory manager" -w secret12 -f inv.txt adding new entry "ou=ny<group>mmm,dc=redhat,dc=com"
[ludwig@elkris ~]$ ldapdelete -x -h localhost -p 1390 -D "cn=directory manager" -w secret12 ou=ny<group>mmm,dc=redhat,dc=com
[26/Jun/2014:16:53:26 +0200] conn=9 op=1 ADD dn="ou=ny\3Cgroup\3Emmm,dc=redhat,dc=com" [26/Jun/2014:16:53:27 +0200] conn=9 op=1 RESULT err=0 tag=105 nentries=0 etime=1 [ [26/Jun/2014:16:54:23 +0200] conn=10 op=1 DEL dn="ou=ny\3Cgroup\3Emmm,dc=redhat,dc=com" [26/Jun/2014:16:54:26 +0200] conn=10 op=1 RESULT err=0 tag=107 nentries=0 etime=3
On 06/27/2014 10:16 AM, Audun Røe wrote:
This works for me as well. However, when added with (what I assume to be) proper escaping in the first place like in this case, the entries also appear with visible escaping when browsing the directory. The problematic entries don't.
I also can't add more entries of the latter type, as the server responds with 34 - syntax error, just like when attempting to delete the ones that are already there. In any case, I guess I'll just go for the big hammer, re-import and be done with it :)
did you try with quotes: ldapmodify ..... dn: ou="my<problematic>entry",suffix changetype: delete
if that doesn't work, I'm afraid export/import is the last resort
-Audun
On Thu, Jun 26, 2014 at 4:58 PM, Ludwig Krispenz <lkrispen@redhat.com mailto:lkrispen@redhat.com> wrote:
Hi, This works for me: more inv.txt dn: ou=ny\<group\>mmm,dc=redhat,dc=com changetype: add objectclass: organizationalunit ldapmodify -x -h localhost -p 1390 -D "cn=directory manager" -w secret12 -f inv.txt adding new entry "ou=ny\<group\>mmm,dc=redhat,dc=com" [ludwig@elkris ~]$ ldapdelete -x -h localhost -p 1390 -D "cn=directory manager" -w secret12 ou=ny\<group\>mmm,dc=redhat,dc=com [26/Jun/2014:16:53:26 +0200] conn=9 op=1 ADD dn="ou=ny\3Cgroup\3Emmm,dc=redhat,dc=com" [26/Jun/2014:16:53:27 +0200] conn=9 op=1 RESULT err=0 tag=105 nentries=0 etime=1 [ [26/Jun/2014:16:54:23 +0200] conn=10 op=1 DEL dn="ou=ny\3Cgroup\3Emmm,dc=redhat,dc=com" [26/Jun/2014:16:54:26 +0200] conn=10 op=1 RESULT err=0 tag=107 nentries=0 etime=3
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Error 32 when I try with quotes, same as when I add escaping with backslash. So export/import it is.
Thanks for the suggestions, guys!
-Audun
On Fri, Jun 27, 2014 at 11:54 AM, Ludwig Krispenz lkrispen@redhat.com wrote:
On 06/27/2014 10:16 AM, Audun Røe wrote:
This works for me as well. However, when added with (what I assume to be) proper escaping in the first place like in this case, the entries also appear with visible escaping when browsing the directory. The problematic entries don't.
I also can't add more entries of the latter type, as the server responds with 34 - syntax error, just like when attempting to delete the ones that are already there. In any case, I guess I'll just go for the big hammer, re-import and be done with it :)
did you try with quotes: ldapmodify ..... dn: ou="my<problematic>entry",suffix changetype: delete
if that doesn't work, I'm afraid export/import is the last resort
389-users@lists.fedoraproject.org