- openldap-bugs - openldap.org

Re: (ITS#5337) Start Slapd failure!!!
by hyc＠symas.com 24 Jan '08

24 Jan '08

dugangfeng(a)163.com wrote: > Full_Name: dugangfeng > Version: openldap-2.4.7 > OS: linuxAS4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.181.247.78) > > > hi all: > I start slapd by -d -1 command,'slapd -d -1',but print this: Your report says OpenLDAP 2.4.7 but the debug output you provided clearly says OpenLDAP 2.2.13, from August 2004. It appears you're running the wrong version. > @(#) $OpenLDAP: slapd 2.2.13 (Aug 19 2004 21:22:15) $ > root@porky.build.redhat.com:/usr/src/build/440386-i386/BUILD/openldap-2.2.13/openldap-2.2.13/build-servers/servers/slapd > daemon_init:<null> > please help me ,thanks. The ITS is for actual bug reports, not for help requests. Use the OpenLDAP-software mailing list for help using the software. There is no OpenLDAP bug here, this ITS will be closed. If you actually paid attention to the diagnostic output it would be obvious what the problem is. The biggest help we can give you is to tell you to read more carefully. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re:Re: (ITS#5337) Start Slapd failure!!!
by dugangfeng＠163.com 24 Jan '08

24 Jan '08

