[Date Prev][Date Next]
Re: Trouble with nisnetgrouptriple syntax / RFC 2307
Changing the definition of nisNetgroupTriple in nis.schema
to the modern-but-unofficial definition solves the problem
for us. We'll just need to remember to always drop our
nis.schema in place with every OpenLDAP upgrade :/
attributetype ( 126.96.36.199.188.8.131.52 NAME 'nisNetgroupTriple'
DESC 'Netgroup triple'
SYNTAX 184.108.40.206.4.1.14220.127.116.11.26 )
FWIW, from the ldap man page for Solaris:
Solaris LDAP clients use the LDAP v3 protocol to access nam-
ing information from LDAP servers. The LDAP server must sup-
port the object classes and attributes defined in RFC2307bis
(draft), which maps the naming service model on to LDAP.
I wonder what, if any, other problems I'll run into with
Solaris clients querying non-Solaris OpenLDAP servers.
Thanks for the help.
Hallvard B Furuseth wrote:
Pierangelo Masarati writes:
Jeff Blaine wrote:
First, thanks for the reply. Second, I apologize for "sanitizing"
my example with fake names in the nisNetgroupTriples because it
dodged the actual problem.
It appears the problem is with underscores in the triples'
Apparently an underscore is not valid in a 'keystring'?
Right. RFC 2307 refers to RFC 2252 (sectin 4.1) which defines it as
allowing letters, digits, "-" and ";".
An underscore __should__ be valid in the username part of
It should have been. There is an "rfc2307bis" document which is
supposed to update RFC 2307 if it ever gets released, and that
simply uses the IA5 String syntax (in practice ASCII string) for
RFC 2307 some other quirks, e.g. it demands the gecos field is ASCII.
For that matter, I'm sure someone out there uses 8-bit usernames
and directory names.