12:06 a.m.
Hello
I'm using dnsDomain2 schema with openldap 2.2.27 for dns server (pdns).
When I look into the logfiles i saw that some questions are not answered
by slapd.
When I ask:
ldapsearch -x -LLL "dc=hostname"
i get the follwing answer:
dn: dc=hostnanme,dc=example.local,ou=DNS,ou=Services,dc=example,dc=local
objectClass: top
objectClass: dNSDomain2
objectClass: domainRelatedObject
dc: hostname
aRecord: 192.168.1.1
pTRRecord: hostname.example.local
associatedDomain: hostname.example.local
ok, but
ldapsearch -x -LLL "aRecord=192.168.1.1"
or
ldapsearch -x -LLL "aRecord=192*"
returns nothing and
ldapsearch -x -LLL "aRecord=*"
returns all entries.
The entry 'aRecord' is of type caseIgnoreIA5Match.
What's wrong there? Any ideas?
--
Mit freundlichen Grüßen
Jürgen Magin
**************************************************************
# #
# OCTOGON Software Development GmbH #
# http://www.octo-soft.de #
# #
# Jürgen Magin, Einsteinstr. 11, D 68519 Viernheim #
# #
# Tel : +49 6204/738353 #
# Fax : +49 6204/914875 #
# EMail : gaston(a)octo-soft.de #
# #
**************************************************************
10:13 a.m.
--On Monday, December 11, 2006 9:06 AM +0100 Jürgen Magin
<gaston(a)octo-soft.de> wrote:
Hello
I'm using dnsDomain2 schema with openldap 2.2.27 for dns server (pdns).
When I look into the logfiles i saw that some questions are not answered
by slapd.
When I ask:
ldapsearch -x -LLL "dc=hostname"
i get the follwing answer:
dn:
dc=hostnanme,dc=example.local,ou=DNS,ou=Services,dc=example,dc=local
objectClass: top
objectClass: dNSDomain2
objectClass: domainRelatedObject
dc: hostname
aRecord: 192.168.1.1
pTRRecord: hostname.example.local
associatedDomain: hostname.example.local
ok, but
ldapsearch -x -LLL "aRecord=192.168.1.1"
or
ldapsearch -x -LLL "aRecord=192*"
returns nothing and
ldapsearch -x -LLL "aRecord=*"
returns all entries.
The entry 'aRecord' is of type caseIgnoreIA5Match.
What's wrong there? Any ideas?
Yes. You apparently didn't read the schema definition:
# 9.3.22. DNS ARecord
#
# The A Record attribute type specifies a type A (Address) DNS resource
# record [6] [7].
#
# aRecord ATTRIBUTE
# WITH ATTRIBUTE-SYNTAX
# DNSRecordSyntax
# ::= {pilotAttributeType 26}
#
## incorrect syntax?
attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
As you can see, there is *no* SUBSTR defined, so there is no defined rule
on how to handle substring searches.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
12:11 a.m.
Thanks for your quick answer.
You are right there is no substring match defined.
But i got no answer too, when i search for the whole string.
That is what i don't understand.
Quanah Gibson-Mount schrieb:
--On Monday, December 11, 2006 9:06 AM +0100 Jürgen Magin
<gaston(a)octo-soft.de> wrote:
> dn:
> dc=hostnanme,dc=example.local,ou=DNS,ou=Services,dc=example,dc=local
> objectClass: top
> objectClass: dNSDomain2
> objectClass: domainRelatedObject
> dc: hostname
> aRecord: 192.168.1.1
> pTRRecord: hostname.example.local
> associatedDomain: hostname.example.local
> ok, but
> ldapsearch -x -LLL "aRecord=192.168.1.1"
> returns nothing
This is the whole value "192.168.1.1" in database.
As you can see, there is *no* SUBSTR defined, so there is no defined
rule on how to handle substring searches.
--Quanah
--
Mit freundlichen Grüßen
Jürgen Magin
**************************************************************
# #
# OCTOGON Software Development GmbH #
# http://www.octo-soft.de #
# #
# Jürgen Magin, Einsteinstr. 11, D 68519 Viernheim #
# #
# Tel : +49 6204/738353 #
# Fax : +49 6204/914875 #
# EMail : gaston(a)octo-soft.de #
# #
**************************************************************
2:42 a.m.
On Monday 11 December 2006 10:06, Jürgen Magin wrote:
Hello
I'm using dnsDomain2 schema with openldap 2.2.27 for dns server (pdns).
When I look into the logfiles i saw that some questions are not answered
by slapd.
When I ask:
ldapsearch -x -LLL "dc=hostname"
i get the follwing answer:
dn:
dc=hostnanme,dc=example.local,ou=DNS,ou=Services,dc=example,dc=local
objectClass: top
objectClass: dNSDomain2
objectClass: domainRelatedObject
dc: hostname
aRecord: 192.168.1.1
pTRRecord: hostname.example.local
associatedDomain: hostname.example.local
ok, but
ldapsearch -x -LLL "aRecord=192.168.1.1"
or
ldapsearch -x -LLL "aRecord=192*"
returns nothing and
ldapsearch -x -LLL "aRecord=*"
returns all entries.
The entry 'aRecord' is of type caseIgnoreIA5Match.
What's wrong there? Any ideas?
Have you made any changes to the index configuration (assuming you use a
slapd.conf for configuration)? If so, did you run slapindex (or an
export/import)?
Regards,
Buchan
--
Buchan Milne
ISP Systems Specialist - Monitoring/Authentication Team Leader
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
4:54 a.m.
Buchan Milne schrieb:
On Monday 11 December 2006 10:06, Jürgen Magin wrote:
> Hello
>
> I'm using dnsDomain2 schema with openldap 2.2.27 for dns server (pdns).
> When I look into the logfiles i saw that some questions are not answered
> by slapd.
>
> When I ask:
> ldapsearch -x -LLL "dc=hostname"
> i get the follwing answer:
> dn:
> dc=hostnanme,dc=example.local,ou=DNS,ou=Services,dc=example,dc=local
> objectClass: top
> objectClass: dNSDomain2
> objectClass: domainRelatedObject
> dc: hostname
> aRecord: 192.168.1.1
> pTRRecord: hostname.example.local
> associatedDomain: hostname.example.local
> ok, but
> ldapsearch -x -LLL "aRecord=192.168.1.1"
> or
> ldapsearch -x -LLL "aRecord=192*"
> returns nothing and
> ldapsearch -x -LLL "aRecord=*"
> returns all entries.
>
> The entry 'aRecord' is of type caseIgnoreIA5Match.
> What's wrong there? Any ideas?
>
Have you made any changes to the index configuration (assuming you use a
slapd.conf for configuration)? If so, did you run slapindex (or an
export/import)?
Yes I changed the index configuration and run slapindex. Here is the
index configuration from my slapd.conf:
index objectClass pres,eq
index cn approx,pres,sub,eq
index sn approx,pres,sub,eq
## required to support pdb_getsampwnam()
index uid approx,pres,sub,eq
## required to support pdb_getsambapwrid()
index displayName pres,sub,eq
## uncomment these if you are storing posixAccount and
## posixGroup entries in the directory as well
index uidNumber eq
index gidNumber eq
index memberUid eq
## required to support CourierMailAccount
index mail approx,pres,sub,eq
index mailsource approx,pres,sub,eq
index sambaSID eq
index sambaSIDList eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index sambaGroupType eq
index default sub
index dhcpHWAddress eq
index dhcpClassData eq
index associatedDomain approx,pres,sub,eq
index member pres,eq
index aRecord eq
index ipServicePort eq
index ipServiceProtocol eq
I noticed that pdns runs in timeouts. So i had a look for the slapd logfile
and saw that slapd got the request, but ansered with:
SEARCH RESULT tag=101 err=0 nentries=0 text=
Regards,
Buchan
--
Mit freundlichen Grüßen
Jürgen Magin
**************************************************************
# #
# OCTOGON Software Development GmbH #
# http://www.octo-soft.de #
# #
# Jürgen Magin, Einsteinstr. 11, D 68519 Viernheim #
# #
# Tel : +49 6204/738353 #
# Fax : +49 6204/914875 #
# EMail : gaston(a)octo-soft.de #
# #
**************************************************************
11:30 a.m.
--On Tuesday, December 12, 2006 5:08 PM +0100 Turbo Fredriksson
<turbo(a)bayour.com> wrote:
Quoting "Jürgen Magin" <gaston(a)octo-soft.de>:
> index aRecord eq
Shouldn't that be 'sub' (not 'eq') if you want substring matches?
Did you miss the part where I pointed out that substring searches are not
allowed on that attribute, because the schema definition doesn't allow them?
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
12:26 a.m.
Quanah Gibson-Mount schrieb:
--On Tuesday, December 12, 2006 5:08 PM +0100 Turbo Fredriksson
<turbo(a)bayour.com> wrote:
> Quoting "Jürgen Magin" <gaston(a)octo-soft.de>:
>
>> index aRecord eq
>
> Shouldn't that be 'sub' (not 'eq') if you want substring
matches?
Did you miss the part where I pointed out that substring searches are
not allowed on that attribute, because the schema definition doesn't
allow them?
--Quanah
Sorry guys the substring match is not the point of interest, because the
whole string
doesn't match too.
Have a look to my last mail. :-)
Thanks for your responds.
--
Mit freundlichen Grüßen
Jürgen Magin
**************************************************************
# #
# OCTOGON Software Development GmbH #
# http://www.octo-soft.de #
# #
# Jürgen Magin, Einsteinstr. 11, D 68519 Viernheim #
# #
# Tel : +49 6204/738353 #
# Fax : +49 6204/914875 #
# EMail : gaston(a)octo-soft.de #
# #
**************************************************************
4:20 p.m.
--On Wednesday, December 13, 2006 9:26 AM +0100 Jürgen Magin
<gaston(a)octo-soft.de> wrote:
Sorry guys the substring match is not the point of interest, because
the
whole string
doesn't match too.
Have a look to my last mail. :-)
Thanks for your responds.
All I can say is, works for me.
I set up a test LDAP server, created a randomly generated entry:
# user.1, Accounts, example.com
dn: uid=user.1,ou=Accounts,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: dNSZone
givenName: Aaccf
sn: Amar
cn: Aaccf Amar
initials: AA
uid: user.1
mail: user.1(a)example.com
telephoneNumber: 629-550-1330
homePhone: 599-075-3272
pager: 871-414-0149
mobile: 990-984-9327
employeeNumber: 1
street: 56091 West Street
l: Salisbury
st: GA
postalCode: 12157
postalAddress: Aaccf Amar$56091 West Street$Salisbury, GA 12157
description: This is the description for Aaccf Amar.
aRecord: 192.0.0.1
added an "eq" index for aRecord, created a junk schema to test with, and
then added the entry.
The search works for me:
ldap-uat00:/tmp# ldapsearch -LLL -x -h localhost -b "dc=example,dc=com"
arecord=192.0.0.1
dn: uid=user.1,ou=Accounts,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: dNSZone
givenName: Aaccf
sn: Amar
cn: Aaccf Amar
initials: AA
uid: user.1
mail: user.1(a)example.com
telephoneNumber: 629-550-1330
homePhone: 599-075-3272
pager: 871-414-0149
mobile: 990-984-9327
employeeNumber: 1
street: 56091 West Street
l: Salisbury
st: GA
postalCode: 12157
postalAddress: Aaccf Amar$56091 West Street$Salisbury, GA 12157
description: This is the description for Aaccf Amar.
aRecord: 192.0.0.1
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
4:10 a.m.
Quoting Quanah Gibson-Mount <quanah(a)stanford.edu>:
--On Tuesday, December 12, 2006 5:08 PM +0100 Turbo Fredriksson
<turbo(a)bayour.com> wrote:
> Quoting "Jürgen Magin" <gaston(a)octo-soft.de>:
>
>> index aRecord eq
>
> Shouldn't that be 'sub' (not 'eq') if you want substring
matches?
Did you miss the part where I pointed out that substring searches are
not allowed on that attribute, because the schema definition doesn't
allow them?
... "after changing it to 'caseExactIA5SubstringsMatch'" as implied...
3:38 p.m.
--On Wednesday, December 13, 2006 1:10 PM +0100 Turbo Fredriksson
<turbo(a)bayour.com> wrote:
Quoting Quanah Gibson-Mount <quanah(a)stanford.edu>:
> --On Tuesday, December 12, 2006 5:08 PM +0100 Turbo Fredriksson
> <turbo(a)bayour.com> wrote:
>
>> Quoting "Jürgen Magin" <gaston(a)octo-soft.de>:
>>
>>> index aRecord eq
>>
>> Shouldn't that be 'sub' (not 'eq') if you want substring
matches?
>
> Did you miss the part where I pointed out that substring searches are
> not allowed on that attribute, because the schema definition doesn't
> allow them?
... "after changing it to 'caseExactIA5SubstringsMatch'" as implied...
And I'm sure you know that changing RFC defined attribute definitions is
highly frowned upon.
aRecord is defined in RFC1274 as:
# aRecord ATTRIBUTE
# WITH ATTRIBUTE-SYNTAX
# DNSRecordSyntax
# ::= {pilotAttributeType 26}
and the RFC clearly states that the allowed matching rules for that type
are:
DNSRecordSyntax ATTRIBUTE-SYNTAX
IA5String
MATCHES FOR EQUALITY
As in, no substring matching.
Telling people to willfully violate RFC defined attributes is generally a
bad thing.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
6196
days inactive
6199
days old
openldap-software@openldap.org
11 comments
4 participants
participants (4)
-
Buchan Milne -
Jürgen Magin -
Quanah Gibson-Mount -
Turbo Fredriksson