------=_Part_162959_15053760.1201154655304 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 7bit this is my slapd.conf: /////////////////////////////////////////////////////// # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema #include /usr/local/etc/openldap/schema/corba.schema #include /usr/local/etc/openldap/schema/cosine.schema #include /usr/local/etc/openldap/schema/inetorgperson.schema #include /usr/local/etc/openldap/schema/misc.schema #include /usr/local/etc/openldap/schema/openldap.schema #include /usr/local/etc/openldap/schema/nis.schema #include /usr/local/etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=gfdu,dc=com" rootdn "cn=Manager,dc=gfdu,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq /////////////////////////////////////////////////////////////////// this is my core.schema: # OpenLDAP Core schema # $OpenLDAP: pkg/ldap/servers/slapd/schema/core.schema,v 1.88.2.5 2007/12/13 07:31:15 hyc Exp $ ## This work is part of OpenLDAP Software <http://www.openldap.org/>. ## ## Copyright 1998-2007 The OpenLDAP Foundation. ## All rights reserved. ## ## Redistribution and use in source and binary forms, with or without ## modification, are permitted only as authorized by the OpenLDAP ## Public License. ## ## A copy of this license is available in the file LICENSE in the ## top-level directory of the distribution or, alternatively, at ## <http://www.OpenLDAP.org/license.html>. # ## Portions Copyright (C) The Internet Society (1997-2006). ## All Rights Reserved. ## ## This document and translations of it may be copied and furnished to ## others, and derivative works that comment on or otherwise explain it ## or assist in its implementation may be prepared, copied, published ## and distributed, in whole or in part, without restriction of any ## kind, provided that the above copyright notice and this paragraph are ## included on all such copies and derivative works. However, this ## document itself may not be modified in any way, such as by removing ## the copyright notice or references to the Internet Society or other ## Internet organizations, except as needed for the purpose of ## developing Internet standards in which case the procedures for ## copyrights defined in the Internet Standards process must be ## followed, or as required to translate it into languages other than ## English. ## ## The limited permissions granted above are perpetual and will not be ## revoked by the Internet Society or its successors or assigns. ## ## This document and the information contained herein is provided on an ## "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING ## TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ## BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ## HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF ## MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. # # # Includes LDAPv3 schema items from: # RFC 2252/2256 (LDAPv3) # # Select standard track schema items: # RFC 1274 (uid/dc) # RFC 2079 (URI) # RFC 2247 (dc/dcObject) # RFC 2587 (PKI) # RFC 2589 (Dynamic Directory Services) # RFC 4524 (associatedDomain) # # Select informational schema items: # RFC 2377 (uidObject) # # Standard attribute types from RFC 2256 # # system schema #attributetype ( 2.5.4.0 NAME 'objectClass' # DESC 'RFC2256: object classes of the entity' # EQUALITY objectIdentifierMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) # system schema #attributetype ( 2.5.4.1 NAME ( 'aliasedObjectName' 'aliasedEntryName' ) # DESC 'RFC2256: name of aliased object' # EQUALITY distinguishedNameMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) attributetype ( 2.5.4.2 NAME 'knowledgeInformation' DESC 'RFC2256: knowledge information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) # system schema #attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) # DESC 'RFC2256: common name(s) for which the entity is known by' # SUP name ) attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name ) attributetype ( 2.5.4.5 NAME 'serialNumber' DESC 'RFC2256: serial number of the entity' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} ) # RFC 4519 definition ('countryName' in X.500 and RFC2256) attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC2256: two-letter ISO-3166 country code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE ) #attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) # DESC 'RFC2256: ISO-3166 country 2-letter code' # SUP name SINGLE-VALUE ) attributetype ( 2.5.4.7 NAME ( 'l' 'localityName' ) DESC 'RFC2256: locality which this object resides in' SUP name ) attributetype ( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' ) DESC 'RFC2256: state or province which this object resides in' SUP name ) attributetype ( 2.5.4.9 NAME ( 'street' 'streetAddress' ) DESC 'RFC2256: street address of this object' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' ) DESC 'RFC2256: organization this object belongs to' SUP name ) attributetype ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC 'RFC2256: organizational unit this object belongs to' SUP name ) attributetype ( 2.5.4.12 NAME 'title' DESC 'RFC2256: title associated with the entity' SUP name ) # system schema #attributetype ( 2.5.4.13 NAME 'description' # DESC 'RFC2256: descriptive information' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) # Deprecated by enhancedSearchGuide attributetype ( 2.5.4.14 NAME 'searchGuide' DESC 'RFC2256: search guide, deprecated by enhancedSearchGuide' SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) attributetype ( 2.5.4.15 NAME 'businessCategory' DESC 'RFC2256: business category' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) attributetype ( 2.5.4.16 NAME 'postalAddress' DESC 'RFC2256: postal address' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) attributetype ( 2.5.4.17 NAME 'postalCode' DESC 'RFC2256: postal code' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} ) attributetype ( 2.5.4.18 NAME 'postOfficeBox' DESC 'RFC2256: Post Office Box' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} ) attributetype ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' DESC 'RFC2256: Physical Delivery Office Name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) attributetype ( 2.5.4.20 NAME 'telephoneNumber' DESC 'RFC2256: Telephone Number' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} ) attributetype ( 2.5.4.21 NAME 'telexNumber' DESC 'RFC2256: Telex Number' SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) attributetype ( 2.5.4.22 NAME 'teletexTerminalIdentifier' DESC 'RFC2256: Teletex Terminal Identifier' SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' ) DESC 'RFC2256: Facsimile (Fax) Telephone Number' SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) attributetype ( 2.5.4.24 NAME 'x121Address' DESC 'RFC2256: X.121 Address' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} ) attributetype ( 2.5.4.25 NAME 'internationaliSDNNumber' DESC 'RFC2256: international ISDN number' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} ) attributetype ( 2.5.4.26 NAME 'registeredAddress' DESC 'RFC2256: registered postal address' SUP postalAddress SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) attributetype ( 2.5.4.27 NAME 'destinationIndicator' DESC 'RFC2256: destination indicator' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} ) attributetype ( 2.5.4.28 NAME 'preferredDeliveryMethod' DESC 'RFC2256: preferred delivery method' SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 SINGLE-VALUE ) attributetype ( 2.5.4.29 NAME 'presentationAddress' DESC 'RFC2256: presentation address' EQUALITY presentationAddressMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 SINGLE-VALUE ) attributetype ( 2.5.4.30 NAME 'supportedApplicationContext' DESC 'RFC2256: supported application context' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) attributetype ( 2.5.4.31 NAME 'member' DESC 'RFC2256: member of a group' SUP distinguishedName ) attributetype ( 2.5.4.32 NAME 'owner' DESC 'RFC2256: owner (of the object)' SUP distinguishedName ) attributetype ( 2.5.4.33 NAME 'roleOccupant' DESC 'RFC2256: occupant of role' SUP distinguishedName ) # system schema #attributetype ( 2.5.4.34 NAME 'seeAlso' # DESC 'RFC2256: DN of related object' # SUP distinguishedName ) # system schema #attributetype ( 2.5.4.35 NAME 'userPassword' # DESC 'RFC2256/2307: password of user' # EQUALITY octetStringMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} ) # Must be transferred using ;binary # with certificateExactMatch rule (per X.509) attributetype ( 2.5.4.36 NAME 'userCertificate' DESC 'RFC2256: X.509 user certificate, use ;binary' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) # Must be transferred using ;binary # with certificateExactMatch rule (per X.509) attributetype ( 2.5.4.37 NAME 'cACertificate' DESC 'RFC2256: X.509 CA certificate, use ;binary' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) # Must be transferred using ;binary attributetype ( 2.5.4.38 NAME 'authorityRevocationList' DESC 'RFC2256: X.509 authority revocation list, use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) # Must be transferred using ;binary attributetype ( 2.5.4.39 NAME 'certificateRevocationList' DESC 'RFC2256: X.509 certificate revocation list, use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) # Must be stored and requested in the binary form attributetype ( 2.5.4.40 NAME 'crossCertificatePair' DESC 'RFC2256: X.509 cross certificate pair, use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 ) # system schema #attributetype ( 2.5.4.41 NAME 'name' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributetype ( 2.5.4.42 NAME ( 'givenName' 'gn' ) DESC 'RFC2256: first name(s) for which the entity is known by' SUP name ) attributetype ( 2.5.4.43 NAME 'initials' DESC 'RFC2256: initials of some or all of names, but not the surname(s).' SUP name ) attributetype ( 2.5.4.44 NAME 'generationQualifier' DESC 'RFC2256: name qualifier indicating a generation' SUP name ) attributetype ( 2.5.4.45 NAME 'x500UniqueIdentifier' DESC 'RFC2256: X.500 unique identifier' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) attributetype ( 2.5.4.46 NAME 'dnQualifier' DESC 'RFC2256: DN qualifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) attributetype ( 2.5.4.47 NAME 'enhancedSearchGuide' DESC 'RFC2256: enhanced search guide' SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 ) attributetype ( 2.5.4.48 NAME 'protocolInformation' DESC 'RFC2256: protocol information' EQUALITY protocolInformationMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) # system schema #attributetype ( 2.5.4.49 NAME 'distinguishedName' # EQUALITY distinguishedNameMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) attributetype ( 2.5.4.50 NAME 'uniqueMember' DESC 'RFC2256: unique member of a group' EQUALITY uniqueMemberMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) attributetype ( 2.5.4.51 NAME 'houseIdentifier' DESC 'RFC2256: house identifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) # Must be transferred using ;binary attributetype ( 2.5.4.52 NAME 'supportedAlgorithms' DESC 'RFC2256: supported algorithms' SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 ) # Must be transferred using ;binary attributetype ( 2.5.4.53 NAME 'deltaRevocationList' DESC 'RFC2256: delta revocation list; use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) attributetype ( 2.5.4.54 NAME 'dmdName' DESC 'RFC2256: name of DMD' SUP name ) attributetype ( 2.5.4.65 NAME 'pseudonym' DESC 'X.520(4th): pseudonym for the object' SUP name ) # Standard object classes from RFC2256 # system schema #objectclass ( 2.5.6.0 NAME 'top' # DESC 'RFC2256: top of the superclass chain' # ABSTRACT # MUST objectClass ) # system schema #objectclass ( 2.5.6.1 NAME 'alias' # DESC 'RFC2256: an alias' # SUP top STRUCTURAL # MUST aliasedObjectName ) objectclass ( 2.5.6.2 NAME 'country' DESC 'RFC2256: a country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) ) objectclass ( 2.5.6.3 NAME 'locality' DESC 'RFC2256: a locality' SUP top STRUCTURAL MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) ) objectclass ( 2.5.6.4 NAME 'organization' DESC 'RFC2256: an organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) objectclass ( 2.5.6.5 NAME 'organizationalUnit' DESC 'RFC2256: an organizational unit' SUP top STRUCTURAL MUST ou MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) objectclass ( 2.5.6.7 NAME 'organizationalPerson' DESC 'RFC2256: an organizational person' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) ) objectclass ( 2.5.6.8 NAME 'organizationalRole' DESC 'RFC2256: an organizational role' SUP top STRUCTURAL MUST cn MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) objectclass ( 2.5.6.9 NAME 'groupOfNames' DESC 'RFC2256: a group of names (DNs)' SUP top STRUCTURAL MUST ( member $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) objectclass ( 2.5.6.10 NAME 'residentialPerson' DESC 'RFC2256: an residential person' SUP person STRUCTURAL MUST l MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l ) ) objectclass ( 2.5.6.11 NAME 'applicationProcess' DESC 'RFC2256: an application process' SUP top STRUCTURAL MUST cn MAY ( seeAlso $ ou $ l $ description ) ) objectclass ( 2.5.6.12 NAME 'applicationEntity' DESC 'RFC2256: an application entity' SUP top STRUCTURAL MUST ( presentationAddress $ cn ) MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $ description ) ) objectclass ( 2.5.6.13 NAME 'dSA' DESC 'RFC2256: a directory system agent (a server)' SUP applicationEntity STRUCTURAL MAY knowledgeInformation ) objectclass ( 2.5.6.14 NAME 'device' DESC 'RFC2256: a device' SUP top STRUCTURAL MUST cn MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) ) objectclass ( 2.5.6.15 NAME 'strongAuthenticationUser' DESC 'RFC2256: a strong authentication user' SUP top AUXILIARY MUST userCertificate ) objectclass ( 2.5.6.16 NAME 'certificationAuthority' DESC 'RFC2256: a certificate authority' SUP top AUXILIARY MUST ( authorityRevocationList $ certificateRevocationList $ cACertificate ) MAY crossCertificatePair ) objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames' DESC 'RFC2256: a group of unique names (DN and Unique Identifier)' SUP top STRUCTURAL MUST ( uniqueMember $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) objectclass ( 2.5.6.18 NAME 'userSecurityInformation' DESC 'RFC2256: a user security information' SUP top AUXILIARY MAY ( supportedAlgorithms ) ) objectclass ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP certificationAuthority AUXILIARY MAY ( deltaRevocationList ) ) objectclass ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL MUST ( cn ) MAY ( certificateRevocationList $ authorityRevocationList $ deltaRevocationList ) ) objectclass ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST ( dmdName ) MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) # # Object Classes from RFC 2587 # objectclass ( 2.5.6.21 NAME 'pkiUser' DESC 'RFC2587: a PKI user' SUP top AUXILIARY MAY userCertificate ) objectclass ( 2.5.6.22 NAME 'pkiCA' DESC 'RFC2587: PKI certificate authority' SUP top AUXILIARY MAY ( authorityRevocationList $ certificateRevocationList $ cACertificate $ crossCertificatePair ) ) objectclass ( 2.5.6.23 NAME 'deltaCRL' DESC 'RFC2587: PKI user' SUP top AUXILIARY MAY deltaRevocationList ) # # Standard Track URI label schema from RFC 2079 # system schema #attributetype ( 1.3.6.1.4.1.250.1.57 NAME 'labeledURI' # DESC 'RFC2079: Uniform Resource Identifier with optional label' # EQUALITY caseExactMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclass ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' DESC 'RFC2079: object that contains the URI attribute type' SUP top AUXILIARY MAY ( labeledURI ) ) # # Derived from RFC 1274, but with new "short names" # #attributetype ( 0.9.2342.19200300.100.1.1 # NAME ( 'uid' 'userid' ) # DESC 'RFC1274: user identifier' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) objectclass ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' DESC 'RFC1274: simple security object' SUP top AUXILIARY MUST userPassword ) # RFC 1274 + RFC 2247 attributetype ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainComponent' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) # RFC 2247 objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' DESC 'RFC2247: domain component object' SUP top AUXILIARY MUST dc ) # RFC 2377 objectclass ( 1.3.6.1.1.3.1 NAME 'uidObject' DESC 'RFC2377: uid object' SUP top AUXILIARY MUST uid ) # RFC 4524 # The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181] # host names [RFC1123] that are associated with an object. That is, # values of this attribute should conform to the following ABNF: # # domain = root / label *( DOT label ) # root = SPACE # label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ] # LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z" # SPACE = %x20 ; space (" ") # HYPHEN = %x2D ; hyphen ("-") # DOT = %x2E ; period (".") 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 ) # RFC 2459 -- deprecated in favor of 'mail' (in cosine.schema) attributetype ( 1.2.840.113549.1.9.1 NAME ( 'email' 'emailAddress' 'pkcs9email' ) DESC 'RFC3280: legacy attribute for email addresses in DNs' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} ) ------=_Part_162959_15053760.1201154655304 Content-Type: text/html; charset=gbk Content-Transfer-Encoding: quoted-printable <DIV>this is my slapd.conf:</DIV> <DIV>///////////////////////////////////////////////////////</DIV> <DIV>#<BR># See slapd.conf(5) for details on configuration options.<BR># Th= is file should NOT be world readable.<BR>#<BR>include  /usr/local= /etc/openldap/schema/core.schema<BR>#include     &= nbsp;   /usr/local/etc/openldap/schema/corba.schema<BR>#include&n= bsp;        /usr/local/etc/openldap/sche= ma/cosine.schema<BR>#include       &nbsp= ; /usr/local/etc/openldap/schema/inetorgperson.schema<BR>#include &nbs= p;       /usr/local/etc/openldap/schema/misc.= schema<BR>#include         /usr/loc= al/etc/openldap/schema/openldap.schema<BR>#include    &= nbsp;    /usr/local/etc/openldap/schema/nis.schema<BR>#inclu= de         /usr/local/etc/openldap/= schema/samba.schema</DIV> <DIV> </DIV> <DIV># Define global ACLs to disable default read access.</DIV> <DIV># Do not enable referrals until AFTER you have a working directory<BR>= # service AND an understanding of referrals.<BR>#referral <A href=3D"l= dap://root.openldap.org">ldap://root.openldap.org</A></DIV> <DIV>pidfile  /usr/local/var/run/slapd.pid<BR>argsfile /usr/= local/var/run/slapd.args</DIV> <DIV># Load dynamic backend modules:<BR># modulepath /usr/local/libexe= c/openldap<BR># moduleload back_bdb.la<BR># moduleload back_hdb.l= a<BR># moduleload back_ldap.la</DIV> <DIV># Sample security restrictions<BR># Require integrity protection = (prevent hijacking)<BR># Require 112-bit (3DES or better) encryption f= or updates<BR># Require 63-bit encryption for simple bind<BR># securit= y ssf=3D1 update_ssf=3D112 simple_bind=3D64</DIV> <DIV># Sample access control policy:<BR># Root DSE: allow anyone to re= ad it<BR># Subschema (sub)entry DSE: allow anyone to read it<BR>#&nbsp= ;Other DSEs:<BR>#  Allow self write access<BR>#  Allow = authenticated users read access<BR>#  Allow anonymous users to au= thenticate<BR># Directives needed to implement policy:<BR># access to = dn.base=3D"" by * read<BR># access to dn.base=3D"cn=3DSubschema" by * read<= BR># access to *<BR># by self write<BR># by users read<BR># = by anonymous auth<BR>#<BR># if no access controls are present, the default = policy<BR># allows anyone and everyone to read anything but restricts<BR># = updates to rootdn.  (e.g., "access to * by * read")<BR>#<BR># rootdn c= an always read and write EVERYTHING!</DIV> <DIV>######################################################################= #<BR># BDB database definitions<BR>########################################= ###############################</DIV> <DIV>database bdb<BR>suffix  "dc=3Dgfdu,dc=3Dcom"<BR>rootdn&= nbsp; "cn=3DManager,dc=3Dgfdu,dc=3Dcom"<BR># Cleartext passwords, espe= cially for the rootdn, should<BR># be avoid.  See slappasswd(8) and sl= apd.conf(5) for details.<BR># Use of strong authentication encouraged.<BR>r= ootpw  secret<BR># The database directory MUST exist prior to run= ning slapd AND <BR># should only be accessible by the slapd and slap tools.= <BR># Mode 700 recommended.<BR>directory /usr/local/var/openldap-data<= BR># Indices to maintain<BR>index objectClass eq<BR></DIV> <DIV>///////////////////////////////////////////////////////////////////</D= IV> <DIV> </DIV> <DIV>this is my core.schema:</DIV> <DIV> </DIV> <DIV># OpenLDAP Core schema<BR># $OpenLDAP: pkg/ldap/servers/slapd/schema/c= ore.schema,v 1.88.2.5 2007/12/13 07:31:15 hyc Exp $<BR>## This work is part= of OpenLDAP Software <<A href=3D"http://www.openldap.org/">http://www.o= penldap.org/</A>>.<BR>##<BR>## Copyright 1998-2007 The OpenLDAP Foundati= on.<BR>## All rights reserved.<BR>##<BR>## Redistribution and use in source= and binary forms, with or without<BR>## modification, are permitted only a= s authorized by the OpenLDAP<BR>## Public License.<BR>##<BR>## A copy of th= is license is available in the file LICENSE in the<BR>## top-level director= y of the distribution or, alternatively, at<BR>## <<A href=3D"http://www= .OpenLDAP.org/license.html">http://www.OpenLDAP.org/license.html</A>>.<B= R>#<BR>## Portions Copyright (C) The Internet Society (1997-2006).<BR>## Al= l Rights Reserved.<BR>##<BR>## This document and translations of it may be = copied and furnished to<BR>## others, and derivative works that comment on = or otherwise explain it<BR>## or assist in its implementation may be prepar= ed, copied, published<BR>## and distributed, in whole or in part, without r= estriction of any<BR>## kind, provided that the above copyright notice and = this paragraph are<BR>## included on all such copies and derivative works.&= nbsp; However, this<BR>## document itself may not be modified in any way, s= uch as by removing<BR>## the copyright notice or references to the Internet= Society or other<BR>## Internet organizations, except as needed for the pu= rpose of<BR>## developing Internet standards in which case the procedures f= or<BR>## copyrights defined in the Internet Standards process must be =         <BR>## followed, or as required = to translate it into languages other than<BR>## English.<BR>##  &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     <BR>## The limited permissions granted above are= perpetual and will not be  <BR>## revoked by the Internet Society or = its successors or assigns.        <BR>##= <BR>## This document and the information contained herein is provided on a= n <BR>## "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERIN= G<BR>## TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING<= BR>## BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION<BR>##= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF<BR>## MER= CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</DIV> <DIV>#<BR>#<BR># Includes LDAPv3 schema items from:<BR># RFC 2252/2256= (LDAPv3)<BR>#<BR># Select standard track schema items:<BR># RFC 1274 = (uid/dc)<BR># RFC 2079 (URI)<BR># RFC 2247 (dc/dcObject)<BR>#&nbs= p;RFC 2587 (PKI)<BR># RFC 2589 (Dynamic Directory Services)<BR># = RFC 4524 (associatedDomain)<BR>#<BR># Select informational schema items:<BR= ># RFC 2377 (uidObject)</DIV> <DIV>#<BR># Standard attribute types from RFC 2256<BR>#</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.0 NAME 'objectClass'<BR>#&nb= sp;DESC 'RFC2256: object classes of the entity'<BR># EQUALITY objectId= entifierMatch<BR># SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.1 NAME ( 'aliasedObjectName'= 'aliasedEntryName' )<BR># DESC 'RFC2256: name of aliased object'<BR>#=  EQUALITY distinguishedNameMatch<BR># SYNTAX 1.3.6.1.4.1.1466.115= .121.1.12 SINGLE-VALUE )</DIV> <DIV>attributetype ( 2.5.4.2 NAME 'knowledgeInformation'<BR> DESC 'RFC= 2256: knowledge information'<BR> EQUALITY caseIgnoreMatch<BR> SYN= TAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' )= <BR># DESC 'RFC2256: common name(s) for which the entity is known by'<= BR># SUP name )</DIV> <DIV>attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )<BR> DESC 'RFC2256= : last (family) name(s) for which the entity is known by'<BR> SUP name= )</DIV> <DIV>attributetype ( 2.5.4.5 NAME 'serialNumber'<BR> DESC 'RFC2256: se= rial number of the entity'<BR> EQUALITY caseIgnoreMatch<BR> SUBST= R caseIgnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{6= 4} )</DIV> <DIV># RFC 4519 definition ('countryName' in X.500 and RFC2256)<BR>attribut= etype ( 2.5.4.6 NAME ( 'c' 'countryName' )<BR> DESC 'RFC2256: two-lett= er ISO-3166 country code'<BR> SUP name<BR> SYNTAX 1.3.6.1.4.1.146= 6.115.121.1.11<BR> SINGLE-VALUE )</DIV> <DIV>#attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )<BR># DESC 'RF= C2256: ISO-3166 country 2-letter code'<BR># SUP name SINGLE-VALUE )</D= IV> <DIV>attributetype ( 2.5.4.7 NAME ( 'l' 'localityName' )<BR> DESC 'RFC= 2256: locality which this object resides in'<BR> SUP name )</DIV> <DIV>attributetype ( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' )<BR> D= ESC 'RFC2256: state or province which this object resides in'<BR> SUP = name )</DIV> <DIV>attributetype ( 2.5.4.9 NAME ( 'street' 'streetAddress' )<BR> DES= C 'RFC2256: street address of this object'<BR> EQUALITY caseIgnoreMatc= h<BR> SUBSTR caseIgnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.146= 6.115.121.1.15{128} )</DIV> <DIV>attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' )<BR> DESC= 'RFC2256: organization this object belongs to'<BR> SUP name )</DIV> <DIV>attributetype ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' )<BR>&nb= sp;DESC 'RFC2256: organizational unit this object belongs to'<BR> SUP = name )</DIV> <DIV>attributetype ( 2.5.4.12 NAME 'title'<BR> DESC 'RFC2256: title as= sociated with the entity'<BR> SUP name )</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.13 NAME 'description'<BR>#&n= bsp;DESC 'RFC2256: descriptive information'<BR># EQUALITY caseIgnoreMa= tch<BR># SUBSTR caseIgnoreSubstringsMatch<BR># SYNTAX 1.3.6.1.4.1= .1466.115.121.1.15{1024} )</DIV> <DIV># Deprecated by enhancedSearchGuide<BR>attributetype ( 2.5.4.14 NAME '= searchGuide'<BR> DESC 'RFC2256: search guide, deprecated by enhancedSe= archGuide'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )</DIV> <DIV>attributetype ( 2.5.4.15 NAME 'businessCategory'<BR> DESC 'RFC225= 6: business category'<BR> EQUALITY caseIgnoreMatch<BR> SUBSTR cas= eIgnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )= </DIV> <DIV>attributetype ( 2.5.4.16 NAME 'postalAddress'<BR> DESC 'RFC2256: = postal address'<BR> EQUALITY caseIgnoreListMatch<BR> SUBSTR caseI= gnoreListSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )</D= IV> <DIV>attributetype ( 2.5.4.17 NAME 'postalCode'<BR> DESC 'RFC2256: pos= tal code'<BR> EQUALITY caseIgnoreMatch<BR> SUBSTR caseIgnoreSubst= ringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )</DIV> <DIV>attributetype ( 2.5.4.18 NAME 'postOfficeBox'<BR> DESC 'RFC2256: = Post Office Box'<BR> EQUALITY caseIgnoreMatch<BR> SUBSTR caseIgno= reSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )</DIV> <DIV>attributetype ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'<BR> DE= SC 'RFC2256: Physical Delivery Office Name'<BR> EQUALITY caseIgnoreMat= ch<BR> SUBSTR caseIgnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.14= 66.115.121.1.15{128} )</DIV> <DIV>attributetype ( 2.5.4.20 NAME 'telephoneNumber'<BR> DESC 'RFC2256= : Telephone Number'<BR> EQUALITY telephoneNumberMatch<BR> SUBSTR = telephoneNumberSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.5= 0{32} )</DIV> <DIV>attributetype ( 2.5.4.21 NAME 'telexNumber'<BR> DESC 'RFC2256: Te= lex Number'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )</DIV> <DIV>attributetype ( 2.5.4.22 NAME 'teletexTerminalIdentifier'<BR> DES= C 'RFC2256: Teletex Terminal Identifier'<BR> SYNTAX 1.3.6.1.4.1.1466.1= 15.121.1.51 )</DIV> <DIV>attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' )<BR>=  DESC 'RFC2256: Facsimile (Fax) Telephone Number'<BR> SYNTAX 1.3.= 6.1.4.1.1466.115.121.1.22 )</DIV> <DIV>attributetype ( 2.5.4.24 NAME 'x121Address'<BR> DESC 'RFC2256: X.= 121 Address'<BR> EQUALITY numericStringMatch<BR> SUBSTR numericSt= ringSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )</DI= V> <DIV>attributetype ( 2.5.4.25 NAME 'internationaliSDNNumber'<BR> DESC = 'RFC2256: international ISDN number'<BR> EQUALITY numericStringMatch<B= R> SUBSTR numericStringSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.146= 6.115.121.1.36{16} )</DIV> <DIV>attributetype ( 2.5.4.26 NAME 'registeredAddress'<BR> DESC 'RFC22= 56: registered postal address'<BR> SUP postalAddress<BR> SYNTAX 1= .3.6.1.4.1.1466.115.121.1.41 )</DIV> <DIV>attributetype ( 2.5.4.27 NAME 'destinationIndicator'<BR> DESC 'RF= C2256: destination indicator'<BR> EQUALITY caseIgnoreMatch<BR> SU= BSTR caseIgnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.4= 4{128} )</DIV> <DIV>attributetype ( 2.5.4.28 NAME 'preferredDeliveryMethod'<BR> DESC = 'RFC2256: preferred delivery method'<BR> SYNTAX 1.3.6.1.4.1.1466.115.1= 21.1.14<BR> SINGLE-VALUE )</DIV> <DIV>attributetype ( 2.5.4.29 NAME 'presentationAddress'<BR> DESC 'RFC= 2256: presentation address'<BR> EQUALITY presentationAddressMatch<BR>&= nbsp;SYNTAX 1.3.6.1.4.1.1466.115.121.1.43<BR> SINGLE-VALUE )</DIV> <DIV>attributetype ( 2.5.4.30 NAME 'supportedApplicationContext'<BR> D= ESC 'RFC2256: supported application context'<BR> EQUALITY objectIdenti= fierMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )</DIV> <DIV>attributetype ( 2.5.4.31 NAME 'member'<BR> DESC 'RFC2256: member = of a group'<BR> SUP distinguishedName )</DIV> <DIV>attributetype ( 2.5.4.32 NAME 'owner'<BR> DESC 'RFC2256: owner (o= f the object)'<BR> SUP distinguishedName )</DIV> <DIV>attributetype ( 2.5.4.33 NAME 'roleOccupant'<BR> DESC 'RFC2256: o= ccupant of role'<BR> SUP distinguishedName )</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.34 NAME 'seeAlso'<BR># = DESC 'RFC2256: DN of related object'<BR># SUP distinguishedName )</DIV= > <DIV># system schema<BR>#attributetype ( 2.5.4.35 NAME 'userPassword'<BR>#&= nbsp;DESC 'RFC2256/2307: password of user'<BR># EQUALITY octetStringMa= tch<BR># SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )</DIV> <DIV># Must be transferred using ;binary<BR># with certificateExactMatch ru= le (per X.509)<BR>attributetype ( 2.5.4.36 NAME 'userCertificate'<BR> = DESC 'RFC2256: X.509 user certificate, use ;binary'<BR> EQUALITY certi= ficateExactMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )</DIV> <DIV># Must be transferred using ;binary<BR># with certificateExactMatch ru= le (per X.509)<BR>attributetype ( 2.5.4.37 NAME 'cACertificate'<BR> DE= SC 'RFC2256: X.509 CA certificate, use ;binary'<BR> EQUALITY certifica= teExactMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )</DIV> <DIV># Must be transferred using ;binary<BR>attributetype ( 2.5.4.38 NAME '= authorityRevocationList'<BR> DESC 'RFC2256: X.509 authority revocation= list, use ;binary'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )</DIV> <DIV># Must be transferred using ;binary<BR>attributetype ( 2.5.4.39 NAME '= certificateRevocationList'<BR> DESC 'RFC2256: X.509 certificate revoca= tion list, use ;binary'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )</DIV= > <DIV># Must be stored and requested in the binary form<BR>attributetype ( 2= .5.4.40 NAME 'crossCertificatePair'<BR> DESC 'RFC2256: X.509 cross cer= tificate pair, use ;binary'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )= </DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.41 NAME 'name'<BR># EQU= ALITY caseIgnoreMatch<BR># SUBSTR caseIgnoreSubstringsMatch<BR># = SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )</DIV> <DIV>attributetype ( 2.5.4.42 NAME ( 'givenName' 'gn' )<BR> DESC 'RFC2= 256: first name(s) for which the entity is known by'<BR> SUP name )</D= IV> <DIV>attributetype ( 2.5.4.43 NAME 'initials'<BR> DESC 'RFC2256: initi= als of some or all of names, but not the surname(s).'<BR> SUP name )</= DIV> <DIV>attributetype ( 2.5.4.44 NAME 'generationQualifier'<BR> DESC 'RFC= 2256: name qualifier indicating a generation'<BR> SUP name )</DIV> <DIV>attributetype ( 2.5.4.45 NAME 'x500UniqueIdentifier'<BR> DESC 'RF= C2256: X.500 unique identifier'<BR> EQUALITY bitStringMatch<BR> S= YNTAX 1.3.6.1.4.1.1466.115.121.1.6 )</DIV> <DIV>attributetype ( 2.5.4.46 NAME 'dnQualifier'<BR> DESC 'RFC2256: DN= qualifier'<BR> EQUALITY caseIgnoreMatch<BR> ORDERING caseIgnoreO= rderingMatch<BR> SUBSTR caseIgnoreSubstringsMatch<BR> SYNTAX 1.3.= 6.1.4.1.1466.115.121.1.44 )</DIV> <DIV>attributetype ( 2.5.4.47 NAME 'enhancedSearchGuide'<BR> DESC 'RFC= 2256: enhanced search guide'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 = )</DIV> <DIV>attributetype ( 2.5.4.48 NAME 'protocolInformation'<BR> DESC 'RFC= 2256: protocol information'<BR> EQUALITY protocolInformationMatch<BR>&= nbsp;SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.49 NAME 'distinguishedName'<= BR># EQUALITY distinguishedNameMatch<BR># SYNTAX 1.3.6.1.4.1.1466= .115.121.1.12 )</DIV> <DIV>attributetype ( 2.5.4.50 NAME 'uniqueMember'<BR> DESC 'RFC2256: u= nique member of a group'<BR> EQUALITY uniqueMemberMatch<BR> SYNTA= X 1.3.6.1.4.1.1466.115.121.1.34 )</DIV> <DIV>attributetype ( 2.5.4.51 NAME 'houseIdentifier'<BR> DESC 'RFC2256= : house identifier'<BR> EQUALITY caseIgnoreMatch<BR> SUBSTR caseI= gnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )= </DIV> <DIV># Must be transferred using ;binary<BR>attributetype ( 2.5.4.52 NAME '= supportedAlgorithms'<BR> DESC 'RFC2256: supported algorithms'<BR>&nbsp= ;SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )</DIV> <DIV># Must be transferred using ;binary<BR>attributetype ( 2.5.4.53 NAME '= deltaRevocationList'<BR> DESC 'RFC2256: delta revocation list; use ;bi= nary'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )</DIV> <DIV>attributetype ( 2.5.4.54 NAME 'dmdName'<BR> DESC 'RFC2256: name o= f DMD'<BR> SUP name )</DIV> <DIV>attributetype ( 2.5.4.65 NAME 'pseudonym'<BR> DESC 'X.520(4th): p= seudonym for the object'<BR> SUP name )</DIV> <DIV># Standard object classes from RFC2256</DIV> <DIV># system schema<BR>#objectclass ( 2.5.6.0 NAME 'top'<BR># DESC 'R= FC2256: top of the superclass chain'<BR># ABSTRACT<BR># MUST obje= ctClass )</DIV> <DIV># system schema<BR>#objectclass ( 2.5.6.1 NAME 'alias'<BR># DESC = 'RFC2256: an alias'<BR># SUP top STRUCTURAL<BR># MUST aliasedObje= ctName )</DIV> <DIV>objectclass ( 2.5.6.2 NAME 'country'<BR> DESC 'RFC2256: a country= '<BR> SUP top STRUCTURAL<BR> MUST c<BR> MAY ( searchGuide $ = description ) )</DIV> <DIV>objectclass ( 2.5.6.3 NAME 'locality'<BR> DESC 'RFC2256: a locali= ty'<BR> SUP top STRUCTURAL<BR> MAY ( street $ seeAlso $ searchGui= de $ st $ l $ description ) )</DIV> <DIV>objectclass ( 2.5.6.4 NAME 'organization'<BR> DESC 'RFC2256: an o= rganization'<BR> SUP top STRUCTURAL<BR> MUST o<BR> MAY ( use= rPassword $ searchGuide $ seeAlso $ businessCategory $<BR>  x121A= ddress $ registeredAddress $ destinationIndicator $<BR>  preferre= dDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $<BR>  = telephoneNumber $ internationaliSDNNumber $ <BR>  facsimileTeleph= oneNumber $ street $ postOfficeBox $ postalCode $<BR>  postalAddr= ess $ physicalDeliveryOfficeName $ st $ l $ description ) )</DIV> <DIV>objectclass ( 2.5.6.5 NAME 'organizationalUnit'<BR> DESC 'RFC2256= : an organizational unit'<BR> SUP top STRUCTURAL<BR> MUST ou<BR>&= nbsp;MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $<BR>&nb= sp; x121Address $ registeredAddress $ destinationIndicator $<BR> =  preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $<B= R>  telephoneNumber $ internationaliSDNNumber $<BR>  fa= csimileTelephoneNumber $ street $ postOfficeBox $ postalCode $<BR> &nb= sp;postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )</D= IV> <DIV>objectclass ( 2.5.6.6 NAME 'person'<BR> DESC 'RFC2256: a person'<= BR> SUP top STRUCTURAL<BR> MUST ( sn $ cn )<BR> MAY ( userPa= ssword $ telephoneNumber $ seeAlso $ description ) )</DIV> <DIV>objectclass ( 2.5.6.7 NAME 'organizationalPerson'<BR> DESC 'RFC22= 56: an organizational person'<BR> SUP person STRUCTURAL<BR> MAY (= title $ x121Address $ registeredAddress $ destinationIndicator $<BR> =  preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $<B= R>  telephoneNumber $ internationaliSDNNumber $ <BR>  f= acsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $<BR> &n= bsp;postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )</DIV> <DIV>objectclass ( 2.5.6.8 NAME 'organizationalRole'<BR> DESC 'RFC2256= : an organizational role'<BR> SUP top STRUCTURAL<BR> MUST cn<BR>&= nbsp;MAY ( x121Address $ registeredAddress $ destinationIndicator $<BR>&nbs= p; preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $= <BR>  telephoneNumber $ internationaliSDNNumber $ facsimileTeleph= oneNumber $<BR>  seeAlso $ roleOccupant $ preferredDeliveryMethod= $ street $<BR>  postOfficeBox $ postalCode $ postalAddress $<BR>=   physicalDeliveryOfficeName $ ou $ st $ l $ description ) )</DIV= > <DIV>objectclass ( 2.5.6.9 NAME 'groupOfNames'<BR> DESC 'RFC2256: a gr= oup of names (DNs)'<BR> SUP top STRUCTURAL<BR> MUST ( member $ cn= )<BR> MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description= ) )</DIV> <DIV>objectclass ( 2.5.6.10 NAME 'residentialPerson'<BR> DESC 'RFC2256= : an residential person'<BR> SUP person STRUCTURAL<BR> MUST l<BR>=  MAY ( businessCategory $ x121Address $ registeredAddress $<BR> &= nbsp;destinationIndicator $ preferredDeliveryMethod $ telexNumber $<BR>&nbs= p; teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumb= er $<BR>  facsimileTelephoneNumber $ preferredDeliveryMethod $ st= reet $<BR>  postOfficeBox $ postalCode $ postalAddress $<BR>&nbsp= ; physicalDeliveryOfficeName $ st $ l ) )</DIV> <DIV>objectclass ( 2.5.6.11 NAME 'applicationProcess'<BR> DESC 'RFC225= 6: an application process'<BR> SUP top STRUCTURAL<BR> MUST cn<BR>=  MAY ( seeAlso $ ou $ l $ description ) )</DIV> <DIV>objectclass ( 2.5.6.12 NAME 'applicationEntity'<BR> DESC 'RFC2256= : an application entity'<BR> SUP top STRUCTURAL<BR> MUST ( presen= tationAddress $ cn )<BR> MAY ( supportedApplicationContext $ seeAlso $= ou $ o $ l $<BR> description ) )</DIV> <DIV>objectclass ( 2.5.6.13 NAME 'dSA'<BR> DESC 'RFC2256: a directory = system agent (a server)'<BR> SUP applicationEntity STRUCTURAL<BR>&nbsp= ;MAY knowledgeInformation )</DIV> <DIV>objectclass ( 2.5.6.14 NAME 'device'<BR> DESC 'RFC2256: a device'= <BR> SUP top STRUCTURAL<BR> MUST cn<BR> MAY ( serialNumber $= seeAlso $ owner $ ou $ o $ l $ description ) )</DIV> <DIV>objectclass ( 2.5.6.15 NAME 'strongAuthenticationUser'<BR> DESC '= RFC2256: a strong authentication user'<BR> SUP top AUXILIARY<BR> = MUST userCertificate )</DIV> <DIV>objectclass ( 2.5.6.16 NAME 'certificationAuthority'<BR> DESC 'RF= C2256: a certificate authority'<BR> SUP top AUXILIARY<BR> MUST ( = authorityRevocationList $ certificateRevocationList $<BR>  cACert= ificate ) MAY crossCertificatePair )</DIV> <DIV>objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames'<BR> DESC 'RFC225= 6: a group of unique names (DN and Unique Identifier)'<BR> SUP top STR= UCTURAL<BR> MUST ( uniqueMember $ cn )<BR> MAY ( businessCategory= $ seeAlso $ owner $ ou $ o $ description ) )</DIV> <DIV>objectclass ( 2.5.6.18 NAME 'userSecurityInformation'<BR> DESC 'R= FC2256: a user security information'<BR> SUP top AUXILIARY<BR> MA= Y ( supportedAlgorithms ) )</DIV> <DIV>objectclass ( 2.5.6.16.2 NAME 'certificationAuthority-V2'<BR> SUP= certificationAuthority<BR> AUXILIARY MAY ( deltaRevocationList ) )</D= IV> <DIV>objectclass ( 2.5.6.19 NAME 'cRLDistributionPoint'<BR> SUP top ST= RUCTURAL<BR> MUST ( cn )<BR> MAY ( certificateRevocationList $ au= thorityRevocationList $<BR>  deltaRevocationList ) )</DIV> <DIV>objectclass ( 2.5.6.20 NAME 'dmd'<BR> SUP top STRUCTURAL<BR>&nbsp= ;MUST ( dmdName )<BR> MAY ( userPassword $ searchGuide $ seeAlso $ bus= inessCategory $<BR>  x121Address $ registeredAddress $ destinatio= nIndicator $<BR>  preferredDeliveryMethod $ telexNumber $ teletex= TerminalIdentifier $<BR>  telephoneNumber $ internationaliSDNNumb= er $ facsimileTelephoneNumber $<BR>  street $ postOfficeBox $ pos= talCode $ postalAddress $<BR>  physicalDeliveryOfficeName $ st $ = l $ description ) )</DIV> <DIV>#<BR># Object Classes from RFC 2587<BR>#<BR>objectclass ( 2.5.6.21 NAM= E 'pkiUser'<BR> DESC 'RFC2587: a PKI user'<BR> SUP top AUXILIARY<= BR> MAY userCertificate )</DIV> <DIV>objectclass ( 2.5.6.22 NAME 'pkiCA'<BR> DESC 'RFC2587: PKI certif= icate authority'<BR> SUP top AUXILIARY<BR> MAY ( authorityRevocat= ionList $ certificateRevocationList $<BR>  cACertificate $ crossC= ertificatePair ) )</DIV> <DIV>objectclass ( 2.5.6.23 NAME 'deltaCRL'<BR> DESC 'RFC2587: PKI use= r'<BR> SUP top AUXILIARY<BR> MAY deltaRevocationList )</DIV> <DIV>#<BR># Standard Track URI label schema from RFC 2079<BR># system schem= a<BR>#attributetype ( 1.3.6.1.4.1.250.1.57 NAME 'labeledURI'<BR># DESC= 'RFC2079: Uniform Resource Identifier with optional label'<BR># EQUAL= ITY caseExactMatch<BR># SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )</DIV> <DIV>objectclass ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject'<BR> DE= SC 'RFC2079: object that contains the URI attribute type'<BR> SUP top = AUXILIARY<BR> MAY ( labeledURI ) )</DIV> <DIV>#<BR># Derived from RFC 1274, but with new "short names"<BR>#<BR>#attr= ibutetype ( 0.9.2342.19200300.100.1.1<BR># NAME ( 'uid' 'userid' )<BR>= # DESC 'RFC1274: user identifier'<BR># EQUALITY caseIgnoreMatch<B= R># SUBSTR caseIgnoreSubstringsMatch<BR># SYNTAX 1.3.6.1.4.1.1466= .115.121.1.15{256} )</DIV> <DIV>attributetype ( 0.9.2342.19200300.100.1.3<BR> NAME ( 'mail' 'rfc8= 22Mailbox' )<BR> DESC 'RFC1274: RFC822 Mailbox'<BR>    = EQUALITY caseIgnoreIA5Match<BR>    SUBSTR caseIgnoreIA5Subst= ringsMatch<BR>    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} = )</DIV> <DIV>objectclass ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'<B= R> DESC 'RFC1274: simple security object'<BR> SUP top AUXILIARY<B= R> MUST userPassword )</DIV> <DIV># RFC 1274 + RFC 2247<BR>attributetype ( 0.9.2342.19200300.100.1.25<BR= > NAME ( 'dc' 'domainComponent' )<BR> DESC 'RFC1274/2247: domain = component'<BR> EQUALITY caseIgnoreIA5Match<BR> SUBSTR caseIgnoreI= A5SubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALU= E )</DIV> <DIV># RFC 2247<BR>objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'<BR>&n= bsp;DESC 'RFC2247: domain component object'<BR> SUP top AUXILIARY MUST= dc )</DIV> <DIV># RFC 2377<BR>objectclass ( 1.3.6.1.1.3.1 NAME 'uidObject'<BR> DE= SC 'RFC2377: uid object'<BR> SUP top AUXILIARY MUST uid )</DIV> <DIV># RFC 4524<BR>#   The 'associatedDomain' attribute specifies= DNS [RFC1034][RFC2181]<BR>#   host names [RFC1123] that are asso= ciated with an object.   That is,<BR>#   values of this= attribute should conform to the following ABNF:<BR>#<BR>#  &nbsp= ; domain =3D root / label *( DOT label )<BR>#    root &= nbsp; =3D SPACE<BR>#    label  =3D LETDIG [ *61( LETDIG= / HYPHEN ) LETDIG ]<BR>#    LETDIG =3D %x30-39 / %x41-5A / = %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z"<BR>#    SPACE  = =3D %x20           &= nbsp;            ; s= pace (" ")<BR>#    HYPHEN =3D %x2D    &n= bsp;           &nbsp= ;       ; hyphen ("-")<BR>#   = DOT    =3D %x2E       &n= bsp;           &nbsp= ;    ; period (".")<BR>attributetype ( 0.9.2342.19200300.100= .1.37<BR> NAME 'associatedDomain'<BR> DESC 'RFC1274: domain assoc= iated with object'<BR> EQUALITY caseIgnoreIA5Match<BR> SUBSTR cas= eIgnoreIA5SubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )</= DIV> <DIV># RFC 2459 -- deprecated in favor of 'mail' (in cosine.schema)<BR>attr= ibutetype ( 1.2.840.113549.1.9.1<BR> NAME ( 'email' 'emailAddress' 'pk= cs9email' )<BR> DESC 'RFC3280: legacy attribute for email addresses in= DNs'<BR> EQUALITY caseIgnoreIA5Match<BR> SUBSTR caseIgnoreIA5Sub= stringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )</DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV><br><br>=20 <hr> <font style=3D"font-size:12px;line-height:15px;">=C3=C0=C0=FB=C9=BD=BF=AA= =C5=CC3000=C8=CB=C7=C0=B9=BA=A3=A1440=CC=D7=CA=DB=F3=C0=A3=AC</font><a styl= e=3D"font-size:12px;line-height:15px; color:blue; text-decoration:underline= ;" href=3D"http://popme.163.com/netease/mail/003865footer.html">=BC=D3=CD= =C6300=CC=D717=BA=C5=BF=AA=CA=BC=B5=C7=BC=C7=A3=A1</a> ------=_Part_162959_15053760.1201154655304--

