Hi,
I store my DNS records in openldap (I use powerdns with ldap backend) and I am trying to use a search filter like: (aRecord=10.11.12.*) but it never produces results.
I noticed that aRecord is defined in dnsDomain schema (available in cosine.schema) and inherited in dnsDomain2 schema (which is used by powerdns, available here: http://www.linuxnetworks.de/pdnsldap/dnsdomain2.schema).
I came to the conclusion that the problem may be caused by the fact that aRecord (oid: 0.9.2342.19200300.100.1.26) in cosine.schema has no substring matching rule defined in schema:
attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
I thought of modifying it in order to allow substring matching, like:
attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Questions:
1. Is the above logic correct, i.e. has the cause of the problem been identified correctly? 2. Is there any other way we can search substrings of values in this (or other similar) attribute(s) without modifying the schema(s)? 3. Can an LDAP administrator freely modify an organisation's schema(s) whenever it is deemed appropriate? Are there any risks by doing it? (I understand one should be cautious when upgrading openldap, and take care to "cascade" modifications to the upgraded version.) - AND/OR - Is there any process of "schema evolution" where LDAP server users provide feedback so that standard schema(s) are globally adapted to user request(s)? In the end: What is the easiest recommended way of using customized schema(s) in an organization?
Please advise.
Thanks in advance, Nick
Any suggestions, anyone?
Let me rephrase the questions (hoping to help in replying):
1. In (very) short: Is there any way we can search substrings of values in attributes not having a SUBSTR matching rule defined, without modifying the schema(s)? 2. If I expand the definition of an attribute - by adding a SUBSTR matching rule - in a widely distributed schema in cosine.schema, is there any serious risk which I should consider?
Thanks, Nick
On 8/1/2011 5:12 μμ, Nick Milas wrote:
Hi,
I store my DNS records in openldap (I use powerdns with ldap backend) and I am trying to use a search filter like: (aRecord=10.11.12.*) but it never produces results. ... I came to the conclusion that the problem may be caused by the fact that aRecord (oid: 0.9.2342.19200300.100.1.26) in cosine.schema has no substring matching rule defined in schema:
attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
I thought of modifying it in order to allow substring matching, like:
attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
--On Tuesday, January 11, 2011 9:28 PM +0200 Nick Milas nick@eurobjects.com wrote:
Any suggestions, anyone?
Let me rephrase the questions (hoping to help in replying):
- In (very) short: Is there any way we can search substrings of values in attributes not having a SUBSTR matching rule defined, without modifying the schema(s)?
No.
- If I expand the definition of an attribute - by adding a SUBSTR matching rule - in a widely distributed schema in cosine.schema, is there any serious risk which I should consider?
Yes. The proper thing to do would be to start an updated RFC to get the old definitions updated, or to create your own attribute that has improved matching rules. A lot of the old RFCs were created at a time when their current uses weren't imagined, or a need for doing things differently than what they were designed to do wasn't thought of.
--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
Thanks Quanah,
But, in the meantime, problems went worse!
I found this message/thread: http://www.openldap.org/lists/openldap-software/200612/msg00095.html which indicates that that user couldn't even do exact matches (with aRecord attribute values).
I then tested, and found he was right! I can't do exact matches as well!
In my slapd.conf I have:
index associatedDomain pres,eq,sub index aRecord pres,eq
And here is the result of my queries (exact match):
# ldapsearch2.4 -x -v -D "cn=Manager,dc=noa,dc=gr" -W -s sub -b "ou=dns1,dc=noa,dc=gr" arecord=195.251.202.63 dn ldap_initialize( <DEFAULT> ) Enter LDAP Password: filter: arecord=195.251.202.63 requesting: dn # extended LDIF # # LDAPv3 # base <ou=dns1,dc=noa,dc=gr> with scope subtree # filter: arecord=195.251.202.63 # requesting: dn #
# search result search: 2 result: 0 Success
# numResponses: 1
But, if I search with another attribute (also exact match):
# ldapsearch2.4 -x -v -D "cn=Manager,dc=noa,dc=gr" -W -s sub -b "ou=dns1,dc=noa,dc=gr" associateddomain=nmilas1.astro.noa.gr dn ldap_initialize( <DEFAULT> ) Enter LDAP Password: filter: associateddomain=nmilas1.astro.noa.gr requesting: dn # extended LDIF # # LDAPv3 # base <ou=dns1,dc=noa,dc=gr> with scope subtree # filter: associateddomain=nmilas1.astro.noa.gr # requesting: dn #
# nmilas1.astro, noa.gr, dns1, noa.gr dn: dc=nmilas1.astro,dc=noa.gr,ou=dns1,dc=noa,dc=gr
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
What may be wrong?
In that case, you (Quanah) tested with a "junk schema". Would it make sense to test with the real schemas ?
Here is the whole entry (on which searches were conducted):
dn: dc=nmilas1.astro,dc=noa.gr,ou=dns1,dc=noa,dc=gr objectClass: dNSDomain2 objectClass: domainRelatedObject dc: nmilas1.astro associatedDomain: nmilas1.astro.noa.gr aRecord: 195.251.202.63
domainRelatedObject is in cosine.schema, associatedDomain is in core.schema, aRecord is in cosine.schema. Definitions:
attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain' DESC 'RFC1274: domain associated with object' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Nick
On 11/1/2011 9:38 μμ, Quanah Gibson-Mount wrote:
Yes. The proper thing to do would be to start an updated RFC to get the old definitions updated, or to create your own attribute that has improved matching rules. A lot of the old RFCs were created at a time when their current uses weren't imagined, or a need for doing things differently than what they were designed to do wasn't thought of.
--Quanah
Nick Milas writes:
I then tested, and found he was right! I can't do exact matches as well!
Note that after messing with the schema of existing objects in your database, at best you need to rebuild your indexes with slapindex (while slapd is down), at worst you may have to slapcat the old database (with the old schema), move away the database directory, and slapadd it back to a fresh database.
Thanks Hallvard,
I had already done slapindex2.4. (Tried now again, just in case. Nothing changed.)
Note, however, that I had not changed the schema (and I still haven't) !
As a test, in my test rig (on another machine also running the same version, with the same DIT) I did change the schema for the aRecord attribute (as I had suggested):
attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Then, in my slapd.conf I did:
index aRecord pres,eq,sub
and finally stopped the server, indexed, restarted and it worked (both for partial and exact matches - this example is with an exact match):
# service ldap2.4 stop Stopping slapd: [ OK ] # # cd /var/lib/ldap2.4 # slapindex2.4 # chown -R ldap:ldap /var/lib/ldap2.4 # # # service ldap2.4 start Starting slapd (ldap + ldaps): [ OK ] # # ldapsearch2.4 -x -v -D "cn=Manager,dc=noa,dc=gr" -W -s sub -b "ou=dns1,dc=noa,dc=gr" arecord=195.251.202.63 dn ldap_initialize( <DEFAULT> ) Enter LDAP Password: filter: arecord=195.251.202.63 requesting: dn # extended LDIF # # LDAPv3 # base <ou=dns1,dc=noa,dc=gr> with scope subtree # filter: arecord=195.251.202.63 # requesting: dn #
# nmilas1.astro, noa.gr, dns1, noa.gr dn: dc=nmilas1.astro,dc=noa.gr,ou=dns1,dc=noa,dc=gr
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
But why exact matches don't work with the attribute as it normally is in schema?
Nick
On 14/1/2011 1:44 μμ, Hallvard B Furuseth wrote:
Note that after messing with the schema of existing objects in your database, at best you need to rebuild your indexes with slapindex (while slapd is down), at worst you may have to slapcat the old database (with the old schema), move away the database directory, and slapadd it back to a fresh database.
My tests were with openldap2.4.22.
(I have started to gradually migrate to current versions mainly due to IPv6 support in ACLs.)
On another server, where I still run v2.3.43-12.el5_5.3, the search works (without changing the schema):
# ldapsearch -x -v -D "cn=Manager,dc=noa,dc=gr" -W -s sub -b "ou=dns1,dc=noa,dc=gr" arecord=195.251.202.63 dn ldap_initialize( <DEFAULT> ) Enter LDAP Password: filter: arecord=195.251.202.63 requesting: dn # extended LDIF # # LDAPv3 # base <ou=dns1,dc=noa,dc=gr> with scope subtree # filter: arecord=195.251.202.63 # requesting: dn #
# nmilas1.astro, noa.gr, dns1, noa.gr dn: dc=nmilas1.astro,dc=noa.gr,ou=dns1,dc=noa,dc=gr
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
May that shed some light?
Nick
On 14/1/2011 2:10 μμ, Nick Milas wrote:
But why exact matches don't work with the attribute as it normally is in schema?
I know it gets frustrating, but after a new indexing (slapindex2.4), now it works (exact matches, always with the initial schema) in v2.4.22 servers.
I am kind of totally confused now...
Nick
On 14/1/2011 2:34 μμ, Nick Milas wrote:
My tests were with openldap2.4.22.
(I have started to gradually migrate to current versions mainly due to IPv6 support in ACLs.)
On another server, where I still run v2.3.43-12.el5_5.3, the search works (without changing the schema):
openldap-technical@openldap.org
-
Hallvard B Furuseth -
Nick Milas -
Quanah Gibson-Mount