I turned up the logging on the OpenLDAP server and spotted several instances of:
get_ava: illegal value for attributeType nisNetgroupTriple
I've looked over RFC 2307 and the values stored in OpenLDAP seem to be consistent with the defined syntax. Additionally, the server did not object when I inserted the data so I don't know why there is a problem when reading it.
Is there a specific loglevel setting that will tell me more precisely what is going on? I bumped it up enough for it to show me:
slapd[26143]: get_ava: illegal value for attributeType nisNetgroupTriple slapd[26143]: end get_filter 0 slapd[26143]: begin get_filter slapd[26143]: EQUALITY slapd[26143]: get_ava: illegal value for attributeType nisNetgroupTriple slapd[26143]: end get_filter 0 slapd[26143]: begin get_filter slapd[26143]: SUBSTRINGS slapd[26143]: begin get_ssa slapd[26143]: error=18 slapd[26143]: end get_filter 0 slapd[26143]: begin get_filter slapd[26143]: get_filter: unknown filter type=130 slapd[26143]: end get_filter 0 slapd[26143]: begin get_filter slapd[26143]: EQUALITY slapd[26143]: get_ava: illegal value for attributeType nisNetgroupTriple slapd[26143]: end get_filter 0 slapd[26143]: begin get_filter slapd[26143]: EQUALITY slapd[26143]: get_ava: illegal value for attributeType nisNetgroupTriple slapd[26143]: end get_filter 0
"error=18" and "unknown filter type=130" searches haven't led me to a solution.
Thanks for your time, Ryan
Ryan Lovett wrote:
I turned up the logging on the OpenLDAP server and spotted several instances of:
get_ava: illegal value for attributeType nisNetgroupTriple
I've looked over RFC 2307 and the values stored in OpenLDAP seem to be consistent with the defined syntax. Additionally, the server did not object when I inserted the data so I don't know why there is a problem when reading it.
Most likely this error message is reporting the wrong thing. In fact there is no equality matching rule for the nisNetgroupTriple attributetype, so it cannot be used in a search filter.
Is there a specific loglevel setting that will tell me more precisely what is going on? I bumped it up enough for it to show me:
slapd[26143]: get_ava: illegal value for attributeType nisNetgroupTriple slapd[26143]: end get_filter 0 slapd[26143]: begin get_filter slapd[26143]: EQUALITY slapd[26143]: get_ava: illegal value for attributeType nisNetgroupTriple slapd[26143]: end get_filter 0 slapd[26143]: begin get_filter slapd[26143]: SUBSTRINGS slapd[26143]: begin get_ssa slapd[26143]: error=18 slapd[26143]: end get_filter 0 slapd[26143]: begin get_filter slapd[26143]: get_filter: unknown filter type=130 slapd[26143]: end get_filter 0 slapd[26143]: begin get_filter slapd[26143]: EQUALITY slapd[26143]: get_ava: illegal value for attributeType nisNetgroupTriple slapd[26143]: end get_filter 0 slapd[26143]: begin get_filter slapd[26143]: EQUALITY slapd[26143]: get_ava: illegal value for attributeType nisNetgroupTriple slapd[26143]: end get_filter 0
"error=18" and "unknown filter type=130" searches haven't led me to a solution.
Thanks for your time, Ryan
On Sat, Apr 07, 2007 at 12:48:55AM -0700, Howard Chu wrote:
Ryan Lovett wrote:
I turned up the logging on the OpenLDAP server and spotted several instances of:
get_ava: illegal value for attributeType nisNetgroupTriple
I've looked over RFC 2307 and the values stored in OpenLDAP seem to be consistent with the defined syntax. Additionally, the server did not object when I inserted the data so I don't know why there is a problem when reading it.
Most likely this error message is reporting the wrong thing. In fact there is no equality matching rule for the nisNetgroupTriple attributetype, so it cannot be used in a search filter.
Thanks for your feedback. Given your information I searched a bit more and found this post:
http://osdir.com/ml/ldap.padl.nss/2005-02/msg00004.html
where someone changed the attributetype from
attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgroup triple' SYNTAX 1.3.6.1.1.1.0.0 )
to
attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgroup triple' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
This quieted the get_ava message and solved my problem where the client wasn't able to lookup the netgroup data. Apparently this has also helped a few other people with Solaris clients:
http://www.openldap.org/lists/openldap-software/200402/msg00584.html http://sapiens.wustl.edu/~sysmain/info/openldap/schemas/nis.schema http://www.archivesat.com/OpenLDAP_bugs/thread1581049.htm
I'm mentioning these reports in case it helps other people.
Regards, Ryan
openldap-software@openldap.org