1 0

(ITS#5337) Start Slapd failure!!!
by dugangfeng＠163.com 24 Jan '08

24 Jan '08

Full_Name: dugangfeng Version: openldap-2.4.7 OS: linuxAS4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.181.247.78) hi all: I start slapd by -d -1 command,'slapd -d -1',but print this: @(#) $OpenLDAP: slapd 2.2.13 (Aug 19 2004 21:22:15) $ root@porky.build.redhat.com:/usr/src/build/440386-i386/BUILD/openldap-2.2.13/openldap-2.2.13/build-servers/servers/slapd daemon_init: <null> daemon_init: listen on ldap:/// daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap:///) daemon: initialized ldap:/// daemon_init: 2 listeners opened slapd init: initiated server. slap_sasl_init: initialized! bdb_initialize: initialize BDB backend bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) bdb_initialize: initialize BDB backend bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) reading config file /etc/openldap/slapd.conf line 5 (include /etc/openldap/schema/core.schema) reading config file /etc/openldap/schema/core.schema line 78 (attributetype ( 2.5.4.2 NAME 'knowledgeInformation' DESC 'RFC2256: knowledge information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )) line 87 (attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name )) line 93 (attributetype ( 2.5.4.5 NAME 'serialNumber' DESC 'RFC2256: serial number of the entity' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )) line 100 (attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC4519: two-letter ISO-3166 country code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE )) /etc/openldap/schema/core.schema: line 100: AttributeType inappropriate SUPerior: "c" slapd shutdown: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. please help me ,thanks.

1 0

Re: (ITS#5314) slapd crashed in syncrepl and mirror mode when deleting entry
by hyc＠symas.com 23 Jan '08

23 Jan '08

savithri(a)yahoo.com wrote: > Full_Name: Savithri > Version: OpenLDAP 2.4.7 > OS: SunOS 5.9 Generic_118558-08 sun4u sparc SUNW,Sun-Fire-V210 > URL: ftp://ftp.openldap.org/incoming/savithri-pkg-080108.tar.gz > Submission from: (NULL) (12.111.90.130) > I have zipped the following files: > 1. slapd.conf/s from both nodes (slapd.conf.node_A and slapd.conf.node_B ) > 2. sample data ( sample_data.ldif ) > 3. compile, run options ( build_run_option.txt) > 4. the core file ( core) > 5. log files from both the nodes A and B ( node_A_ldap.out and node_B_ldap.out) > and have ftp the file "savithri-pkg-080108.tar.gz" to > ftp://ftp.openldap.org/incoming/ There is no such file there now. Can you upload it again? Also can you include the gdb backtrace corresponding to the core file? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5336) slapd SEGV at entry_partsize
by gary＠sharcnet.ca 22 Jan '08

22 Jan '08

Full_Name: Gary Molenkamp Version: 2.4.7 OS: Linux URL: Submission from: (NULL) (129.100.171.21) On a configuration with 1 Master and 4 replicas, one of the replicas will consistently SEGV after about 2 minutes of runtime. I ran slapd through gdb and was able to catch the bt: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1157667136 (LWP 31189)] entry_partsize (e=Variable "e" is not available. ) at entry.c:677 677 len += a->a_desc->ad_cname.bv_len+1; (gdb) bt #0 entry_partsize (e=Variable "e" is not available. ) at entry.c:677 #1 0x000000000043a919 in entry_flatsize (e=Variable "e" is not available. ) at entry.c:711 #2 0x00000000004412b8 in slap_send_search_entry (op=0x2aaabc02b430, rs=0x45008ca0) at result.c:800 #3 0x000000000049b3d3 in bdb_search (op=0x2aaabc02b430, rs=0x45008ca0) at search.c:869 #4 0x000000000048b482 in overlay_op_walk (op=0x2aaabc02b430, rs=0x45008ca0, which=op_search, oi=0x7ed580, on=0x0) at backover.c:652 #5 0x000000000048b985 in over_op_func (op=0x2aaabc02b430, rs=0x45008ca0, which=op_search) at backover.c:704 #6 0x0000000000433976 in fe_op_search (op=0x2aaabc02b430, rs=0x45008ca0) at search.c:368 #7 0x0000000000434102 in do_search (op=0x2aaabc02b430, rs=0x45008ca0) at search.c:217 #8 0x00000000004319b6 in connection_operation (ctx=0x45008de0, arg_v=Variable "arg_v" is not available. ) at connection.c:1083 #9 0x0000000000431f5d in connection_read_thread (ctx=0x45008de0, argv=Variable "argv" is not available. ) at connection.c:1210 #10 0x00000000005137f4 in ldap_int_thread_pool_wrapper (xpool=0x778d20) at tpool.c:625 #11 0x0000003d5a306325 in start_thread () from /lib64/libpthread.so.0 #12 0x0000003d59acbbad in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? ()

1 0

(ITS#5305)
by ando＠sys-net.it 22 Jan '08

22 Jan '08

>From a private message the contributor sent me, it appears he's not working at this any more, and he doesn't intend to take care of the reviews. So I suggest his contribution goes to "contrib", in case anyone finds it useful. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5335) Dynamic Groups and ACLs in test006-acls
by ghenry＠OpenLDAP.org 22 Jan '08

22 Jan '08

Full_Name: Gavin Henry Version: ALL OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) ACLs using Dynamic groups are not tested. I will add them when I get a chance. Thanks, Gavin.

1 0

(ITS#5332) multimaster replication crash
by Marcel.Ritter＠rrze.uni-erlangen.de 22 Jan '08

22 Jan '08

Full_Name: Marcel Ritter Version: HEAD OS: Linux (openSUSE 10.3) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.188.78.179) When using multimaster replication slapd dies (on x86_64). I've used the scripts/test050-syncrepl-multimaster with one simple modification: I added one ldapadd command at the end of the script, trying to add some 20000 entries. With this modification it doesn't take long, till one of the slapds gets a SIGSEGV: Continuing. [New Thread 0x43005950 (LWP 629)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42003950 (LWP 604)] 0x00002b507f90f2f3 in pthread_mutex_lock () from /lib64/libpthread.so.0 > thread apply all bt Thread 7 (Thread 0x43005950 (LWP 629)): #0 0x00002b507f911656 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004dce51 in ldap_int_thread_pool_wrapper (xpool=0x82dfe0) at tpool.c:582 #2 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #3 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 6 (Thread 0x40800950 (LWP 601)): #0 0x00002b507fbe7478 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000041aac0 in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2281 #2 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #3 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 5 (Thread 0x41001950 (LWP 602)): #0 0x00002b507f911656 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004dce51 in ldap_int_thread_pool_wrapper (xpool=0x82dfe0) at tpool.c:582 #2 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #3 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 4 (Thread 0x41802950 (LWP 603)): #0 0x00002b507f911656 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004dce51 in ldap_int_thread_pool_wrapper (xpool=0x82dfe0) at tpool.c:582 #2 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #3 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 3 (Thread 0x42003950 (LWP 604)): #0 0x00002b507f90f2f3 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x00000000004a4ecf in bdb_cache_return_entry_rw (bdb=<value optimized out>, e=0xa062a8, rw=<value optimized out>, lock=<value optimized out>) at cache.c:256 #2 0x0000000000489b65 in bdb_search (op=0x42002660, rs=0x42001ee0) at search.c:909 #3 0x0000000000477492 in overlay_op_walk (op=0x42002660, rs=0x42001ee0, which=op_search, oi=0x8d2d50, on=0x0) at backover.c:653 #4 0x00000000004779b5 in over_op_func (op=0x42002660, rs=0x42001ee0, which=op_search) at backover.c:705 #5 0x0000000000471116 in syncrepl_entry (si=0x885a40, op=0x42002660, entry=0x9f7fc8, modlist=0x420025c8, syncstate=1, syncUUID=0x42002560, syncCSN=0x0) at syncrepl.c:1970 #6 0x0000000000472e5c in do_syncrep2 (op=0x42002660, si=0x885a40) at syncrepl.c:827 #7 0x00000000004746fc in do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1207 #8 0x00000000004dcdf7 in ldap_int_thread_pool_wrapper (xpool=0x82dfe0) at tpool.c:625 #9 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #10 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 2 (Thread 0x42804950 (LWP 605)): #0 0x00002b507eaad2f8 in __lock_get_internal () from /usr/lib64/libdb-4.5.so #1 0x00002b507eaae628 in __lock_vec () from /usr/lib64/libdb-4.5.so #2 0x00002b507ea87e65 in __db_lget () from /usr/lib64/libdb-4.5.so #3 0x00002b507ea172e6 in __bam_search () from /usr/lib64/libdb-4.5.so #4 0x00002b507ea07e66 in ?? () from /usr/lib64/libdb-4.5.so #5 0x00002b507ea08f07 in ?? () from /usr/lib64/libdb-4.5.so #6 0x00002b507ea7aa3c in __db_c_get () from /usr/lib64/libdb-4.5.so #7 0x00002b507ea837be in __db_c_get_pp () from /usr/lib64/libdb-4.5.so #8 0x00000000004ade7a in bdb_id2entry (be=<value optimized out>, tid=<value optimized out>, locker=25, id=2253, e=0x426825a8) at id2entry.c:131 #9 0x00000000004a60f2 in bdb_cache_find_id (op=0x42803660, tid=0x0, id=2253, eip=0x428028c8, flag=2, locker=25, lock=0x42802860) at cache.c:894 #10 0x0000000000489a67 in bdb_search (op=0x42803660, rs=0x42802ee0) at search.c:683 #11 0x0000000000477492 in overlay_op_walk (op=0x42803660, rs=0x42802ee0, which=op_search, oi=0x8d2d50, on=0x0) at backover.c:653 #12 0x00000000004779b5 in over_op_func (op=0x42803660, rs=0x42802ee0, which=op_search) at backover.c:705 #13 0x0000000000471116 in syncrepl_entry (si=0x886250, op=0x42803660, entry=0x9f86a8, modlist=0x428035c8, syncstate=1, syncUUID=0x42803560, syncCSN=0x0) at syncrepl.c:1970 #14 0x0000000000472e5c in do_syncrep2 (op=0x42803660, si=0x886250) at syncrepl.c:827 #15 0x00000000004746fc in do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1207 #16 0x00000000004dcdf7 in ldap_int_thread_pool_wrapper (xpool=0x82dfe0) at tpool.c:625 #17 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #18 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #19 0x0000000000000000 in ?? () Thread 1 (Thread 0x2b508007d4a0 (LWP 597)): #0 0x00002b507f90e576 in pthread_join () from /lib64/libpthread.so.0 #1 0x0000000000418412 in slapd_daemon () at daemon.c:2644 #2 0x0000000000407f1e in main (argc=8, argv=0x7fff2c2e7a18) at main.c:939 #0 0x00002b507f90f2f3 in pthread_mutex_lock () from /lib64/libpthread.so.0

1 0

Re: (ITS#5330) back-null upgrade
by hyc＠symas.com 21 Jan '08

21 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > I'll be upgrading back-null a bit. At the moment just support for > Back-config, Modify-Increment Extension and empty rootpw. > Maybe grow it to a useful template of a nontrivial backend later > (after I learn how to write that), with access control, referrals, > various extensions... Might be almost-unused and thus subject to > code rot, but less so than documentation of the backend API. > > However I imagine that could slow it down somewhat, so it might > become less useful when used to benchmark backends. (E.g. if you > run a test with some backend, then with back-null, diff the time > to see how much was spent in the backend.) I don't believe back-null should ever handle access controls or referrals. It shouldn't have any config options at all, really. Create some other backend if you want a dummy template that shows how all the other APIs are tied in. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5331) empty rootpw undocumented
by h.b.furuseth＠usit.uio.no 18 Jan '08

18 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard HEAD/backend.c makes an empty rootpw force invalidCredentials for Simple Bind as rootdn (as far as I can tell), but this is not documented in man5/slapd.conf.5 and slapd-config.5.

1 0

(ITS#5330) back-null upgrade
by h.b.furuseth＠usit.uio.no 18 Jan '08

18 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard I'll be upgrading back-null a bit. At the moment just support for Back-config, Modify-Increment Extension and empty rootpw. Maybe grow it to a useful template of a nontrivial backend later (after I learn how to write that), with access control, referrals, various extensions... Might be almost-unused and thus subject to code rot, but less so than documentation of the backend API. However I imagine that could slow it down somewhat, so it might become less useful when used to benchmark backends. (E.g. if you run a test with some backend, then with back-null, diff the time to see how much was spent in the backend.)

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 18 Jan '08

18 Jan '08

ando(a)sys-net.it writes: >> And your commit looks nice. > > Does it also __work__ nice? :) I only checked it passes test030 (except > with -b ldif, which errors out at compare --- the rest now is fine. test030 is almost my sole experience with back-relay. > With respect to the compare issue, I remember someone (was it you?) > raised the #ifdef SLAP_COMPARE_IN_FRONTEND issue. Yes. ITS#4937 - chain overlay bugs with Statslog & ldbm/ldif databases. -- Hallvard

1 0

Re: (ITS#5328) backends sending/setting results
by ando＠sys-net.it 18 Jan '08

18 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > And your commit looks nice. Does it also __work__ nice? :) I only checked it passes test030 (except with -b ldif, which errors out at compare --- the rest now is fine. With respect to the compare issue, I remember someone (was it you?) raised the #ifdef SLAP_COMPARE_IN_FRONTEND issue. At that time, I believe the implications of having overlays in place was not fully understood by me. In fact, the presence of the overlay infrastructure would cause the frontend to believe that the backend will handle the operation even if it actually won't. But compare returns (should return) SLAP_CB_CONTINUE if none of the overlays nor the backend itself handled the call, so there must be something incorrect in the frontend code, otherwise it should correctly workaround the compare of its own. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 18 Jan '08

18 Jan '08

ando(a)sys-net.it writes: >h.b.furuseth(a)usit.uio.no wrote: >> Back-relay operations can be factored out to something like this: >> (...) >> return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send ); > > ^^^ cancel should __NOT__ send response, since it's an extended > operation. (...) Good catch. >> return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling ); >> return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 ); >> return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 ); > > I like the idea, but that's slightly too simple. The reason I didn't > try to synthesize calls like that was the need to also handle more > complex combinations. For this reason, I'm actually considering the use > of a mask to fine-grain drive the behavior of the helper. And your commit looks nice. Actually what I intended to say was "the _current_ back-relay code can be factored out to...". I didn't know which of it was correct. -- Regards, Hallvard

1 0

Re: (ITS#5328) backends sending/setting results
by ando＠sys-net.it 16 Jan '08

16 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > back-relay's be_extended could send a result, but be_extended should > only set/return it and leave it to the frontend to send it. > Just fixed by Pierangelo. > > Looking at the code, some overlays also send results when used as > be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay. > > > More about back-relay: > > - it fails to send anything if the Delete operation is not supported. > > - be_abandon, be_chk_referrals and be_operational can return either an > LDAP result code, or 0 or 1 (which become success and operationError > if they get used as result codes). I don't know if that matters. > > Back-relay operations can be factored out to something like this: > > int > relay_back_op( > Operation *op, > SlapReply *rs, > BackendDB *bd, > BI_op_func *func, > Fail_Type fail_mode ) > { > int rc = fail_mode; > > if ( func ) { > BackendDB *be = op->o_bd; > slap_callback cb; > > relay_back_add_cb( &cb, op ); > > op->o_bd = bd; > rc = func( op, rs ); > op->o_bd = be; > > if ( op->o_callback == &cb ) { > op->o_callback = op->o_callback->sc_next; > } > > } else if ( fail_mode > Fail_1 ) { > rc = rs->sr_err = LDAP_UNWILLING_TO_PERFORM; > rs->sr_text = "operation not supported within naming context"; > if ( fail_mode == Fail_send ) { > send_ldap_result( op, rs ); > rc = 1; > } > } > > return rc; > } > > ... > return relay_back_op( op, rs, bd, bd->be_bind, Fail_send ); > (void) relay_back_op( op, rs, bd, bd->be_unbind, Fail_0 ); return 0; > return relay_back_op( op, rs, bd, bd->be_search, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_compare, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_modify, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_modrdn, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_add, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_delete, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_abandon, Fail_1 ); > return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send ); ^^^ cancel should __NOT__ send response, since it's an extended operation. On the contrary, it should set op->o_cancel if it couldn't relay the operation, otherwise the cancel thread would yield forever. > return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling ); > return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 ); > return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 ); I like the idea, but that's slightly too simple. The reason I didn't try to synthesize calls like that was the need to also handle more complex combinations. For this reason, I'm actually considering the use of a mask to fine-grain drive the behavior of the helper. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 16 Jan '08

16 Jan '08

I wrote: > Back-relay operations ...as of today... > can be factored out to something like this: > (...) Oops, I forgot: typedef enum { Fail_0 = 0, Fail_1 = 1, Fail_unwilling, Fail_send } Fail_Type; -- Hallvard

1 0

(ITS#5329) back-ldif deadlock
by h.b.furuseth＠usit.uio.no 16 Jan '08

16 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard back-ldif deadlocks on Modify access control in test006-acls (modified to support back-ldif). It tries to lock li_rdwr for both write (for the modify) and read (reading entries for access control) at the same time. However the manpage says The LDIF backend does not honor any of the access control semantics described in slapd.access(5). Only read (=r) access to the entry pseudo-attribute and to the other attribute values of the entries returned by the search operation is honored, which is performed by the frontend. Should the manpage be updated (and maybe more acl calls be added), or should the acl call be removed? Assuming the acl call should be there, one simple fix could be to introduce a 'li_wlock' mutex, lock it early on LDAP update operations, and delay locking li_rdwr until the operation is about to update the database. That can also get rid of the entry2str_mutex abuse. I've written a patch and it works, but something broke test045. Will look again later, if we are to keep the acl call(s).

1 0

(ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 16 Jan '08

16 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard back-relay's be_extended could send a result, but be_extended should only set/return it and leave it to the frontend to send it. Just fixed by Pierangelo. Looking at the code, some overlays also send results when used as be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay. More about back-relay: - it fails to send anything if the Delete operation is not supported. - be_abandon, be_chk_referrals and be_operational can return either an LDAP result code, or 0 or 1 (which become success and operationError if they get used as result codes). I don't know if that matters. Back-relay operations can be factored out to something like this: int relay_back_op( Operation *op, SlapReply *rs, BackendDB *bd, BI_op_func *func, Fail_Type fail_mode ) { int rc = fail_mode; if ( func ) { BackendDB *be = op->o_bd; slap_callback cb; relay_back_add_cb( &cb, op ); op->o_bd = bd; rc = func( op, rs ); op->o_bd = be; if ( op->o_callback == &cb ) { op->o_callback = op->o_callback->sc_next; } } else if ( fail_mode > Fail_1 ) { rc = rs->sr_err = LDAP_UNWILLING_TO_PERFORM; rs->sr_text = "operation not supported within naming context"; if ( fail_mode == Fail_send ) { send_ldap_result( op, rs ); rc = 1; } } return rc; } ... return relay_back_op( op, rs, bd, bd->be_bind, Fail_send ); (void) relay_back_op( op, rs, bd, bd->be_unbind, Fail_0 ); return 0; return relay_back_op( op, rs, bd, bd->be_search, Fail_send ); return relay_back_op( op, rs, bd, bd->be_compare, Fail_send ); return relay_back_op( op, rs, bd, bd->be_modify, Fail_send ); return relay_back_op( op, rs, bd, bd->be_modrdn, Fail_send ); return relay_back_op( op, rs, bd, bd->be_add, Fail_send ); return relay_back_op( op, rs, bd, bd->be_delete, Fail_send ); return relay_back_op( op, rs, bd, bd->be_abandon, Fail_1 ); return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send ); return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling ); return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 ); return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 );

1 0

Re: (ITS#5308) test034-translucent crashes with back-ldif
by h.b.furuseth＠usit.uio.no 15 Jan '08

15 Jan '08

ando(a)sys-net.it writes: > It is now fixed in HEAD; please test. Please, also check and test for > any side-effect introduced by the fix, as it impacts all calls to > str2entry (many, I believe). Tested, works fine so far. Haven't looked much for those side effects though. Would need to dig in the code and then construct test cases for it, I guess. -- Hallvard

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by hyc＠symas.com 15 Jan '08

15 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I understand that unfortunately in slapadd this would require either >> to keep track of inserted DNs, or to issue quite a few be_entry_get(), >> possibly resulting in a sensible penalization. Perhaps it could be an >> option, relying on the fact that slapadd is basically intended to >> operate on "well-behaved" data? > > It had better, since slapadd accepts entries out of order. (It returns > failure at the end if some child has not received a parent.) Seems like this only needs to be a feature of LDAP Add processing; slapadd should pretty much take its input verbatim. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 15 Jan '08

15 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I understand that unfortunately in slapadd this would require either >> to keep track of inserted DNs, or to issue quite a few be_entry_get(), >> possibly resulting in a sensible penalization. Perhaps it could be an >> option, relying on the fact that slapadd is basically intended to >> operate on "well-behaved" data? > > It had better, since slapadd accepts entries out of order. (It returns > failure at the end if some child has not received a parent.) This could be treated specially by performing renames as soon as info becomes available. This pushes more and more towards making this either an option or a no-go for slapadd (i.e. rely on LDIF massaging to have things nice). Note that having data not compliant with the requirement of this ITS would by no means be a violation of LDAP nor cause any operational issue to slapd. It would just be a matter of having more well-behaved data if this does not impact too much operations (and it shouldn't for run-time adds, since we already lookup the parent when adding an entry). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by h.b.furuseth＠usit.uio.no 15 Jan '08

15 Jan '08

ando(a)sys-net.it writes: > I understand that unfortunately in slapadd this would require either > to keep track of inserted DNs, or to issue quite a few be_entry_get(), > possibly resulting in a sensible penalization. Perhaps it could be an > option, relying on the fact that slapadd is basically intended to > operate on "well-behaved" data? It had better, since slapadd accepts entries out of order. (It returns failure at the end if some child has not received a parent.) -- Hallvard

1 0

Re: (ITS#5327) slapo-constraint seg faults on regex
by ando＠sys-net.it 15 Jan '08

15 Jan '08

michael(a)stroeder.com wrote: > Guess it's not that helpful: No problem, easy to reproduce (as much as easy to fix :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5327) slapo-constraint seg faults on regex
by michael＠stroeder.com 15 Jan '08

15 Jan '08

Guess it's not that helpful: (gdb) bt full #0 0x0815903b in ldap_pvt_sasl_mutex_dispose () No symbol table info available. #1 0x0000002c in ?? () No symbol table info available. #2 0x00000000 in ?? () No symbol table info available. (gdb)

1 0

(ITS#5327) slapo-constraint seg faults on regex
by michael＠stroeder.com 15 Jan '08

15 Jan '08

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.61.186) slapo-constraint seg faults if slapd.conf contains this line: constraint_attribute gender regex ^[0129]?$ The very same config works with RE24 just fine.

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 15 Jan '08

15 Jan '08

ando(a)sys-net.it wrote: > I think it is reasonable to reconstruct an entry's DN by using the parent's DN > and the entry's RDN. The rationale consists in ensuring the tree naming is as > uniform as possible. I understand that unfortunately in slapadd this would require either to keep track of inserted DNs, or to issue quite a few be_entry_get(), possibly resulting in a sensible penalization. Perhaps it could be an option, relying on the fact that slapadd is basically intended to operate on "well-behaved" data? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by ando＠sys-net.it 14 Jan '08

14 Jan '08

[Please CC messages to the ITS] Tim Bishop wrote: > On Sat, Jan 12, 2008 at 10:07:57AM +0100, Pierangelo Masarati wrote: >> tim(a)bishnet.net wrote: >> >>> For reference, it's because my libdb is built using --with-uniquename. >>> This means the function name is actually __lock_getlocker_4006. >>> >>> I didn't see this in the documentation. OpenLDAP should either correctly >>> handle this case, or document that it's not supported. >> I think using that option is a Bad Idea (TM); it is the Wrong Solution >> to the problem of having multiple coexisting versions of a library. In >> any case, adding support for that feature would be problematic and >> definitely prone to user (and developer) errors, since the value used to >> make names unique is not exposed in any header file, so it would have to >> be manually defined. There are tons of (sysadmin side) ways to make >> sure the right library is loaded, so I vote against supporting this >> feature. Of course, I'm fine about documenting that --with-uniquename >> is not supported. > > I notice lots of other functions have a mapping in the bdb header file > so you don't need to know the unique value. Is this issue occuring > because the __lock_getlocker function is not meant to be called by > external applications? The mapping depends on the version of Berkeley, so mapping names would require to know what the mapping is; but as far as I can see, it does not provide any means to expose it. Other mappings are basically needed to work around uneven cross-version naming issues in Berkeley, or for OpenLDAP internal purposes, like separating back-bdb and back-hdb names. As Hallvard pointed out, probably that function was not meant to be exposed, since it's not declared in Berkeley's headers, but unfortunately OpenLDAP code seems to need it. Of course, you can still manually CPPFLAGS=-D__lock_getlocker=__lock_getlocker_4006 to workaround your issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 14 Jan '08

14 Jan '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I think it is reasonable to reconstruct an entry's DN by using the parent's DN and the entry's RDN. The rationale consists in ensuring the tree naming is as uniform as possible. p.

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 14 Jan '08

14 Jan '08

Howard Chu writes: > The outcome of the original discussion, which Kurt again reminded me > of today, was that ldapmodify should quit its guessing games and just > accept valid LDIF input. All I see in the -devel discussion is about bugs in the parser. I see nothing about removing the default "add:"/"replace:" derived from "changetype:", though perhaps it's in the off-list discussion it refers to. > The description of the exceptions in the manpage seemed imply they > were there to accommodate slurpd users, who needed a mechanism for > applying failed updates to a target server. Now that all slurpd/replog > support has been dropped, there really is no more justification for > these exceptions. That's not my impression, nor my recollection of the -r option. The manpage lists some differences from ldif format - replog, and defaulting changetype, add/replace. But they do not seem related. Not in the old code either; removing replog code can be done cleanly and does not interfere with those defaults. BTW I was wrong about when -r was removed. Seems to have been in the middle of the 2.0 branch; I only checked the beginning. ldapmodify rev 1.97, May 2 2001 "Clean up some logic, based upon Novell patches". I see a small patch from Novell shortly before that, ITS#1075, about a bug in the -r option. The "patches" referred to means more I've missed, I guess. >> As far as I can tell Logschema doesn't support full LDIF modify though. >> reqMod is unordered, so one cannot make two modifications to the same >> attribute. E.g. "delete: foo" followed by "replace: foo". > > I suppose reqMod should be made ordered. My point about logschema is that > reqMod's syntax doesn't require separators/terminators or as many redundant > attribute references. > > attr:- foo > attr:+ bar > > is a far more efficient representation than > > delete: attr > attr: foo > - > add: attr > attr: bar > - Which is why I want the old 'replace:' default back... With a doc warning that one must use the verbose LDIF format if one wants to not worry about attribute names like "increment" or "changetype". > The logschema format is also easily grep-able without resorting to grep > windowing and other such hassles. And that was roughly the old ldapmodify format. See manpage umich ldap-3.3/doc/man/man1/ldapmodify.1. I wonder why we removed it. There are a few weird LDAP change requests that do not map to that format, e.g. add: cn cn: foo - add: cn cn: bar - but that could have been fixed simply by allowing a '-' line as in the current format. >> Maybe it's time to take this to the ldapext list and hear what others >> do. > > This is really getting off topic, unless you're suggesting that we > spec this for a new version of LDIF. Not really, more the opposite - if we just relax some restrictions on the old format ldapmodify accepted before, that's fine. But otherwise, if we end up inventing a new way to parse ldifs rather than just accepting more of what the code accepted before, I think it'd be best to see what others do first. And if so we might as well go further. I don't suggest that as part of resolving this ITS, certainly. -- Regards, Hallvard

1 0

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by h.b.furuseth＠usit.uio.no 13 Jan '08

13 Jan '08

ando(a)sys-net.it writes: > (...) There are tons of (sysadmin side) ways to make > sure the right library is loaded, so I vote against supporting this > feature. Of course, I'm fine about documenting that --with-uniquename > is not supported. configure should in any case check for __lock_getlocker(), since it's not a documented Berkeley DB function. Note that their headers do not declare it, OpenLDAP back-bdb.h does. -- Regards, Hallvard

1 0

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by ando＠sys-net.it 12 Jan '08

12 Jan '08

tim(a)bishnet.net wrote: > For reference, it's because my libdb is built using --with-uniquename. > This means the function name is actually __lock_getlocker_4006. > > I didn't see this in the documentation. OpenLDAP should either correctly > handle this case, or document that it's not supported. I think using that option is a Bad Idea (TM); it is the Wrong Solution to the problem of having multiple coexisting versions of a library. In any case, adding support for that feature would be problematic and definitely prone to user (and developer) errors, since the value used to make names unique is not exposed in any header file, so it would have to be manually defined. There are tons of (sysadmin side) ways to make sure the right library is loaded, so I vote against supporting this feature. Of course, I'm fine about documenting that --with-uniquename is not supported. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by tim＠bishnet.net 11 Jan '08

11 Jan '08

On Fri, Jan 11, 2008 at 12:30:42PM -0800, Howard Chu wrote: > tim(a)bishnet.net wrote: > >Full_Name: Tim Bishop > >Version: 2.4.7 > >OS: Solaris 9 > >URL: > >Submission from: (NULL) (129.12.3.176) > > > > > >I'm having trouble building 2.4.7 against bdb 4.6.21. The build error is: > > > >Undefined first referenced > > symbol in file > >__lock_getlocker libbackends.a(bdbinit.o) > >ld: fatal: Symbol referencing errors. No output written to .libs/slapd > >collect2: ld returned 1 exit status > >make[2]: *** [slapd] Error 1 > > > >Is bdb 4.6.21 supported? > > Yes. > > It looks like either you're linking against the wrong version of libdb, or > something is odd in the way your libdb was built. There's no OpenLDAP > software bug here, this ITS will be closed. Use the -software mailing list > for questions about working with the source. For reference, it's because my libdb is built using --with-uniquename. This means the function name is actually __lock_getlocker_4006. I didn't see this in the documentation. OpenLDAP should either correctly handle this case, or document that it's not supported. Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984

1 0

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by hyc＠symas.com 11 Jan '08

11 Jan '08

tim(a)bishnet.net wrote: > Full_Name: Tim Bishop > Version: 2.4.7 > OS: Solaris 9 > URL: > Submission from: (NULL) (129.12.3.176) > > > I'm having trouble building 2.4.7 against bdb 4.6.21. The build error is: > > Undefined first referenced > symbol in file > __lock_getlocker libbackends.a(bdbinit.o) > ld: fatal: Symbol referencing errors. No output written to .libs/slapd > collect2: ld returned 1 exit status > make[2]: *** [slapd] Error 1 > > Is bdb 4.6.21 supported? Yes. > > Is there a configure option to force a particular version of bdb? Read the INSTALL document. It looks like either you're linking against the wrong version of libdb, or something is odd in the way your libdb was built. There's no OpenLDAP software bug here, this ITS will be closed. Use the -software mailing list for questions about working with the source. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5308) test034-translucent crashes with back-ldif
by ando＠sys-net.it 11 Jan '08

11 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > "./run -b ldif test034-translucent" crashes in str2entry2() at: > entry.c:298: if( ad_prev->ad_type->sat_equality && > because ad_prev == NULL - which got through due to this statement: > entry.c:278: if (( ad_prev && ad != ad_prev ) || ( i == lines )) { The real bug here is that the loop for attribute normalizations is run also in case there is no attrs. In fact, the same error shows up if you craft a shell backend (back-shell, back-perl) so that an LDIF only containing a DN is returned. It is now fixed in HEAD; please test. Please, also check and test for any side-effect introduced by the fix, as it impacts all calls to str2entry (many, I believe). Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5325) Build error: __lock_getlocker undefined symbol
by tim＠bishnet.net 11 Jan '08

11 Jan '08

Full_Name: Tim Bishop Version: 2.4.7 OS: Solaris 9 URL: Submission from: (NULL) (129.12.3.176) I'm having trouble building 2.4.7 against bdb 4.6.21. The build error is: Undefined first referenced symbol in file __lock_getlocker libbackends.a(bdbinit.o) ld: fatal: Symbol referencing errors. No output written to .libs/slapd collect2: ld returned 1 exit status make[2]: *** [slapd] Error 1 Is bdb 4.6.21 supported? Is there a configure option to force a particular version of bdb? Thanks, Tim.

1 0

Re: (ITS#5324) Access violation on Windows due to %n in format strings
by hyc＠symas.com 11 Jan '08

11 Jan '08

ghenry(a)suretecsystems.com wrote: > > In libraries/libldap/url.c, function ldap_url_desc2str, there are a > couple of >> sprintfs that use %n in their format strings to return position information. >> The latest Windows SDKs have heavily deprecated %n and its use now results in an >> unfortunate access violation and process crash. > > ldap_url_desc2str calls desc2str, which is where the sprintfs are. > > There's actually only one in an if/else in that function. > > This is the same for the latest 2.3 libldap and 2.4 libldap > > but this doesn't really answer your question. Already fixed in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5324) Access violation on Windows due to %n in format strings
by ghenry＠suretecsystems.com 11 Jan '08

11 Jan '08

> In libraries/libldap/url.c, function ldap_url_desc2str, there are a couple of > sprintfs that use %n in their format strings to return position information. > The latest Windows SDKs have heavily deprecated %n and its use now results in an > unfortunate access violation and process crash. ldap_url_desc2str calls desc2str, which is where the sprintfs are. There's actually only one in an if/else in that function. This is the same for the latest 2.3 libldap and 2.4 libldap but this doesn't really answer your question. > > We've added a call to "_set_printf_count_output(1)" in libraries/libldap/init.c > function ldap_int_initialize() to re-enable %n so we're sufficiently worked > around for the moment. We're happy with our own workaround so we're not asking > for any kind of quick turnaround on this issue. If you want to fix this, please > do so in your own time and in your own way. You can consider this a courtesy > report only. > > If you decide not to fix this, please let me know because we'll need to add a > formal test case to our regression suites to make sure we don't resurrect the > issue when we upgrade our OpenLDAP clients. > > The msdn.microsoft.com website has the details of their proprietary function and > SDK versions where it's required in case you want to use our approach. I > included the URL so that you can get to it directly without going through MSDN's > searching. My own opinion is finding a way to do without the %n is probably > better and would result in fewer ifdefs in the code (always a plus in my book) > and less Microsoft specific code lurking around to bite us later. > > We did pull down 2.3.39 and our tech that looked at the code tells me the %n's > are still there and there's no _set_printf_count_output call so we think the > problem still exists in the latest version. Give me a virtual slap if I've got > this wrong. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by ghenry＠OpenLDAP.org 11 Jan '08

11 Jan '08

ghenry(a)suretecsystems.com wrote: > joshua(a)itsecureadmin.com wrote: >> Full_Name: Joshua Miller >> Version: 2.4.7 >> OS: CentOS 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (198.134.96.10) >> >> >> OL Version 2.4.7 >> Berkely DB 4.6 >> OS CentOS 5 >> >> Command: slapindex >> >> ISSUE: >> >> When attempting to generate cn=config from a configuration file using slapindex, >> no cn=config is generated: >> >> # cd /etc/openldap >> # mkdir slapd.d >> # /usr/sbin/slapindex -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d >> # echo $? >> 0 >> >> Program exits without error. >> >> # ls /etc/openldap/slapd.d >> >> Subsequently, running this command immediately after generates the appropriate >> cn=config: >> >> # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d >> config file testing succeeded >> # ll slapd.d >> total 8 >> drwxr-x--- 4 root root 4096 Jan 10 13:07 cn=config >> -rw------- 1 root root 1097 Jan 10 13:07 cn=config.ldif >> # >> >> > > man slapindex does indeed so you can do this... > "does indeed say you can do this..." that should read. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by ghenry＠suretecsystems.com 11 Jan '08

11 Jan '08

joshua(a)itsecureadmin.com wrote: > Full_Name: Joshua Miller > Version: 2.4.7 > OS: CentOS 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.134.96.10) > > > OL Version 2.4.7 > Berkely DB 4.6 > OS CentOS 5 > > Command: slapindex > > ISSUE: > > When attempting to generate cn=config from a configuration file using slapindex, > no cn=config is generated: > > # cd /etc/openldap > # mkdir slapd.d > # /usr/sbin/slapindex -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d > # echo $? > 0 > > Program exits without error. > > # ls /etc/openldap/slapd.d > > Subsequently, running this command immediately after generates the appropriate > cn=config: > > # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d > config file testing succeeded > # ll slapd.d > total 8 > drwxr-x--- 4 root root 4096 Jan 10 13:07 cn=config > -rw------- 1 root root 1097 Jan 10 13:07 cn=config.ldif > # > > man slapindex does indeed so you can do this... -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

RE: (ITS#5320) bug on the filter functionnality =*
by jpgressard＠hotmail.com 11 Jan '08

11 Jan '08

--_5a7f2691-df18-4e09-b6ca-32d395149553_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hallvard, I have followed the advices of Hallvard and it works. So after an upgrade to 2.4.7, you have to rebuild the indexes.1 - Stop the = slapd deamon2 - launch slapindex3 - relaunch the slapd deamon Thanks for your help. Jean-Paul> From: h.b.furuseth(a)usit.uio.no> To: jpgressard(a)hotmail.com> > jp= gressard(a)hotmail.com writes:> > The query (&(sn=3DXXXXXX*)(givenName=3D*))c= an not find the entry below.> > Does it help to stop slapd, run sbin/slapin= dex, and restart slapd?> You need to do that if you edit slapd.conf's index= statements,> and possibly when you upgrade.> > -- > Hallvard _________________________________________________________________ Nouveau ! Cr=E9ez votre profil Messenger ! http://home.services.spaces.live.com/= --_5a7f2691-df18-4e09-b6ca-32d395149553_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } </style> </head> <body class=3D'hmmessage'> Hi Hallvard,<BR> I have followed the advices of Hallvard and it works.<BR> So after an upgrade to 2.4.7, you have to rebuild the indexes.<BR>1 - Stop = the slapd deamon<BR>2 - launch slapindex<BR>3 - relaunch the slapd deamon<B= R> Thanks for your help.<BR> Jean-Paul<BR><BR>> From: h.b.furuseth(a)usit.uio.no<BR>> To: jpgressard= @hotmail.com<BR>> <BR>> jpgressard(a)hotmail.com writes:<BR>> > T= he query (&(sn=3DXXXXXX*)(givenName=3D*))can not find the entry below.<= BR>> <BR>> Does it help to stop slapd, run sbin/slapindex, and restar= t slapd?<BR>> You need to do that if you edit slapd.conf's index stateme= nts,<BR>> and possibly when you upgrade.<BR>> <BR>> -- <BR>> Ha= llvard<BR><BR><br /><hr />Windows Live Messenger 2008 vient de sortir, enco= re plus de fun ! <a href=3D'http://www.windowslive.fr/majmessenger.asp' ta= rget=3D'_new'>T=E9l=E9chargez gratuitement Messenger 2008</a></body> </html>= --_5a7f2691-df18-4e09-b6ca-32d395149553_--

1 0

(ITS#5324) Access violation on Windows due to %n in format strings
by jeff.lewis＠teradata.com 11 Jan '08

11 Jan '08

Full_Name: Jeff Lewis Version: 2.3.20 OS: Microsoft Windows on IA64 URL: http://msdn2.microsoft.com/en-us/library/ms175782.aspx Submission from: (NULL) (192.127.94.7) We (Teradata, formerly NCR) have encountered a small glitch with the latest Windows SDK and OpenLDAP client tools. We're getting an access violation where we did not get one with the older SDK. Our IA64 builds require the newer SDK because of codegen issues with the older compilers...but soon, we're going to be moving to the newer SDK for i386 and x8664 so the problem will begin to crop up there as well. Here's the problem: In libraries/libldap/url.c, function ldap_url_desc2str, there are a couple of sprintfs that use %n in their format strings to return position information. The latest Windows SDKs have heavily deprecated %n and its use now results in an unfortunate access violation and process crash. We've added a call to "_set_printf_count_output(1)" in libraries/libldap/init.c function ldap_int_initialize() to re-enable %n so we're sufficiently worked around for the moment. We're happy with our own workaround so we're not asking for any kind of quick turnaround on this issue. If you want to fix this, please do so in your own time and in your own way. You can consider this a courtesy report only. If you decide not to fix this, please let me know because we'll need to add a formal test case to our regression suites to make sure we don't resurrect the issue when we upgrade our OpenLDAP clients. The msdn.microsoft.com website has the details of their proprietary function and SDK versions where it's required in case you want to use our approach. I included the URL so that you can get to it directly without going through MSDN's searching. My own opinion is finding a way to do without the %n is probably better and would result in fewer ifdefs in the code (always a plus in my book) and less Microsoft specific code lurking around to bite us later. We did pull down 2.3.39 and our tech that looked at the code tells me the %n's are still there and there's no _set_printf_count_output call so we think the problem still exists in the latest version. Give me a virtual slap if I've got this wrong. If you decide to fix this, I'm at your disposal and can provide some testing support since IA64 platforms are pretty rare. If you want to get in touch with me and my email address doesn't work (we're in a spin-off transition right now so our infrastructure isn't as stable as it should be), you can reach me by phone at 310-616-2384.

1 0

Re: (ITS#5323) dyngroup.c:dgroup_cf() bug
by hyc＠symas.com 11 Jan '08

11 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> To avoid that, start the code with something like >> ap = on->on_bi.bi_private; >> app = ≈ > > Duh.. ignore that one. > Probably should ignore all of this. dynlist totally supersedes dyngroup now. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5323) dyngroup.c:dgroup_cf() bug
by h.b.furuseth＠usit.uio.no 11 Jan '08

11 Jan '08

I wrote: > To avoid that, start the code with something like > ap = on->on_bi.bi_private; > app = ≈ Duh.. ignore that one. -- Hallvard

1 0

(ITS#5323) dyngroup.c:dgroup_cf() bug
by h.b.furuseth＠usit.uio.no 11 Jan '08

11 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard overlays/dyngroup.c:dgroup_cf() has some strange LDAP_MOD_DELETE code: app = (adpair **)&on->on_bi.bi_private; for (...; ...; ..., app = &ap->ap_next) { ap = *app; } *app = ap->ap_next; Last statement is a no-op, since *app == *(&ap->ap_next) == ap->ap_next. I'm not sure what it's intended to do. Also the first statement makes the void* object bi_private be accessed as an adpair* object. Breaks the 'strict aliasing' rules, so I guess it can miscompile. To avoid that, start the code with something like ap = on->on_bi.bi_private; app = ≈

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by hyc＠symas.com 11 Jan '08

11 Jan '08

joshua(a)itsecureadmin.com wrote: > Quanah Gibson-Mount wrote: >> --On Thursday, January 10, 2008 9:09 PM +0000 joshua(a)itsecureadmin.com >>> Full_Name: Joshua Miller >>> Version: 2.4.7 >>> OS: CentOS 5 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (198.134.96.10) >> What makes you think you should be using slapindex to do this? > > > The admin guide suggests that any slap* command should do this: > > http://www.openldap.org/doc/admin24/slapdconf2.html#cn=config > > > Also, the slapd-config man page: > > Alternatively, an existing slapd.conf file can be converted to > the new format using slapd or any of the slap tools: > slaptest -f /etc/openldap/slapd.conf -F ETCDIR/slapd.d The docs are incomplete. slapd or slaptest will always work; the other tools (slapadd/slapcat/slapindex) don't actually invoke the config database's startup routine unless you're explicitly operating on the config backend therefore the conversion won't occur in general. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5322) slaptest exits on seg fault (SIGSEGV) if id2entry.bdb does not exist
by joshua＠itsecureadmin.com 10 Jan '08

10 Jan '08

Full_Name: Joshua Miller Version: 2.4.7 OS: CentOS 5 URL: http://ditree.com/work/gdb.ol2.4.7.out Submission from: (NULL) (198.134.96.10) When issuing slaptest prior to executing slapd to generate an id2entry.bdb file, slaptest/slapindex exits with a segmentation fault (SIGSEGV). Use case: user installs OpenLDAP, generates a configuration file, slapd.conf. User decides to generate cn=config prior to running slapd. User receives seg fault through running slaptest to perform this operation. Steps to reproduce: * install openldap 2.4.7, using berkley db 4.6 * create suitable slapd.conf * attempt to validate the configuration file using the following command: slaptest -f slapd.conf Expected results: Success Actual results: Segmentation Fault (SIGSEGV). Possibly useless gdb output located at: http://ditree.com/work/gdb.ol2.4.7.out

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by joshua＠itsecureadmin.com 10 Jan '08

10 Jan '08

Quanah Gibson-Mount wrote: > --On Thursday, January 10, 2008 9:09 PM +0000 joshua(a)itsecureadmin.com >> Full_Name: Joshua Miller >> Version: 2.4.7 >> OS: CentOS 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (198.134.96.10) > > What makes you think you should be using slapindex to do this? The admin guide suggests that any slap* command should do this: http://www.openldap.org/doc/admin24/slapdconf2.html#cn=config Also, the slapd-config man page: Alternatively, an existing slapd.conf file can be converted to the new format using slapd or any of the slap tools: slaptest -f /etc/openldap/slapd.conf -F ETCDIR/slapd.d Thanks, -- Joshua M. Miller - RHCE,VCP

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by quanah＠zimbra.com 10 Jan '08

10 Jan '08

--On Thursday, January 10, 2008 9:09 PM +0000 joshua(a)itsecureadmin.com wrote: > Full_Name: Joshua Miller > Version: 2.4.7 > OS: CentOS 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.134.96.10) > > > OL Version 2.4.7 > Berkely DB 4.6 > OS CentOS 5 > > Command: slapindex What makes you think you should be using slapindex to do this? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5321) slapindex fails to create cn=config from configuration file
by joshua＠itsecureadmin.com 10 Jan '08

10 Jan '08

Full_Name: Joshua Miller Version: 2.4.7 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.134.96.10) OL Version 2.4.7 Berkely DB 4.6 OS CentOS 5 Command: slapindex ISSUE: When attempting to generate cn=config from a configuration file using slapindex, no cn=config is generated: # cd /etc/openldap # mkdir slapd.d # /usr/sbin/slapindex -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d # echo $? 0 Program exits without error. # ls /etc/openldap/slapd.d Subsequently, running this command immediately after generates the appropriate cn=config: # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d config file testing succeeded # ll slapd.d total 8 drwxr-x--- 4 root root 4096 Jan 10 13:07 cn=config -rw------- 1 root root 1097 Jan 10 13:07 cn=config.ldif #

1 0

Re: (ITS#5320) bug on the filter functionnality =*
by quanah＠zimbra.com 10 Jan '08

10 Jan '08

--On Thursday, January 10, 2008 3:31 PM +0000 jpgressard(a)hotmail.com wrote: > I tested the same query on the version 2.4.6 and it was working. > Furthermore, if I amend the query to (&(sn=XXX*)(givenName=D*)), or > (sn=XXX*) I find the entry. As noted when 2.4.7 was released, you want to regenerate your indices. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs