- openldap-bugs - openldap.org

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by michael＠stroeder.com 30 Nov '09

30 Nov '09

Download content of testrun/ here: http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz

1 0

(ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by michael＠stroeder.com 30 Nov '09

30 Nov '09

Full_Name: Michael Ströder Version: 2.4.20 OS: SLES 10 URL: Submission from: (NULL) (84.163.87.167) SLES 10 32 Bit gcc version 4.1.0 (SUSE Linux) BDB 4.8 >>>>> Starting test043-delta-syncrepl for bdb... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entries in the producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that producer slapd is running... Using ldapmodify to modify producer directory... Waiting 7 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... test failed - producer and consumer databases differ >>>>> ./scripts/test043-delta-syncrepl failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/source/openldap-2.4.20/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/source/openldap-2.4.20/tests' make: *** [test] Error 2

1 0

Re: (ITS#6402) Mismatched parentheses in LBER_INVALID macro
by h.b.furuseth＠usit.uio.no 30 Nov '09

30 Nov '09

Fixed in cvs HEAD: Replaced the macro with a comment. I've also updated the comments above about BER identifier octets vs tags. Hopefully I got it right this time, someone please have a look:-) http://www.openldap.org/devel/cvsweb.cgi/include/lber.h.diff?r1=1.111&r2=1.… -- Hallvard

1 0

ITS#6379 published: SECURITY: Incorrect handling of '\0' in postal address
by openldap-its＠OpenLDAP.org 29 Nov '09

29 Nov '09

Private ITS#6379 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6379

1 0

Re: (ITS#6270) Conflict between ppolicy (pwdReset flag) and unique overlays
by hyc＠symas.com 29 Nov '09

29 Nov '09

clem.oudot(a)gmail.com wrote: > Full_Name: Clement OUDOT > Version: 2.4.16 > OS: RHEL 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.145.72.122) > > > Hello, > > I use both ppolicy and unique overlays. > > I try to modify the password of an account whose pwdReset attribute is set to > TRUE. I get this LDAP error: > > ldap_modify: Insufficient access (50) > additional info: unique_search failed > > In OpenLDAP logs, we can see: > > connection restricted to password changing only > send_ldap_result: conn=20 op=2 p=3 > send_ldap_result: err=50 matched="" text="Operations are restricted to > bind/unbind/abandon/StartTLS/modify password" > send_ldap_result: conn=20 op=2 p=3 > send_ldap_result: err=50 matched="" text="unique_search failed" > send_ldap_response: msgid=3 tag=103 err=50 > > > So it seems the unique overlay cannot do a search because the connection is > restricted by the ppolicy overlay. Given the configuration you provided, this should now be fixed with the unique.c in CVS HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6404) tests return success on failure
by h.b.furuseth＠usit.uio.no 29 Nov '09

29 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Some tests exit with the result code of the last failed command, even when that is 0 (success) and the command should have failed: if test $RC != 10 ; then echo "ldapmodify should have returned referral ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit 1 fi Fixing most cases I've spotted. However someone who knows pcache should look at test020-proxycache. It has 'exit 0's which look intentional, some which look like errors (says "should have failed"), and some 'return $RC's which RC can be 0.

1 0

(ITS#6403) crash with translucent + back-null
by h.b.furuseth＠usit.uio.no 29 Nov '09

29 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Callers of bi->bi_entry_get_rw(,,,,,Entry **ent) should set *ent = NULL. Translucent doesn't. null_back_entry_get() assert()s it. Crash. Happens with ./run -b null test034-translucent. I'll fix translucent for now, but I assume a saner fix would be to change that "calling convention" - which I suspect exists in the first place because I once gave a bug just like this the same minimal fix.

1 0

Re: (ITS#6402) Mismatched parentheses in LBER_INVALID macro
by h.b.furuseth＠usit.uio.no 27 Nov '09

27 Nov '09

julianfoad(a)btopenworld.com writes: > The definition of the macro LBER_INVALID in 'include/lber.h' has > mismatched (unbalanced) parentheses, meaning that it cannot be used as > a valid C expression by itself. Wow. You are the first to notice for 10 years. The test is incomplete too. I guess I can come up with bit hack for a better test is anyone is interested, but otherwise we can just delete it. The macro only existed without a parse error for one month in 1999, in revision 1.17 through 1.30. Next revision broke it with commit message "Fix bad LBER_INVALID macro":-) -- Hallvard

1 0

(ITS#6402) Mismatched parentheses in LBER_INVALID macro
by julianfoad＠btopenworld.com 27 Nov '09

27 Nov '09

Full_Name: Julian Foad Version: CVS head (include/lber.h r1.111) OS: Linux URL: ftp://ftp.openldap.org/incoming/julian-foad-091127.patch Submission from: (NULL) (217.169.20.120) The definition of the macro LBER_INVALID in 'include/lber.h' has mismatched (unbalanced) parentheses, meaning that it cannot be used as a valid C expression by itself. This error was noticed when parsing the file with 'ctypesgen' as part of building the ctypes-python bindings of Subversion. The patch to fix it, in Unidiff format, looks like this: #define LBER_INVALID(t) (((t) & (ber_tag_t) 0x080UL) \ - && (((t) & (ber_tag_t) ~ 0x0FF)) + && ((t) & (ber_tag_t) ~ 0x0FF)) I uploaded the patch file; URL is filled in below. The macro is not used within the openldap source, so this problem and this fix makes no difference to the building and testing of openldap itself.

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by hyc＠symas.com 24 Nov '09

24 Nov '09

masarati(a)aero.polimi.it wrote: >> Howard Chu wrote: >>> Of course, no one is saying for certain that this is the explanation, >>> yet. >> >> It sounds reasonable to me :) > Based on my *very incomplete and possibly wrong* analysis, the problem > would be automatically cured by using back-bdb. Also, fixing back-hdb *if > it's broken at all* should be possible. Quite certain this is not the explanation, since syncrepl will call syncrepl_add_glue() whenever it needs to store an entry that doesn't yet have its parent. -- -- Howard Chu CTO, 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#6401) openldap doesn't start......
by quanah＠zimbra.com 24 Nov '09

24 Nov '09

--On Tuesday, November 24, 2009 6:20 PM +0000 luisvm87(a)gmail.com wrote: > Full_Name: Luis Vargas Mieles > Version: 2.4.19 > OS: centOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.93.195.131) > slapd starting > ........ and slapd never start -.- I don't know where the mistake is... I > checked the configuration files slapd.conf, odbc.ini, odbcinst.ini and I > can't find the mistake, please help me =) How are you checking on whether or not slapd ever "started"? Is there a slapd process? Maybe it is waiting on a connection to the mysql server. In any case, the ITS system is not for questions about how to use/configure OpenLDAP. Please direct such questions to the openldap-software(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6401) openldap doesn't start......
by luisvm87＠gmail.com 24 Nov '09

24 Nov '09

Full_Name: Luis Vargas Mieles Version: 2.4.19 OS: centOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.93.195.131) Hello when I started the slapd, it generates these sentences... [root@localhost ~]# /usr/local/libexec/slapd -d 1 @(#) $OpenLDAP: slapd 2.4.19 (Nov 23 2009 19:03:54) $ root@localhost.localdomain:/usr/src/openldap-2.4.19/servers/slapd ldap_pvt_gethostbyname_a: host=localhost.localdomain, r=0 daemon_init: listen on ldap:/// daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap:///) daemon: listener initialized ldap:/// daemon_init: 2 listeners opened ldap_create slapd init: initiated server. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 4.8.24: (August 14, 2009) hdb_back_initialize: initialize HDB backend hdb_back_initialize: Berkeley DB 4.8.24: (August 14, 2009) ==>sql_back_initialize() <==sql_back_initialize() ==>backsql_db_init() ==>backsql_init_db_env() <==backsql_init_db_env()=0 <==backsql_db_init() >>> dnPrettyNormal: <o=sql,c=RU> <<< dnPrettyNormal: <o=sql,c=RU>, <o=sql,c=ru> >>> dnPrettyNormal: <cn=root,o=sql,c=RU> <<< dnPrettyNormal: <cn=root,o=sql,c=RU>, <cn=root,o=sql,c=ru> ==>backsql_db_config() <==backsql_db_config(): dbname=example ==>backsql_db_config() <==backsql_db_config(): dbuser=root ==>backsql_db_config() <==backsql_db_config(): dbpasswd=xxxx ==>backsql_db_config() <==backsql_db_config(): subtree_cond=ldap_entries.dn LIKE CONCAT('%',?) ==>backsql_db_config() <==backsql_db_config(): insentry_stmt=INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?) ==>backsql_db_config() <==backsql_db_config(): has_ldapinfo_dn_ru=no >>> dnNormalize: <cn=Subschema> <<< dnNormalize: <cn=subschema> matching_rule_use_init 1.2.840.113556.1.4.804 (integerBitOrMatch): matchingRuleUse: ( 1.2.840.113556.1.4.804 NAME 'integerBitOrMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ mailPreferenceOption ) ) 1.2.840.113556.1.4.803 (integerBitAndMatch): matchingRuleUse: ( 1.2.840.113556.1.4.803 NAME 'integerBitAndMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ mailPreferenceOption ) ) 1.3.6.1.4.1.1466.109.114.2 (caseIgnoreIA5Match): matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' APPLIES ( altServer $ olcDbConfig $ c $ mail $ dc $ associatedDomain $ email $ aRecord $ mDRecord $ mXRecord $ nSRecord $ sOARecord $ cNAMERecord $ janetMailbox ) ) 1.3.6.1.4.1.1466.109.114.1 (caseExactIA5Match): matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' APPLIES ( altServer $ olcDbConfig $ c $ mail $ dc $ associatedDomain $ email $ aRecord $ mDRecord $ mXRecord $ nSRecord $ sOARecord $ cNAMERecord $ janetMailbox ) ) 2.5.13.39 (certificateListMatch): 2.5.13.38 (certificateListExactMatch): matchingRuleUse: ( 2.5.13.38 NAME 'certificateListExactMatch' APPLIES ( authorityRevocationList $ certificateRevocationList $ deltaRevocationList ) ) 2.5.13.35 (certificateMatch): 2.5.13.34 (certificateExactMatch): matchingRuleUse: ( 2.5.13.34 NAME 'certificateExactMatch' APPLIES ( userCertificate $ cACertificate ) ) 2.5.13.30 (objectIdentifierFirstComponentMatch): matchingRuleUse: ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ ldapSyntaxes $ supportedApplicationContext ) ) 2.5.13.29 (integerFirstComponentMatch): matchingRuleUse: ( 2.5.13.29 NAME 'integerFirstComponentMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ mailPreferenceOption ) ) 2.5.13.27 (generalizedTimeMatch): matchingRuleUse: ( 2.5.13.27 NAME 'generalizedTimeMatch' APPLIES ( createTimestamp $ modifyTimestamp ) ) 2.5.13.24 (protocolInformationMatch): matchingRuleUse: ( 2.5.13.24 NAME 'protocolInformationMatch' APPLIES protocolInformation ) 2.5.13.23 (uniqueMemberMatch): matchingRuleUse: ( 2.5.13.23 NAME 'uniqueMemberMatch' APPLIES uniqueMember ) 2.5.13.22 (presentationAddressMatch): matchingRuleUse: ( 2.5.13.22 NAME 'presentationAddressMatch' APPLIES presentationAddress ) 2.5.13.20 (telephoneNumberMatch): matchingRuleUse: ( 2.5.13.20 NAME 'telephoneNumberMatch' APPLIES ( telephoneNumber $ homePhone $ mobile $ pager ) ) 2.5.13.17 (octetStringMatch): matchingRuleUse: ( 2.5.13.17 NAME 'octetStringMatch' APPLIES ( userPassword $ olcDbCryptKey ) ) 2.5.13.16 (bitStringMatch): matchingRuleUse: ( 2.5.13.16 NAME 'bitStringMatch' APPLIES x500UniqueIdentifier ) 2.5.13.14 (integerMatch): matchingRuleUse: ( 2.5.13.14 NAME 'integerMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ mailPreferenceOption ) ) 2.5.13.13 (booleanMatch): matchingRuleUse: ( 2.5.13.13 NAME 'booleanMatch' APPLIES ( hasSubordinates $ olcAddContentAcl $ olcGentleHUP $ olcHidden $ olcLastMod $ olcMirrorMode $ olcMonitoring $ olcReadOnly $ olcReverseLookup $ olcDbChecksum $ olcDbNoSync $ olcDbDirtyRead $ olcDbLinearIndex $ olcSpNoPresent $ olcSpReloadHint ) ) 2.5.13.11 (caseIgnoreListMatch): matchingRuleUse: ( 2.5.13.11 NAME 'caseIgnoreListMatch' APPLIES ( postalAddress $ registeredAddress $ homePostalAddress ) ) 2.5.13.8 (numericStringMatch): matchingRuleUse: ( 2.5.13.8 NAME 'numericStringMatch' APPLIES ( x121Address $ internationaliSDNNumber ) ) 2.5.13.7 (caseExactSubstringsMatch): matchingRuleUse: ( 2.5.13.7 NAME 'caseExactSubstringsMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.6 (caseExactOrderingMatch): matchingRuleUse: ( 2.5.13.6 NAME 'caseExactOrderingMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.5 (caseExactMatch): matchingRuleUse: ( 2.5.13.5 NAME 'caseExactMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcSpCheckpoint $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage ) ) 2.5.13.4 (caseIgnoreSubstringsMatch): matchingRuleUse: ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.3 (caseIgnoreOrderingMatch): matchingRuleUse: ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.2 (caseIgnoreMatch): matchingRuleUse: ( 2.5.13.2 NAME 'caseIgnoreMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcSpCheckpoint $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage ) ) 1.2.36.79672281.1.13.3 (rdnMatch): 2.5.13.1 (distinguishedNameMatch): matchingRuleUse: ( 2.5.13.1 NAME 'distinguishedNameMatch' APPLIES ( creatorsName $ modifiersName $ subschemaSubentry $ entryDN $ namingContexts $ aliasedObjectName $ dynamicSubtrees $ distinguishedName $ seeAlso $ olcDefaultSearchBase $ olcRootDN $ olcSchemaDN $ olcSuffix $ olcUpdateDN $ olcRelay $ member $ owner $ roleOccupant $ manager $ documentAuthor $ secretary $ associatedName $ dITRedirect ) ) 2.5.13.0 (objectIdentifierMatch): matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) ) slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}inetorgperson" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" WARNING: No dynamic config support for database sql. config_build_entry: "olcDatabase={1}sql" backend_startup_one: starting "o=sql,c=RU" ==>backsql_db_open(): testing RDBMS connection backsql_db_open(): concat func not specified (use "concat_pattern" directive in slapd.conf) backsql_db_open(): children search SQL condition not specified (use "children_cond" directive in slapd.conf); preparing default backsql_db_open(): setting "ldap_entries.dn LIKE CONCAT('%,',?)" as default "children_cond" backsql_db_open(): DN match search SQL condition not specified (use "dn_match_cond" directive in slapd.conf); preparing default backsql_db_open(): setting "ldap_entries.dn=?" as default "dn_match_cond" backsql_db_open(): objectclass mapping SQL statement not specified (use "oc_query" directive in slapd.conf) backsql_db_open(): setting "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" by default backsql_db_open(): attribute mapping SQL statement not specified (use "at_query" directive in slapd.conf) backsql_db_open(): setting "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" by default backsql_db_open(): entry deletion SQL statement not specified (use "delentry_stmt" directive in slapd.conf) backsql_db_open(): setting "DELETE FROM ldap_entries WHERE id=?" by default backsql_db_open(): entry deletion SQL statement not specified (use "renentry_stmt" directive in slapd.conf) backsql_db_open(): setting "UPDATE ldap_entries SET dn=?,parent=?,keyval=? WHERE id=?" by default backsql_db_open(): objclasses deletion SQL statement not specified (use "delobjclasses_stmt" directive in slapd.conf) backsql_db_open(): setting "DELETE FROM ldap_entry_objclasses WHERE entry_id=?" by default ==>backsql_get_db_conn() ==>backsql_open_db_handle() <==backsql_open_db_handle() <==backsql_get_db_conn() ==>backsql_load_schema_map() backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" objectClass: id="1" name="inetOrgPerson" keytbl="persons" keycol="id" create_proc="" create_keyval="" delete_proc="" expect_return="0"create_hint="" backsql_load_schema_map(): objectClass "inetOrgPerson": keytbl="persons" keycol="id" expect_return: add=0, del=0; attributes: objectClass: id="2" name="document" keytbl="documents" keycol="id" create_proc="" create_keyval="" delete_proc="" expect_return="0"create_hint="" backsql_load_schema_map(): objectClass "document": keytbl="documents" keycol="id" expect_return: add=0, del=0; attributes: objectClass: id="3" name="organization" keytbl="institutes" keycol="id" create_proc="" create_keyval="" delete_proc="" expect_return="0"create_hint="" backsql_load_schema_map(): objectClass "organization": keytbl="institutes" keycol="id" expect_return: add=0, del=0; attributes: objectClass: id="4" name="referral" keytbl="referrals" keycol="id" create_proc="" create_keyval="" delete_proc="" expect_return="0"create_hint="" backsql_load_schema_map(): objectClass "referral": keytbl="referrals" keycol="id" expect_return: add=0, del=0; attributes: backsql_load_schema_map(): at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id="2" attributeType: name="description" sel_expr="documents.abstract" from="documents" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT documents.abstract AS description FROM documents WHERE documents.id=? ORDER BY description" attributeType: name="documentTitle" sel_expr="documents.title" from="documents" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT documents.title AS documentTitle FROM documents WHERE documents.id=? ORDER BY documentTitle" attributeType: name="documentAuthor" sel_expr="documentAuthor.dn" from="ldap_entries AS documentAuthor,documents,authors_docs,persons" join_where="documentAuthor.keyval=persons.id AND documentAuthor.oc_map_id=1 AND authors_docs.doc_id=documents.id AND aut backsql_oc_get_attr_mapping(): preconstructed query "SELECT documentAuthor.dn AS documentAuthor FROM ldap_entries AS documentAuthor,documents,authors_docs,persons WHERE documents.id=? AND documentAuthor.keyval=persons.id AND documentAuthor.oc_map_id=1 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id ORDER BY documentAuthor" attributeType: name="documentIdentifier" sel_expr="concat('document ',documents.id)" from="documents" join_where="documentAuthor.keyval=persons.id AND documentAuthor.oc_map_id=1 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id" add backsql_oc_get_attr_mapping(): preconstructed query "SELECT concat('document ',documents.id) AS documentIdentifier FROM documents WHERE documents.id=? ORDER BY documentIdentifier" backsql_load_schema_map("document"): autoadding 'objectClass' and 'ref' mappings backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "referral" with param oc_id="4" attributeType: name="ou" sel_expr="referrals.name" from="referrals" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT referrals.name AS ou FROM referrals WHERE referrals.id=? ORDER BY ou" attributeType: name="ref" sel_expr="referrals.url" from="referrals" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT referrals.url AS ref FROM referrals WHERE referrals.id=? ORDER BY ref" backsql_load_schema_map("referral"): autoadding 'objectClass' and 'ref' mappings backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "organization" with param oc_id="3" attributeType: name="o" sel_expr="institutes.name" from="institutes" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT institutes.name AS o FROM institutes WHERE institutes.id=? ORDER BY o" attributeType: name="dc" sel_expr="lower(institutes.name)" from="institutes,ldap_entries AS dcObject,ldap_entry_objclasses as auxObjectClass" join_where="institutes.id=dcObject.keyval AND dcObject.oc_map_id=3 AND dcObject.id=auxObjectClass.entry_id AND au backsql_oc_get_attr_mapping(): preconstructed query "SELECT lower(institutes.name) AS dc FROM institutes,ldap_entries AS dcObject,ldap_entry_objclasses AS auxObjectClass WHERE institutes.id=? AND institutes.id=dcObject.keyval AND dcObject.oc_map_id=3 AND dcObject.id=auxObjectClass.entry_id AND auxObjectClass.oc_name='dcObject' ORDER BY dc" backsql_load_schema_map("organization"): autoadding 'objectClass' and 'ref' mappings backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "inetOrgPerson" with param oc_id="1" attributeType: name="cn" sel_expr="concat(persons.name,' ',persons.surname)" from="persons" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT concat(persons.name,' ',persons.surname) AS cn FROM persons WHERE persons.id=? ORDER BY cn" attributeType: name="telephoneNumber" sel_expr="phones.phone" from="persons,phones" join_where="phones.pers_id=persons.id" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT phones.phone AS telephoneNumber FROM persons,phones WHERE persons.id=? AND phones.pers_id=persons.id ORDER BY telephoneNumber" attributeType: name="givenName" sel_expr="persons.name" from="persons" join_where="phones.pers_id=persons.id" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT persons.name AS givenName FROM persons WHERE persons.id=? ORDER BY givenName" attributeType: name="sn" sel_expr="persons.surname" from="persons" join_where="phones.pers_id=persons.id" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT persons.surname AS sn FROM persons WHERE persons.id=? ORDER BY sn" attributeType: name="userPassword" sel_expr="persons.password" from="persons" join_where="persons.password IS NOT NULL" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT persons.password AS userPassword FROM persons WHERE persons.id=? AND persons.password IS NOT NULL ORDER BY userPassword" attributeType: name="seeAlso" sel_expr="seeAlso.dn" from="ldap_entries AS seeAlso,documents,authors_docs,persons" join_where="seeAlso.keyval=documents.id AND seeAlso.oc_map_id=2 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id" add backsql_oc_get_attr_mapping(): preconstructed query "SELECT seeAlso.dn AS seeAlso FROM ldap_entries AS seeAlso,documents,authors_docs,persons WHERE persons.id=? AND seeAlso.keyval=documents.id AND seeAlso.oc_map_id=2 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id ORDER BY seeAlso" attributeType: name="userCertificate" sel_expr="certs.cert" from="persons,certs" join_where="certs.pers_id=persons.id" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT certs.cert AS userCertificate FROM persons,certs WHERE persons.id=? AND certs.pers_id=persons.id ORDER BY userCertificate" backsql_load_schema_map("inetOrgPerson"): autoadding 'objectClass' and 'ref' mappings <==backsql_load_schema_map() ==>backsql_free_db_conn() ==>backsql_close_db_handle(0x932e428) <==backsql_close_db_handle(0x932e428) <==backsql_free_db_conn() <==backsql_db_open(): test succeeded, schema map loaded slapd starting ........ and slapd never start -.- I don't know where the mistake is... I checked the configuration files slapd.conf, odbc.ini, odbcinst.ini and I can't find the mistake, please help me =) here we have the configuration files +++++slapd.conf+++++++ # $OpenLDAP: /servers/slapd/back-sql/rdbms_depend/mysql/slapd.conf,v 1.5.2.1 2005/01/20 18:04:03 kurt Exp $ # # 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/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.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 ####################################################################### # sql database definitions ####################################################################### database sql suffix "o=sql,c=RU" rootdn "cn=root,o=sql,c=RU" rootpw {SSHA}J3tV8vA0ouDU6LfnaPraZDPebsQdIrqe dbname example dbuser root dbpasswd admin subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no +++++++odbc.ini+++++++ [example] Description = Example for OpenLDAP's back-sql Driver = MySQL #Trace = No Database = example Server = localhost Port = 3306 Socket = /var/lib/mysql/mysql.sock User = root Password = admin #ReadOnly = No #RowVersioning = No #ShowSystemTables = No #ShowOidColumn = No #FakeOidIndex = No #ConnSettings = +++++++odbcinst.ini++++++++ # Example driver definitinions # # # Included in the unixODBC package [PostgreSQL] Description = ODBC for PostgreSQL Driver = /usr/lib/libodbcpsql.so Setup = /usr/lib/libodbcpsqlS.so FileUsage = 1 # Driver from the MyODBC package # Setup from the unixODBC package #[MySQL] #Description = ODBC for MySQL #Driver = /usr/lib/libmyodbc.so #Setup = /usr/lib/libodbcmyS.so #FileUsage = 1 [MySQL] Description = ODBC for MySQL Driver = /usr/lib/libmyodbc3.so Setup = /usr/lib/libodbcmyS.so FileUsage = 1 +++++++++++++++++++++++++++++++++++++++++++++++ thanks for your attention :)

1 0

Re: (ITS#6395) Web site release readme needs BDB version compatibility update
by quanah＠zimbra.com 23 Nov '09

23 Nov '09

--On Monday, November 23, 2009 5:39 AM +0000 battery(a)writeme.com wrote: > Full_Name: Matt Kassawara > Version: 2.4.18 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.56.179.224) > > > The release readme posted on the OpenLDAP web site doesn't explicitly > indicate compatibility with BDB 4.8. > > http://www.openldap.org/software/release/readme.html This will be addressed automatically when 2.4.20 is released, as this was fixed a while ago in CVS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6399) Documentation error for "referral" result code 10
by hyc＠symas.com 23 Nov '09

23 Nov '09

chris.czub(a)gmail.com wrote: > Full_Name: Chris Czub > Version: 2.4 > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.82.64.120) > > > http://www.openldap.org/doc/admin24/appendix-ldap-result-codes.html#{{refer… > > The referral section refers to section 4.1.10, which is non-existent in the > documentation. This appendix is apparently a copy/paste from RFC4511; this then seems to be a reference to 4.1.10 in that RFC. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6400) Different-sized CSNs confuse accesslog
by h.b.furuseth＠usit.uio.no 23 Nov '09

23 Nov '09

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Given CSNs of different lengths, overlays/accesslog.c:log_old_lookup() remembers truncated versions of the longer CSNs as "max CSN". The remembered length shrinks but never grows as CSNs change. I think the test if ( len > pd->csn.bv_len ) len = pd->csn.bv_len; should be if ( len > LDAP_PVT_CSNSTR_BUFSIZE ) len = LDAP_PVT_CSNSTR_BUFSIZE; since as far as I can tell pd->csn.bv_val is always csnbuf from accesslog_purge(). The compare just below must be fixed to match. It is buggy now anyway, CSNs of different lengths can compare equal.

1 0

Re: (ITS#6398) quiet valgrind (tool -F parsing)
by h.b.furuseth＠usit.uio.no 23 Nov '09

23 Nov '09

richton(a)nbcs.rutgers.edu writes: > Quiets a valgrind "definitely lost" leak complaint. > I submit this patch as public domain. Thanks. Fixed in HEAD. -- Hallvard

1 0

Re: (ITS#6397) accesslog + syncprov crash
by h.b.furuseth＠usit.uio.no 23 Nov '09

23 Nov '09

Poking a bit more in the backtrace (with a new coredump, sorry) shows that the filter given to test_filter() is NULL because *ss = { s_base = {bv_len = 6, bv_val = 0x1f94c5a0 "cn=log"}, s_eid = 1, s_op = 0x1f948310 { o_hdr = 0x1f948480 {all nulls}, o_controls = 0x1f9485c8 [(void *) 0x0]}, s_rid = 1, s_sid = -1, s_flags = 1, s_inuse = 1, <fields with null values omitted> } in frame 1, syncprov_matchops (op=0x42ec6690, opc=0x1f958ca0, saveit=1) at syncprov.c:1304: rc = test_filter( &op2, e, ss->s_op->ors_filter ); I have ss == si->si_ops != sm->sm_op. *si = { si_ops = 0x1f951c20, si_ctxcsn = 0x1f74fa70, si_contextdn = {bv_len = 6, bv_val = 0x1f4e4310 "cn=log"}, si_sids = 0x1f74fae0 [0], si_numcsns = 1, si_numops = 49, si_nopres = 1, si_usehint = 1, si_mods = 0x1fa615b0 {avl_data = 0x1fa61d20}, si_ops_mutex = { __data = {__lock = 1, __owner = 26790, __nusers = 1}, __size = "\001\000\000\000\000\000\000\000\246h\000\000\001", '\0' <repeats 26 times>, __align = 1}} Following si->si_mods: sml_mod.sm_type is garbage, is that relevant? *((modtarget *) si->si_mods->avl_data)->mt_mods->mi_op = { o_hdr = 0x42ec6800, o_tag = 102 <LDAP_REQ_MODIFY>, o_time = 1259003422, o_tincr = 0, o_bd = 0x42ec62d0, o_req_dn = {bv_len = 6, bv_val = 0x1f4e4400 "cn=log"}, o_req_ndn = {bv_len = 6, bv_val = 0x1f4e4310 "cn=log"}, o_request.oq_modify = { rs_mods = { rs_modlist = 0x42ec64c0 { sml_mod = { sm_desc = 0x1f4a46e0 <entryCSN>, sm_values = 0x42ec6500 &[ {bv_len = 40, bv_val = 0x42ec6530 "20091123191016.381756Z#000000#000#000000\311_\214\031="}, BER_BVNULL], sm_numvals = 1, sm_op = 2, sm_flags = 1, sm_type = {bv_len = 4222451713, bv_val = 0x42ec6680 ""}}}, rs_no_opattrs = 1 '\001'}}, o_no_schema_check = 1 '\001', o_ctrlflag = '\0' <repeats 14 times>, "\002", '\0' <repeats 16 times>, o_controls = 0x42ec6948 &[(void *) 0x0], o_authz = { sai_dn = {bv_len = 28, bv_val = 0x1f4e46f0 "cn=Manager,dc=example,dc=com"}, sai_ndn = {bv_len = 28, bv_val = 0x1f4e4d90 "cn=manager,dc=example,dc=com"}}, o_callback = 0x1f958c80, o_csn = {bv_len = 40, bv_val = 0x42ec6530 "20091123191016.381756Z#000000#000#000000\311_\214\031="}, o_extra = {slh_first = 0x1f958d28}} (gdb) backtrace #0 0x0000000000452066 in test_filter (op=0x42ec5bf0, e=0x1f577e48, f=0x0) at filterentry.c:69 #1 0x0000000000529cd1 in syncprov_matchops (op=0x42ec6690, opc=0x1f958ca0, saveit=1) at syncprov.c:1304 #2 0x000000000052c524 in syncprov_op_mod (op=0x42ec6690, rs=0x42ec6620) at syncprov.c:2064 #3 0x00000000004b3f0f in overlay_op_walk (op=0x42ec6690, rs=0x42ec6620, which=op_modify, oi=0x1f4e47e0, on=0x1f4e49c0) at backover.c:659 #4 0x00000000004b41a1 in over_op_func (op=0x42ec6690, rs=0x42ec6620, which=op_modify) at backover.c:721 #5 0x00000000004b42b7 in over_op_modify (op=0x42ec6690, rs=0x42ec6620) at backover.c:760 #6 0x0000000000521c67 in accesslog_purge (ctx=0x42ec6d60, arg=0x1f4e4760) at accesslog.c:699 #7 0x00000000005478ed in ldap_int_thread_pool_wrapper (xpool=0x1f4ae8a0) at tpool.c:685 #8 0x0000003d1a4064a7 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003d198d3c2d in clone () from /lib64/libc.so.6 -- Hallvard

1 0

(ITS#6399) Documentation error for "referral" result code 10
by chris.czub＠gmail.com 23 Nov '09

23 Nov '09

Full_Name: Chris Czub Version: 2.4 OS: CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.82.64.120) http://www.openldap.org/doc/admin24/appendix-ldap-result-codes.html#{{refer… The referral section refers to section 4.1.10, which is non-existent in the documentation.

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by quanah＠zimbra.com 23 Nov '09

23 Nov '09

--On Monday, November 23, 2009 8:38 PM +0200 rolnas(a)gmail.com wrote: > I raised (twice) to: > > cachesize 20000 > idlcachesize 100000 Ok, make sure dncachesize is set to zero as well. ;) > BDB software is 4.6.21.4 (from FreeBSD ports as OpenLDAP itself). > > I have no time (sorry) to try compile and run current CVS version. Well, as I said, there are a number of known problems with the entry cache in 2.4.19 which are fixed in CVS. So when you find the time, I'd suggest building the CVS version and using it instead. If it still occurs there, the developers will probably want additional information. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by rolnas＠gmail.com 23 Nov '09

23 Nov '09

On 2009.11.23, at 20:12, Quanah Gibson-Mount wrote: > --On Monday, November 23, 2009 8:09 PM +0200 rolnas(a)gmail.com wrote: >=20 >> P.S. I found myself cachesize < total number of entries. Probably I >> lowered it trying to workaround this problem. >=20 > Yes, please raise it. Also, please try the current CVS as I noted. = Also, what BDB version of software are you using? I raised (twice) to: cachesize 20000 idlcachesize 100000 but it didn't help. My test (ldapsearch of entire DB) usually takes ~2s, after changes (the = same sequence of deletes/adds) - ~18s on master, ~60s on mirror, ~140s = on slave. After restart, again ~2s. BDB software is 4.6.21.4 (from FreeBSD ports as OpenLDAP itself). I have no time (sorry) to try compile and run current CVS version. Regards, Rolandas Naujikas > Thanks! >=20 > --Quanah >=20 > -- >=20 > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by quanah＠zimbra.com 23 Nov '09

23 Nov '09

--On Monday, November 23, 2009 8:09 PM +0200 rolnas(a)gmail.com wrote: > P.S. I found myself cachesize < total number of entries. Probably I > lowered it trying to workaround this problem. Yes, please raise it. Also, please try the current CVS as I noted. Also, what BDB version of software are you using? Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6398) quiet valgrind (tool -F parsing)
by richton＠nbcs.rutgers.edu 23 Nov '09

23 Nov '09

Full_Name: Aaron Richton Version: HEAD OS: irrelevant URL: Submission from: (NULL) (128.6.31.135) Quiets a valgrind "definitely lost" leak complaint. I submit this patch as public domain. --- slapcommon.c~ 2009-11-23 11:22:05.000000000 -0500 +++ slapcommon.c 2009-11-23 11:22:37.000000000 -0500 @@ -763,6 +763,11 @@ conffile = NULL; } + if ( confdir != NULL ) { + ch_free( confdir ); + confdir = NULL; + } + if ( ldiffile != NULL ) { ch_free( ldiffile ); ldiffile = NULL;

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by rolnas＠gmail.com 23 Nov '09

23 Nov '09

> ... > Can you reproduce this behavior with current CVS checkout of the = OPENLDAP_REL_ENG_2_4 branch? I'll note that the entry cache has been = broken for most of RE2.4, and it is specifically fixed in CVS and will = be in the upcoming 2.4.20 release. >=20 > You fail to note in this ITS any of the following information, which = would be useful: Sorry, It was my first submission. > (a) Total number of entries in the database ~15000 (14738) >=20 >> =46rom slapd.conf/cn=3Dconfig: > (b) cachesize 10000 > (c) idlcachesize 50000 > (d) dncachesize Not set, I found somewhere to better don't touch it. >> =46rom the BDB database: >=20 > (e) output of du -c -h *.bdb in the database directory 448K associatedDomain.bdb 288K carLicense.bdb 7.9M cn.bdb 7.1M displayName.bdb 4.4M dn2id.bdb 320K employeeNumber.bdb 528K entryCSN.bdb 544K entryUUID.bdb 464K gidNumber.bdb 3.1M givenName.bdb 30M id2entry.bdb 52K ipHostNumber.bdb 8.0K ipNetworkNumber.bdb 8.0K krb5PrincipalName.bdb 44K macAddress.bdb 336K mail.bdb 120K member.bdb 132K memberUid.bdb 1.3M objectClass.bdb 16K ou.bdb 8.0K sambaDomainName.bdb 60K sambaGroupType.bdb 336K sambaPrimaryGroupSID.bdb 11M sambaSID.bdb 3.7M sn.bdb 20K st.bdb 3.7M uid.bdb 304K uidNumber.bdb 75M total > (f) Contents of your DB_CONFIG file # 100MB cache set_cachesize 0 104857600 1 # 1MB cache for tables and index file names set_lg_regionmax 1048576 # 10MB log files (> 4*set_lg_bsize) set_lg_max 10485760 # 2MB memory cache for log files set_lg_bsize 2097152 # autoremove old log files set_flags DB_LOG_AUTOREMOVE I want add more to this info, if it is relevant: checkpoint 10240 5 cachefree 1000 overlay syncprov syncprov-checkpoint 1000 5 syncprov-sessionlog 10000 Regards, Rolandas Naujikas P.S. I found myself cachesize < total number of entries. Probably I = lowered it trying to workaround this problem. > Thanks, > Quanah >=20 > -- >=20 > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by quanah＠zimbra.com 23 Nov '09

23 Nov '09

--On Monday, November 23, 2009 9:02 AM +0000 rolnas(a)gmail.com wrote: > Full_Name: Rolandas Naujikas > Version: 2.4.19 > OS: FreeBSD 7.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.147.36.211) > > > We have a setup of 3 slapd: 2 of them running in mirror mode and last one > as a read-only slave. All entries could fit in the cache (my goal is good > read performance). > > Usually when master receive only small changes (modify + several adds) - > read performance is OK. > > When I do ~5% content change (doing a lot of deletes and adds in short > period), then read performance drops sharply - on master not so much > (2x), on slaves 10-20x. In the same time CPU load on slaves when doing > read is becoming high (almost 100%), on master - normal. > > It rests in such situation until I restart slave instances, after that > all such performance problems disappears. > > By comparison version 2.4.16 didn't show such behavior and for some time > (until 2.4.19 was not declared stable) we used this older version. > Can you reproduce this behavior with current CVS checkout of the OPENLDAP_REL_ENG_2_4 branch? I'll note that the entry cache has been broken for most of RE2.4, and it is specifically fixed in CVS and will be in the upcoming 2.4.20 release. You fail to note in this ITS any of the following information, which would be useful: (a) Total number of entries in the database >From slapd.conf/cn=config: (b) cachesize (c) idlcachesize (d) dncachesize >From the BDB database: (e) output of du -c -h *.bdb in the database directory (f) Contents of your DB_CONFIG file Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6397) accesslog + syncprov crash
by h.b.furuseth＠usit.uio.no 23 Nov '09

23 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-091123.tgz Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd dumps core in test043-delta-syncrepl with this patch to excite accesslog. While I didn't expect good behavior with that change, I didn't expect a coredump either. --- tests/data/slapd-deltasync-master.conf~ 2009-04-06 17:26:37 +0200 +++ tests/data/slapd-deltasync-master.conf 2009-11-23 15:09:56 +0100 @@ -40,4 +40,5 @@ directory @TESTDIR@/db.1.b rootdn "cn=Manager,dc=example,dc=com" +index reqStart eq #bdb#index objectClass eq #bdb#index entryUUID,entryCSN eq @@ -78,4 +79,5 @@ logops writes logsuccess true +logpurge 00:00:05 00:00:03 #monitor#database monitor Happens ca every 2nd test043 run with RE24 --enable-accesslog. Output with backtrace and testrun/ attached.

1 0

(ITS#6396) slow reads on slaves after many changes in master
by rolnas＠gmail.com 23 Nov '09

23 Nov '09

Full_Name: Rolandas Naujikas Version: 2.4.19 OS: FreeBSD 7.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.147.36.211) We have a setup of 3 slapd: 2 of them running in mirror mode and last one as a read-only slave. All entries could fit in the cache (my goal is good read performance). Usually when master receive only small changes (modify + several adds) - read performance is OK. When I do ~5% content change (doing a lot of deletes and adds in short period), then read performance drops sharply - on master not so much (2x), on slaves 10-20x. In the same time CPU load on slaves when doing read is becoming high (almost 100%), on master - normal. It rests in such situation until I restart slave instances, after that all such performance problems disappears. By comparison version 2.4.16 didn't show such behavior and for some time (until 2.4.19 was not declared stable) we used this older version.

1 0

Re: (ITS#6390) test020 seg faults
by rhafer＠suse.de 23 Nov '09

23 Nov '09

Am Freitag 20 November 2009 19:45:53 schrieb quanah(a)zimbra.com: > --On Friday, November 20, 2009 3:53 PM +0000 quanah(a)zimbra.com wrote: > > --On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: > >> Hm, I get the following warning during the make run: > >> > >> =2E./../../servers/slapd/syncrepl.c:2861 is: > >> comma =3D ber_bvrchr( &ptr, ',' ); > >> with ber_bvrchr being a macro around memrchr(). So it seems that > >> memrchr() = is=20 > >> undefined in syncrepl.c. > > > > Please don't add secondary issues to an ITS. File a new one. > > Unless you're saying that is the issue, which isn't clear to me in what you > wrote. :P I thought sending my mails against this ITS would be sufficient to show that I am talking about this issue :). I'll try to make that a bit more obvious next time. -- regards, Ralf

1 0

(ITS#6395) Web site release readme needs BDB version compatibility update
by battery＠writeme.com 22 Nov '09

22 Nov '09

Full_Name: Matt Kassawara Version: 2.4.18 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.56.179.224) The release readme posted on the OpenLDAP web site doesn't explicitly indicate compatibility with BDB 4.8. http://www.openldap.org/software/release/readme.html

1 0

Re: (ITS#6300) Add kqueue support to slapd
by hyc＠symas.com 22 Nov '09

22 Nov '09

bduncan(a)apple.com wrote: > On Sep 22, 2009, at 1:02 PM, Quanah Gibson-Mount wrote: > >> --On Tuesday, September 22, 2009 7:23 PM +0000 bduncan(a)apple.com >> wrote: >> >>> Subject should have been: "PATCH - Added kqueue support to slapd" to >>> make clear this ITS tracks a patch that has been submitted. >> >> What OS(es) has this kqueue support been tested with? For example, >> the last time I looked at kqueue on OSX 10.5, it was very marginal, >> and missing most of the important pieces, which meant it wouldn't >> work for OpenLDAP or Postfix, etc. > > It was tested on OS X 10.6. Should work on all BSDs; nothing OSX- > specific about the kqueue usage in the patch. As far as kqueue > support in OS X 10.5, from what I see, most everything is there. > Certainly all of the kqueue features in this patch are supported in OS > X 10.5. To expand on this: there are a lot of comments around the web that kqueue was fairly broken at least up to 10.5. E.g. this: http://lists.schmorp.de/pipermail/libev/2008q4/000523.html Since we also use a pipe for the wake_sds[] in our event loop, if kqueue only supports sockets, then it cannot be used reliably in slapd. -- -- Howard Chu CTO, 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#6392) olcAuthIDRewrite handler exited with 1
by masarati＠aero.polimi.it 22 Nov '09

22 Nov '09

> Yeah, I noticed that hyc had patched it differently. There is > definitely a steep learning curve when it comes to helping out with > anything. > I see hyc's patch committed in the latest RE24. I have tested it with > HEAD and the error message seems to be gone. > I can't seem to get olcAuthIDRewrite to work -- but that's probably not > an ITS problem. =) Probably, yes. authzid-rewrite is used much like authz-regexp, only with a slightly different syntax. Actually, when rewriting is available, authz-regexp is handled by authzid-rewrite, using a subset of its syntax (and thus of its semantics). So its use applies when authz-regexp is appropriate. See slapd.conf(5) for usage of authz-regexp. p.

1 0

Re: (ITS#6391) missing check for broken filters
by h.b.furuseth＠usit.uio.no 22 Nov '09

22 Nov '09

masarati(a)aero.polimi.it writes: > Are you going to fix this? Probably not. -- Hallvard

1 0

Re: (ITS#6391) missing check for broken filters
by masarati＠aero.polimi.it 22 Nov '09

22 Nov '09

> syncrepl.c and overlays/pcache.c call str2filter() and str2filter_x() > without checking for success. > > (so does retcode, but that overlay is only for testing anyway.) Are you going to fix this? I can take care of it later, in case. p.

1 0

Re: (ITS#6394) syncrepl accepts rid>999 then assumes rid<=999
by hyc＠symas.com 21 Nov '09

21 Nov '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > syncrepl accepts rid values in range [0, SLAP_SYNC_SID_MAX(4095)], but > proceeds to assume the rid is in range [0, SLAP_SYNC_RID_MAX (999)]. > This can produce buffer overruns for such rids. > > slapd.conf(5) says max rid = 4095, since ITS#5108. > > Possible fixes: either to revert to a limit of 999, or expand to 4 > digits to support the documented behavior, or to make them hex to keep > the documented limit but still max 3 digits. I've opted to revert to 999. The previous behavior was completely broken anyway; aside from the syncrepl config parser all of the rest of the infrastructure was still treating rids as 3 decimal digits: the config unparser, slapd-config(5), slap_compose_sync_cookie, slap_parse_sync_cookie, etc. etc... All of these would have had to change to hex to make the 4095 limit work, and they weren't. Also, for backward compatibility with 2.3, they can't. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6394) syncrepl accepts rid>999 then assumes rid<=999
by h.b.furuseth＠usit.uio.no 21 Nov '09

21 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncrepl accepts rid values in range [0, SLAP_SYNC_SID_MAX(4095)], but proceeds to assume the rid is in range [0, SLAP_SYNC_RID_MAX (999)]. This can produce buffer overruns for such rids. slapd.conf(5) says max rid = 4095, since ITS#5108. Possible fixes: either to revert to a limit of 999, or expand to 4 digits to support the documented behavior, or to make them hex to keep the documented limit but still max 3 digits.

1 0

Re: (ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by hyc＠symas.com 21 Nov '09

21 Nov '09

michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> quanah(a)zimbra.com wrote: >>> --On Saturday, November 21, 2009 1:20 PM +0000 michael(a)stroeder.com wrote: >>> >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: openSUSE Linux 11.2 (x86_64) >>>> URL: >>>> Submission from: (NULL) (84.163.70.93) >>> As I noted yesterday, constant changes were ongoing in HEAD. >>> >>> Please re-sync your sources and try now, I think Howard's done with what he >>> was doing. >> >> My regular test process is as follows: > > Also note that this ITS is for HEAD not RE24. Thanks, got it. A prior patch to syncrepl.c broke this, testing a fix now. -- -- Howard Chu CTO, 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#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by michael＠stroeder.com 21 Nov '09

21 Nov '09

michael(a)stroeder.com wrote: > quanah(a)zimbra.com wrote: >> --On Saturday, November 21, 2009 1:20 PM +0000 michael(a)stroeder.com wrote: >> >>> Full_Name: Michael Str?der >>> Version: HEAD >>> OS: openSUSE Linux 11.2 (x86_64) >>> URL: >>> Submission from: (NULL) (84.163.70.93) >> As I noted yesterday, constant changes were ongoing in HEAD. >> >> Please re-sync your sources and try now, I think Howard's done with what he >> was doing. > > My regular test process is as follows: Also note that this ITS is for HEAD not RE24. Ciao, Michael.

1 0

Re: (ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by michael＠stroeder.com 21 Nov '09

21 Nov '09

quanah(a)zimbra.com wrote: > --On Saturday, November 21, 2009 1:20 PM +0000 michael(a)stroeder.com wrote: > >> Full_Name: Michael Str?der >> Version: HEAD >> OS: openSUSE Linux 11.2 (x86_64) >> URL: >> Submission from: (NULL) (84.163.70.93) > > As I noted yesterday, constant changes were ongoing in HEAD. > > Please re-sync your sources and try now, I think Howard's done with what he > was doing. My regular test process is as follows: 1. Whenever I test I do "cvs up" right before running the build. (And so I did after your message.) 2. Run build script and make test. 3. If anything fails during "make test" I do a "cvs up" once again and watch for changes. If there were changes I return to step 2. 4. If there were no changes I write an ITS. No more changes were present when doing "cvs up" *now*. Ciao, Michael.

1 0

Re: (ITS#6392) olcAuthIDRewrite handler exited with 1
by wgillespie＠es2eng.com 21 Nov '09

21 Nov '09

Yeah, I noticed that hyc had patched it differently. There is definitely a steep learning curve when it comes to helping out with anything. I see hyc's patch committed in the latest RE24. I have tested it with HEAD and the error message seems to be gone. I can't seem to get olcAuthIDRewrite to work -- but that's probably not an ITS problem. =) Thanks for all the help!

1 0

Re: (ITS#6392) olcAuthIDRewrite handler exited with 1
by quanah＠zimbra.com 21 Nov '09

21 Nov '09

--On Saturday, November 21, 2009 10:15 AM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Saturday, November 21, 2009 3:22 AM +0000 wgillespie(a)es2eng.com > wrote: > >> Full_Name: Willie Gillespie >> Version: 2.4.X (from CVS) >> OS: Ubuntu 9.10 x64 >> URL: >> Submission from: (NULL) (208.47.173.116) > > Please update your CVS RE24 checkout and test. Also, please be sure your patches aren't present. ;) They were not the correct solution to the issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by quanah＠zimbra.com 21 Nov '09

21 Nov '09

--On Saturday, November 21, 2009 1:20 PM +0000 michael(a)stroeder.com wrote: > Full_Name: Michael Str?der > Version: HEAD > OS: openSUSE Linux 11.2 (x86_64) > URL: > Submission from: (NULL) (84.163.70.93) As I noted yesterday, constant changes were ongoing in HEAD. Please re-sync your sources and try now, I think Howard's done with what he was doing. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6392) olcAuthIDRewrite handler exited with 1
by quanah＠zimbra.com 21 Nov '09

21 Nov '09

--On Saturday, November 21, 2009 3:22 AM +0000 wgillespie(a)es2eng.com wrote: > Full_Name: Willie Gillespie > Version: 2.4.X (from CVS) > OS: Ubuntu 9.10 x64 > URL: > Submission from: (NULL) (208.47.173.116) Please update your CVS RE24 checkout and test. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by michael＠stroeder.com 21 Nov '09

21 Nov '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.70.93) Running ./scripts/test045-syncreplication-proxied for bdb... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Starting proxy slapd on TCP/IP port 9013... Using ldapsearch to check that proxy slapd is running... 1 > Using ldapadd to populate the master directory... Waiting 7 seconds for syncrepl to receive changes... Waiting 7 seconds for syncrepl to receive changes... Waiting 7 seconds for syncrepl to receive changes... 1 < Comparing retrieved entries from master and slave... 2 > Stopping the provider, sleeping 15 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 7 seconds for syncrepl to receive changes... ldapsearch failed at slave (32)!

1 0

Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com 21 Nov '09

21 Nov '09

quanah(a)zimbra.com wrote: > --On Friday, November 20, 2009 11:29 PM +0000 michael(a)stroeder.com wrote: > >> I think this is the right issue since Howard wrote to me: >>> Your source seems to be corrupt or out of date. There is no call to >>> memrchr anywhere near line 2889 in syncrepl.c > > > This has been fixed in RE24, please try now. :) Seems to be ok now (100 test runs) Ciao, Michael.

1 0

Re: (ITS#6392)
by hyc＠symas.com 21 Nov '09

21 Nov '09

wgillespie(a)es2eng.com wrote: > I tracked down the bug by going through the source code. > Any way I can help with any of this? It's already been fixed in CVS, a few hours ago. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6392)
by wgillespie＠es2eng.com 21 Nov '09

21 Nov '09

This is a multi-part message in MIME format. --------------040503050400050604020005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Okay, so apparently it was a little easier to code than I anticipated. The supplied patch removes the error message I was seeing. Whether or not authid-rewrite actually works is a different question which I have yet to figure out. The second patch (for config.c) isn't directly related to this bug, but would be nice. I've never done a patch before, so I have no idea if I created these correctly. I used the command: diff -c oldfile newfile > file.diff Is this the proper way to do that? --------------040503050400050604020005 Content-Type: text/x-patch; name="config.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="config.c.diff" *** config.c 2009-01-21 17:00:58.000000000 -0700 --- config.c.new 2009-11-21 00:56:08.000000000 -0700 *************** *** 288,294 **** } else { Debug( LDAP_DEBUG_ANY, "[%s:%d] unknown command '%s'\n", ! fname, lineno, "" ); return -1; } --- 288,294 ---- } else { Debug( LDAP_DEBUG_ANY, "[%s:%d] unknown command '%s'\n", ! fname, lineno, argv[0] ); return -1; } --------------040503050400050604020005 Content-Type: text/x-patch; name="saslauthz.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="saslauthz.c.diff" *** saslauthz.c 2009-01-21 17:01:03.000000000 -0700 --- saslauthz.c.new 2009-11-21 00:52:15.000000000 -0700 *************** *** 1284,1289 **** --- 1284,1290 ---- ) { int rc; + int i; char *savearg0; /* init at first call */ *************** *** 1291,1300 **** sasl_rwinfo = rewrite_info_init( REWRITE_MODE_USE_DEFAULT ); } - /* strip "authid-" prefix for parsing */ savearg0 = argv[0]; argv[0] += STRLENOF( "authid-" ); rc = rewrite_parse( sasl_rwinfo, fname, lineno, argc, argv ); argv[0] = savearg0; return rc; --- 1292,1310 ---- sasl_rwinfo = rewrite_info_init( REWRITE_MODE_USE_DEFAULT ); } savearg0 = argv[0]; + /* temporarily shift argv to get rid of argv[0] */ + for ( i = 1; i <= argc; i++ ) { + argv[i-1] = argv[i]; + } + argc--; + /* strip "authid-" prefix for parsing */ argv[0] += STRLENOF( "authid-" ); rc = rewrite_parse( sasl_rwinfo, fname, lineno, argc, argv ); + argc++; + for ( i = argc; i >= 1; i-- ) { + argv[i] = argv[i-1]; + } argv[0] = savearg0; return rc; --------------040503050400050604020005--

1 0

(ITS#6392)
by wgillespie＠es2eng.com 20 Nov '09

20 Nov '09

I tracked down the bug by going through the source code. Basically, slap_sasl_rewrite_config() in servers/slapd/saslauthz.c passes the information to rewrite_parse() in libraries/librewrite/config.c. However, what slap_sasl_rewrite_config() sends is NOT what rewrite_parse() expects to get. It looks like rewrite_parse is a generic function which is called all over the place. Probably not best to mess with that. However, slap_sasl_rewrite_config() is only called from servers/slapd/bconfig.c, so any changes could take place in either of those two places relatively easily. Anyway, what slap_sasl_rewrite_config has in my little test: fname = "slapd" lineno = 0 argc = 3 argv[0] = "olcAuthIDRewrite" argv[1] = "authid-rewriteEngine" argv[2] = "on" In rewrite_parse(), it expects it to be set up more like this: fname = "slapd" lineno = 0 argc = 2 argv[0] = "rewriteEngine" argv[1] = "on" So all that needs to happen in slap_sasl_rewrite_config() is: argc--; and Get rid of argv[0] and shift everything down in the array (1 ==> 0, 2 ==> 1, etc.) (?and then put it all back when finished?) Anyway, I'm not sure how to do that, so the most I can really help out here is by filing this report so you don't have to spend your time tracking down the issue. Second note: it would have helped with debugging had a particular debug command been properly finished. See libraries/librewrite/config.c, line 289-291. The debug command has the %s placeholder for the third argument, but is passed "" instead of something more useful like: argv[0]. Probably just a little oversight. Any way I can help with any of this?

1 0

(ITS#6392) olcAuthIDRewrite handler exited with 1
by wgillespie＠es2eng.com 20 Nov '09

20 Nov '09

Full_Name: Willie Gillespie Version: 2.4.X (from CVS) OS: Ubuntu 9.10 x64 URL: Submission from: (NULL) (208.47.173.116) Modify the attribute olcAuthIDRewrite in cn=config and you get: conn=0 op=7 RESULT tag=103 err=80 text=<olcAuthIDRewrite> handler exited with 1 It seems to do this with 2.4.18 and 2.4.19 as well as the version I downloaded from the CVS tonight (2009-11-20). If others don't seem to have the same problem, I'd be happy to list more information about my setup. This is my first ITS bug, so if you need more info about something, let me know and I can provide.

1 0

Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com 20 Nov '09

20 Nov '09

--On Friday, November 20, 2009 11:29 PM +0000 michael(a)stroeder.com wrote: > I think this is the right issue since Howard wrote to me: >> Your source seems to be corrupt or out of date. There is no call to >> memrchr anywhere near line 2889 in syncrepl.c This has been fixed in RE24, please try now. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com 20 Nov '09

20 Nov '09

quanah(a)zimbra.com wrote: > --On Friday, November 20, 2009 3:53 PM +0000 quanah(a)zimbra.com wrote: > >> --On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: >> >>> Hm, I get the following warning during the make run: >>> >>> =2E./../../servers/slapd/syncrepl.c:2861 is: >>> comma =3D ber_bvrchr( &ptr, ',' ); >>> with ber_bvrchr being a macro around memrchr(). So it seems that >>> memrchr() = is=20 >>> undefined in syncrepl.c. >> >> Please don't add secondary issues to an ITS. File a new one. > > Unless you're saying that is the issue, which isn't clear to me in what you > wrote. :P I think this is the right issue since Howard wrote to me: > Your source seems to be corrupt or out of date. There is no call to memrchr > anywhere near line 2889 in syncrepl.c Ciao, Michael.

1 0

(ITS#6391) missing check for broken filters
by h.b.furuseth＠usit.uio.no 20 Nov '09

20 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncrepl.c and overlays/pcache.c call str2filter() and str2filter_x() without checking for success. (so does retcode, but that overlay is only for testing anyway.)

1 0

Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com 20 Nov '09

20 Nov '09

--On Friday, November 20, 2009 3:53 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: > >> Hm, I get the following warning during the make run: >> >> =2E./../../servers/slapd/syncrepl.c:2861 is: >> comma =3D ber_bvrchr( &ptr, ',' ); >> with ber_bvrchr being a macro around memrchr(). So it seems that >> memrchr() = is=20 >> undefined in syncrepl.c. > > > Please don't add secondary issues to an ITS. File a new one. Unless you're saying that is the issue, which isn't clear to me in what you wrote. :P --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com 20 Nov '09

20 Nov '09

--On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: > Hm, I get the following warning during the make run: > > =2E./../../servers/slapd/syncrepl.c:2861 is: > comma =3D ber_bvrchr( &ptr, ',' ); > with ber_bvrchr being a macro around memrchr(). So it seems that > memrchr() = is=20 > undefined in syncrepl.c. Please don't add secondary issues to an ITS. File a new one. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6390) test020 seg faults
by rhafer＠suse.de 20 Nov '09

20 Nov '09

Am Freitag 20 November 2009 13:34:50 schrieb Ralf Haferkamp: [..] > ../../../servers/slapd/syncrepl.c:2861 is: > comma = ber_bvrchr( &ptr, ',' ); > with ber_bvrchr being a macro around memrchr(). So it seems that memrchr() > is undefined in syncrepl.c. This got introduced by the ITS#6351 fix. I wonder if we should just revert that. The alternative is to add a #define _GNU_SOURCE 1 to ac/string.h if HAVE_MEMRCHR is defined. -- Ralf

1 0

Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com 20 Nov '09

20 Nov '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: RE24 >> OS: openSUSE Linux 11.2 (x86_64) >> URL: >> Submission from: (NULL) (84.163.84.65) >> >> >> Relevant build options: >> CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL" > > The SLAP_LIGHTWEIGHT_DISPATCHER symbol no longer exists in RE24; it was made > the default long ago. > > Why are you testing a release candidate with -DDEVEL? You have no business > defining this, not for release testing. That's for private test builds and > *un*released features; i.e. things we are specifically excluding from > consideration in the release process. I've now set export CFLAGS="-g -O2" now and it still seg faults (after 26 runs). > Your source seems to be corrupt or out of date. There is no call to memrchr > anywhere near line 2889 in syncrepl.c ??? Right before the build I'm always doing cvs up -Rd . This shows me two merges in contrib/ code where I'd tweaked the Makefile to reflect the path of the working dir. Please advice what I should do better. Ciao, Michael.

1 0

Re: (ITS#6390) test020 seg faults
by rhafer＠suse.de 20 Nov '09

20 Nov '09

Hm, I get the following warning during the make run: cc -g -O2 -I../../include -I../../../servers/slapd - I../../../servers/slapd/slapi -I. -I../../../include -c -o syncrepl.o= =20 =2E./../../servers/slapd/syncrepl.c =2E./../../servers/slapd/syncrepl.c: In function =E2=80=98syncrepl_add_glue= =E2=80=99: = =20 =2E./../../servers/slapd/syncrepl.c:2861: warning: cast to pointer from int= eger=20 of different size = =20 =2E./../../servers/slapd/syncrepl.c:2936: warning: cast to pointer from int= eger=20 of different size = =20 =2E./../../servers/slapd/syncrepl.c:2945: warning: cast to pointer from int= eger=20 of different size =2E./../../servers/slapd/syncrepl.c:2861 is: comma =3D ber_bvrchr( &ptr, ',' ); with ber_bvrchr being a macro around memrchr(). So it seems that memrchr() = is=20 undefined in syncrepl.c. Digging through the glibc headers it seems that memrchr() is hidden behind= =20 _GNU_SOURCE. Adding a #define _GNU_SOURCE 1 seems to fix the problem. At le= ast=20 the warnings go away and test020 did fail during the last 40 testruns for m= e. =2D-=20 Ralf

1 0

Re: (ITS#6390) test020 seg faults
by rhafer＠suse.de 20 Nov '09

20 Nov '09

Am Freitag 20 November 2009 00:55:06 schrieb hyc(a)symas.com: This might help: #0 0x00007f117a3f0f54 in __memrchr (s=<value optimized out>, c_in=44, n=18446604362718380092) at memrchr.c:84 char_ptr = 0x7010c82b <Address 0x7010c82b out of bounds> longword_ptr = <value optimized out> longword = <value optimized out> charmask = <value optimized out> c = 44 ',' #1 0x00000000004c484a in syncrepl_add_glue (op=0x7f1177466dd0, e=0xa12508) at ../../../servers/slapd/syncrepl.c:2861 be = 0x9cb760 cb = {sc_next = 0x0, sc_response = 0x4c6e90 <null_callback>, sc_cleanup = 0, sc_private = 0x0} a = 0x0 rc = 0 suffrdns = 2 i = 1 dn = {bv_len = 67, bv_val = 0x7f117010c7f0 "cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com"} ndn = {bv_len = 67, bv_val = 0x7f117010c840 "cn=jennifer smith,ou=alumni association,ou=people,dc=example,dc=com"} glue = 0x3000000018 rs_add = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} ptr = {bv_len = 18446604362718380092, bv_val = 0x7f117010c7f0 "cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com"} nptr = {bv_len = 139712992275168, bv_val = 0x0} comma = 0x7010c82c <Address 0x7010c82c out of bounds> __PRETTY_FUNCTION__ = "syncrepl_add_glue" #2 0x00000000005a5754 in merge_entry (op=0x7f1177466dd0, e=0xa12508, dup=0, query_uuid=0x7f117010c3e0) at ../../../../servers/slapd/overlays/pcache.c:873 rc = 32 modlist = 0x0 text = 0x0 attr = 0xa2a8b0 textbuf = "\020mFw\021\177\000\000\033JK\000\000\000\000\000\376\003\000\000\000\000\000\000\260\215Fw\021\177\000\000 nFw\001\000\000\000\000\000\020\000\000\000\000\000\340\r\000p\021\177\000\000\340\r\000p\021\177\000\000\020\231Fw\021\177\000\000\a\000\000\000\021\177\000\000\377\377\377\377\377\377\377\377\377\377\377\377\021\177\000\000\360lFw\021\177\000\000r\000`\377\377\377\377\377\020mFw\021\177", '\000' <repeats 18 times>, "\020\231Fw\021\177\000\000 mFw\021\177\000\000!\004`\377\377\377\377\377i{\006K\000\000\000\000PtFw\021\177", '\000' <repeats 18 times>, "PmFw\021\177\000\000\300L\211\000\000\000\000\000PmFw\021\177\000\000:\320E\000\000\000\000\000\350mFw\021\177\000\000\340mFw\021\177\000\000\240mFw\021\177\000\000\247ID\000\000\000\000" textlen = 256 sreply = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 0, sr_err = 32, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0x457438 <slap_null_cb>, sc_cleanup = 0, sc_private = 0x0} #3 0x00000000005a977c in cache_entries (op=0x7f11700008b0, rs=0x7f1177468c80, query_uuid=0x7f117010c3e0) at ../../../../servers/slapd/overlays/pcache.c:2291 si = 0x7f1170001268 on = 0x9cb580 cm = 0x9cb760 return_val = 0 e = 0xa12508 crp_uuid = {bv_len = 17, bv_val = 0x7f1170001050 "dc=example,dc=com"} uuidbuf = "685decf2-6a12-102e-8d88-29e65eca5b5f\000\000\000" op_tmp = 0x7f1177466dd0 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x5f22a0 ""}, c_peer_name = {bv_len = 0, bv_val = 0x5f22a0 ""}, c_listener = 0x5f9e60, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x458a5b <slap_send_ldap_result>, c_send_search_entry = 0x45971e <slap_send_search_entry>, c_send_search_reference = 0x45b9e0 <slap_send_search_reference>, c_send_ldap_extended = 0x4592ab <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x459512 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f1177466f40, o_tag = 104, o_time = 1258716009, o_tincr = 12, o_bd = 0x9cb760, o_req_dn = {bv_len = 67, bv_val = 0x7f117010c7f0 "cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com"}, o_req_ndn = {bv_len = 67, bv_val = 0x7f117010c840 "cn=jennifer smith,ou=alumni association,ou=people,dc=example,dc=com"}, o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0xa12508}, oq_bind = { rb_method = 0, rb_cred = {bv_len = 10560776, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = { rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 8 '\b'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 8 '\b'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 10560776, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0xa12508 ""}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0xa12508 ""}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7f1177467088, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 17, bv_val = 0x9cae70 "dc=example,dc=com"}, sai_ndn = {bv_len = 17, bv_val = 0x9e9af0 "dc=example,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f1177466b40, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = { slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7f1177467190, oh_msgid = 0, oh_protocol = 3, oh_tid = 139712992286992, oh_threadctx = 0x7f1177468db0, oh_tmpmemctx = 0x7f1170000de0, oh_tmpmfuncs = 0x88c8c0, oh_counters = 0x90f060, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} thrctx = 0x7f1177468db0 #4 0x00000000005a9d88 in pcache_op_cleanup (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../../servers/slapd/overlays/pcache.c:2397 qc = 0x7f117010c3c0 cb = 0x7f1170001248 si = 0x7f1170001268 on = 0x9cb580 cm = 0x9cb760 qm = 0x9f0380 __PRETTY_FUNCTION__ = "pcache_op_cleanup" #5 0x0000000000457ee0 in slap_cleanup_play (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/result.c:392 sc_next = 0x0 sc_nextp = 0x7f1170001248 sc = 0x7f1177467980 scp = 0x7f1177467980 #6 0x000000000045868b in send_ldap_response (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/result.c:577 berbuf = { buffer = "\000\000\001\000\005\001\000\000\377\377\377\377\377\377\377\377", '\000' <repeats 24 times>"\366, \022\000p\021\177\000\000\304\"\000p\021\177\000\000\000\000\000\000\000\000\000\000\366\022\000p\021\177\000\000\340\r\000p\021\177\000\000pvFw\021\177\000\000\000\000\000\000\000\000\000\000\020\231Fw\021\177\000\000 \000\000p\021\177\000\000\220vFw\021\177\000\000\000\000\000\000\000\000\000\000\020\231Fw\021\177\000\000 \000\000p\021\177\000\000\260vFw\021\177\000\000\000\000\000\000\000\000\000\000\r\311_\000\000\000\000\000\r\311_\000\000\000\000\000\003\000\000\000\000\000\000\000l9>z\021\177\000\000h. \020p\021\177\000\000\071;i|\021\177\000\000\000\000\000\000\000\000\000\000\260\304\020p\021\177\000\000\340vFw\021\177\000\000_\035\213|"..., ialign = 65536, lalign = 1120986529792, falign = 9.18354962e-41, dalign = 5.5384093382102224e-312, palign = 0x10500010000 <Address 0x10500010000 out of bounds>} ber = 0x7f11774675d0 rc = 32768 bytes = 14 __PRETTY_FUNCTION__ = "send_ldap_response" #7 0x0000000000458e70 in slap_send_ldap_result (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/result.c:706 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #8 0x0000000000504d09 in ldap_back_search (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../../servers/slapd/back-ldap/search.c:575 li = 0x9ca1a0 lc = 0x7f1170102c70 tv = {tv_sec = 0, tv_usec = 100000} stoptime = 1258719609 res = 0x7f117010c4b0 e = 0x7f117010c4b0 rc = 0 msgid = 2 match = {bv_len = 0, bv_val = 0x0} filter = {bv_len = 11, bv_val = 0x7f1170001100 "(sn=smith*)"} i = 5 attrs = 0x7f1170102fb0 freetext = 0 freefilter = 0 do_retry = 0 dont_retry = 1 ctrls = 0x0 references = 0x0 save_matched = 0x0 __PRETTY_FUNCTION__ = "ldap_back_search" #9 0x00000000004d0821 in overlay_op_walk (op=0x7f11700008b0, rs=0x7f1177468c80, which=op_search, oi=0x9cb3a0, on=0x0) at ../../../servers/slapd/backover.c:669 func = 0x8877c8 rc = 32768 #10 0x00000000004d0a38 in over_op_func (op=0x7f11700008b0, rs=0x7f1177468c80, which=op_search) at ../../../servers/slapd/backover.c:721 oi = 0x9cb3a0 on = 0x9cb580 be = 0x9ca010 db = {bd_info = 0x887770, bd_self = 0x9ca010, be_ctrls = "\000", '\001' <repeats 23 times>, "\000\000\000\000\000\000\000\000\001", be_flags = 257, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x9cae10, be_nsuffix = 0x9cae40, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 17, bv_val = 0x9cae70 "dc=example,dc=com"}, be_rootndn = {bv_len = 17, bv_val = 0x9e9af0 "dc=example,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x9cad70 "secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x9caf30, be_acl = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xa6ffe0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x88fc80, be_private = 0x9ca1a0, be_next = { stqe_next = 0x9f2140}} cb = {sc_next = 0x7f1170001248, sc_response = 0x4cf7ca <over_back_response>, sc_cleanup = 0, sc_private = 0x9cb3a0} sc = 0x7f1177468c80 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #11 0x00000000004d0b20 in over_op_search (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/backover.c:748 No locals. #12 0x0000000000446014 in fe_op_search (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/search.c:366 bd = 0x8975a0 #13 0x00000000004458b9 in do_search (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/search.c:217 base = {bv_len = 17, bv_val = 0x7f1170102be7 "dc=example,dc=com"} siz = 3 off = 0 i = 3 #14 0x00000000004422f2 in connection_operation (ctx=0x7f1177468db0, arg_v=0x7f11700008b0) at ../../../servers/slapd/connection.c:1109 rc = 80 cancel = 15 op = 0x7f11700008b0 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x7f1170001198, r_nentries = 1, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7f1178550950 memctx = 0x7f1170000de0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #15 0x0000000000442893 in connection_read_thread (ctx=0x7f1177468db0, argv=0xf) at ../../../servers/slapd/connection.c:1245 rc = 0 cri = {op = 0x7f11700008b0, func = 0, arg = 0x0, ctx = 0x7f1177468db0, nullop = 0} s = 15 #16 0x00007f117c8ad279 in ldap_int_thread_pool_wrapper (xpool=0x93e820) at ../../../libraries/libldap_r/tpool.c:685 pool = 0x93e820 task = 0xba6dc0 work_list = 0x93e8b8 ctx = {ltu_id = 139712992286992, ltu_key = {{ltk_key = 0x441e43, ltk_data = 0x7f1170000cd0, ltk_free = 0x441c87 <conn_counter_destroy>}, {ltk_key = 0x4b499a, ltk_data = 0x7f1170000de0, ltk_free = 0x4b477c <slap_sl_mem_destroy>}, {ltk_key = 0x45cda5, ltk_data = 0x0, ltk_free = 0x45ccf8 <slap_op_q_destroy>}, {ltk_key = 0xa70020, ltk_data = 0x7f117010b130, ltk_free = 0x52c79e <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = 0x0 i = 32 keyslot = 662 hash = 1674836630 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #17 0x00007f117b73865d in start_thread (arg=<value optimized out>) at pthread_create.c:297 __res = <value optimized out> pd = 0x7f1177469910 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139712992286992, 3546025110985141157, 139713009061584, 139712992286992, 139713085272128, 3, -3524931473729492059, -3524922222741001307}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <value optimized out> robust = <value optimized out> #18 0x00007f117a43d14d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 No locals. #19 0x0000000000000000 in ?? () No symbol table info available.

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 19 Nov '09

19 Nov '09

Peter Palmreuther wrote: > <hyc(a)symas.com> wrote: >> Peter Palmreuther wrote: >>> <hyc(a)symas.com> wrote: > [...[ >>>> Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be >>>> testing the RE24 code now, not 2.4.19.) >>> [...] ran several thousand test iterations without a single failure yet. [...] >>> Is this fix "back-portable" to 2.4.19 source, so I can compile a >>> 2.4.19-custom version??? [...] >> >> The patch will be in 2.4.20, which will be released soon. > > Thanks a lot :-) > > Just for the record, so I can > - close this case internally, and > - justify the upcoming upgrade toward our change and release management: > > What was the problem? The second server sending back received synced > operations or the first server processing those "send backs"? Both. The consumer was sending the wrong SID to the provider, so the provider's checks to prevent "send backs" wasn't catching it. Also the provider's checks were being bypassed on Modify operations, so the modified entry would be sent back and recreated after it was deleted. I've added a sequence of repeated add-modify-deletes to test050 to make sure we don't regress on this in the future. > Or was > it just "some pixie dust" on the WLAN cable? ;-) -- -- Howard Chu CTO, 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#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 19 Nov '09

19 Nov '09

<hyc(a)symas.com> wrote: > Peter Palmreuther wrote: >> <hyc(a)symas.com> wrote: [...[ >>> Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be >>> testing the RE24 code now, not 2.4.19.) >> [...] ran several thousand test iterations without a single failure yet. [...] >> Is this fix "back-portable" to 2.4.19 source, so I can compile a >> 2.4.19-custom version??? [...] > > The patch will be in 2.4.20, which will be released soon. Thanks a lot :-) Just for the record, so I can - close this case internally, and - justify the upcoming upgrade toward our change and release management: What was the problem? The second server sending back received synced operations or the first server processing those "send backs"? Or was it just "some pixie dust" on the WLAN cable? ;-) -- Regards, Peter

1 0

Re: (ITS#6390) test020 seg faults
by hyc＠symas.com 19 Nov '09

19 Nov '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: openSUSE Linux 11.2 (x86_64) > URL: > Submission from: (NULL) (84.163.84.65) > > > Relevant build options: > CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL" The SLAP_LIGHTWEIGHT_DISPATCHER symbol no longer exists in RE24; it was made the default long ago. Why are you testing a release candidate with -DDEVEL? You have no business defining this, not for release testing. That's for private test builds and *un*released features; i.e. things we are specifically excluding from consideration in the release process. You're still missing the majority of symbols in this trace. > Core was generated by > `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/.libs/lt-'. > Program terminated with signal 11, Segmentation fault. > #0 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 > Thread 1 (Thread 20194): > #0 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 > #1 0x000000000048e304 in syncrepl_add_glue (op=0x2b469b681e10, e=0x817aa8) at > syncrepl.c:2889 Your source seems to be corrupt or out of date. There is no call to memrchr anywhere near line 2889 in syncrepl.c > #2 0x00002b4697aa4b93 in ?? () > #3 0x00002b469b682024 in ?? () > #4 0x00002b469b681d2f in ?? () > #5 0x00002b46ffffffff in ?? () > #6 0x00002b469b683c20 in ?? () > #7 0x00002b469b682490 in ?? () > #8 0x00002b469505e460 in ?? () from /lib64/libc.so.6 > #9 0x0000000000000000 in ?? () Try to get a consistent build first... -- -- Howard Chu CTO, 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#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 19 Nov '09

19 Nov '09

Peter Palmreuther wrote: > <hyc(a)symas.com> wrote: >> Peter Palmreuther wrote: >>> Sorry, misconfiguration on my side when I replicated the real setup at my home server. >>> I'fe corrected configuration and rerun test. >> >> Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be >> testing the RE24 code now, not 2.4.19.) > > I've checked out HEAD from CVSROOT > ':pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP' and ran several > thousand test iterations without a single failure yet. > So I'd guess it seems to be fixed. > > How to continue best, getting a version ready for production? I > hesitate to simply compile HEAD for productive use, as I can't make > sure there's no change between latest stable / release and HEAD that > could lead to other trouble ... > Is this fix "back-portable" to 2.4.19 source, so I can compile a > 2.4.19-custom version??? > > Thanks in advance, The patch will be in 2.4.20, which will be released soon. -- -- Howard Chu CTO, 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#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 19 Nov '09

19 Nov '09

<hyc(a)symas.com> wrote: > Peter Palmreuther wrote: >> Sorry, misconfiguration on my side when I replicated the real setup at my home server. >> I'fe corrected configuration and rerun test. > > Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be > testing the RE24 code now, not 2.4.19.) I've checked out HEAD from CVSROOT ':pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP' and ran several thousand test iterations without a single failure yet. So I'd guess it seems to be fixed. How to continue best, getting a version ready for production? I hesitate to simply compile HEAD for productive use, as I can't make sure there's no change between latest stable / release and HEAD that could lead to other trouble ... Is this fix "back-portable" to 2.4.19 source, so I can compile a 2.4.19-custom version??? Thanks in advance, -- Regards, Peter

1 0

(ITS#6390) test020 seg faults
by michael＠stroeder.com 19 Nov '09

19 Nov '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.84.65) Relevant build options: CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL" $ gcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.4 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux) Core was generated by `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/.libs/lt-'. Program terminated with signal 11, Segmentation fault. #0 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 (gdb) info threads 9 Thread 20130 0x00002b4694de831e in ?? () from /lib64/libc.so.6 8 Thread 20146 0x00002b4694de831e in ?? () from /lib64/libc.so.6 7 Thread 20083 0x00002b4694de831e in ?? () from /lib64/libc.so.6 6 Thread 20162 0x00002b4694dd4712 in select () from /lib64/libc.so.6 5 Thread 20082 0x00002b4694ddb7f8 in epoll_wait () from /lib64/libc.so.6 4 Thread 20240 0x00002b4693888049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 20067 0x00002b469388496d in pthread_join () from /lib64/libpthread.so.0 2 Thread 20178 0x00002b4694dcde7b in write () from /lib64/libc.so.6 * 1 Thread 20194 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 9 (Thread 20130): #0 0x00002b4694de831e in ?? () from /lib64/libc.so.6 #1 0x00002b4694d6e058 in ?? () from /lib64/libc.so.6 #2 0x00002b4694d6df32 in fputs () from /lib64/libc.so.6 #3 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #4 0x00002b4697431988 in ?? () #5 0x0000000000aa1470 in ?? () #6 0x00002b469967d730 in ?? () #7 0x00002b469967d7c0 in ?? () #8 0x00002b469967d640 in ?? () #9 0x000000000099753a in ?? () #10 0x09802b469967d6f0 in ?? () #11 0x0000000000997538 in ?? () #12 0x000000240000001e in ?? () #13 0x0000000000000024 in ?? () #14 0x0000000000000000 in ?? () Thread 8 (Thread 20146): #0 0x00002b4694de831e in ?? () from /lib64/libc.so.6 #1 0x00002b4694d6e058 in ?? () from /lib64/libc.so.6 #2 0x00002b4694d6df32 in fputs () from /lib64/libc.so.6 #3 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #4 0x00002b4697431988 in ?? () #5 0x0000000000bad820 in ?? () #6 0x00002b4699e7e730 in ?? () #7 0x00002b4699e7e7c0 in ?? () #8 0x00002b4699e7e640 in ?? () #9 0x0000000000aa2812 in ?? () #10 0x09802b4699e7e6f0 in ?? () #11 0x0000000000aa2810 in ?? () #12 0x000000240000001e in ?? () #13 0x0000000000000024 in ?? () #14 0x0000000000000000 in ?? () Thread 7 (Thread 20083): #0 0x00002b4694de831e in ?? () from /lib64/libc.so.6 #1 0x00002b4694d6e058 in ?? () from /lib64/libc.so.6 #2 0x00002b4694d6df32 in fputs () from /lib64/libc.so.6 #3 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #4 0x00002b4697430565 in ?? () #5 0x0000000000000000 in ?? () Thread 6 (Thread 20162): #0 0x00002b4694dd4712 in select () from /lib64/libc.so.6 #1 0x00002b4697430353 in ?? () #2 0x0000000000000000 in ?? () Thread 5 (Thread 20082): #0 0x00002b4694ddb7f8 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042ffd3 in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2642 #2 0x00002b469388365d in start_thread () from /lib64/libpthread.so.0 #3 0x00002b4694ddb14d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () ---Type <return> to continue, or q <return> to quit--- Thread 4 (Thread 20240): #0 0x00002b4693888049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b4692c72f85 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:672 #2 0x00002b469388365d in start_thread () from /lib64/libpthread.so.0 #3 0x00002b4694ddb14d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 3 (Thread 20067): #0 0x00002b469388496d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042d04c in slapd_set_write (s=<value optimized out>, wake=0) at daemon.c:962 #2 0x000000000041af37 in cfAddOverlay (p=0x2b469867e9e0, e=0x0, ca=0x4e72) at bconfig.c:4579 #3 0x0000000000000000 in ?? () Thread 2 (Thread 20178): #0 0x00002b4694dcde7b in write () from /lib64/libc.so.6 #1 0x00002b4694d78c53 in _IO_file_write () from /lib64/libc.so.6 #2 0x00002b4694d788ca in ?? () from /lib64/libc.so.6 #3 0x00002b4694d78bbe in _IO_file_xsputn () from /lib64/libc.so.6 #4 0x00002b4694d6df73 in fputs () from /lib64/libc.so.6 #5 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #6 0x00002b4697420e45 in ?? () #7 0x00002b469ae80b50 in ?? () #8 0x00002b469ae808f0 in ?? () #9 0x0000000000000100 in ?? () #10 0x0000000000000000 in ?? () Thread 1 (Thread 20194): #0 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 #1 0x000000000048e304 in syncrepl_add_glue (op=0x2b469b681e10, e=0x817aa8) at syncrepl.c:2889 #2 0x00002b4697aa4b93 in ?? () #3 0x00002b469b682024 in ?? () #4 0x00002b469b681d2f in ?? () #5 0x00002b46ffffffff in ?? () #6 0x00002b469b683c20 in ?? () #7 0x00002b469b682490 in ?? () #8 0x00002b469505e460 in ?? () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? ()

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 19 Nov '09

19 Nov '09

Peter Palmreuther wrote: > Sorry, misconfiguration on my side when I replicated the real setup at my home server. > I'fe corrected configuration and rerun test. Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be testing the RE24 code now, not 2.4.19.) > 'debug-03' is put on known URL, server configuration is > > , [ server #1 {egrep -v '^(#|\s*$)' slapd.conf} ] > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/openldap.schema > include /usr/local/etc/openldap/schema/java.schema > include /usr/local/etc/openldap/schema/samba.schema > include /usr/local/etc/openldap/schema/nis.schema > include /usr/local/etc/openldap/schema/dhcp.schema > pidfile /home/pit/esolution/ldap1/run/slapd.pid > argsfile /home/pit/esolution/ldap1/run/slapd.args > modulepath /usr/local/libexec/openldap > moduleload back_bdb > moduleload back_monitor > moduleload back_hdb > access to dn.subtree="o=esolution,dc=deutscherv,dc=de" > by dn.exact="cn=Admin,o=esolution,dc=deutscherv,dc=de" manage > by dn.exact="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" read > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous auth > access to dn.subtree="dc=deutscherv,dc=de" > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous auth > access to * > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by self write > by users read > by anonymous auth > database hdb > suffix "dc=deutscherv,dc=de" > directory /home/pit/esolution/ldap1/data/deutscherv.de > rootdn "cn=Admin,dc=deutscherv,dc=de" > rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl > index objectClass eq > index entryUUID eq > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > syncrepl rid=001 > provider=ldap://localhost:11389 > type=refreshAndPersist > searchbase="o=esolution,dc=deutscherv,dc=de" > schemachecking=on > bindmethod=simple > binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" > credentials="M1rr0rM3" > retry="5 +" > serverID 1 > mirrormode on > database monitor > ` > > , [ server #2 {egrep -v '^(#|\s*$)' slapd.conf} ] > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/openldap.schema > include /usr/local/etc/openldap/schema/java.schema > include /usr/local/etc/openldap/schema/samba.schema > include /usr/local/etc/openldap/schema/nis.schema > include /usr/local/etc/openldap/schema/dhcp.schema > pidfile /home/pit/esolution/ldap2/run/slapd.pid > argsfile /home/pit/esolution/ldap2/run/slapd.args > modulepath /usr/local/libexec/openldap > moduleload back_bdb > moduleload back_monitor > moduleload back_hdb > access to dn.subtree="o=esolution,dc=deutscherv,dc=de" > by dn.exact="cn=Admin,o=esolution,dc=deutscherv,dc=de" manage > by dn.exact="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" read > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous read > access to dn.subtree="dc=deutscherv,dc=de" > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous read > access to * > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by self write > by users read > by anonymous auth > database hdb > suffix "dc=deutscherv,dc=de" > directory /home/pit/esolution/ldap2/data/deutscherv.de > rootdn "cn=Admin,dc=deutscherv,dc=de" > rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl > index objectClass eq > index entryUUID eq > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > syncrepl rid=001 > provider=ldap://localhost:10389 > type=refreshAndPersist > searchbase="o=esolution,dc=deutscherv,dc=de" > schemachecking=on > bindmethod=simple > binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" > credentials="M1rr0rM3" > retry="5 +" > serverID 2 > mirrormode on > database monitor > ` -- -- Howard Chu CTO, 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#6389) Allow setting syncrepl keepalive
by hyc＠symas.com 19 Nov '09

19 Nov '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> This is low priority. Few platforms provide support for >> process/socket-specific keepalive settings. Usually you just set it >> system-wide in the kernel. (Note that a single setting is insufficient, there >> are 3 parameters that need to be set in concert.) > > I suggest moving this info into the slap_bindconf structure, to allow > its exploitation anywhere connections need to be set up, and defining a > syntax like keepalive="[<idle>]:[<probe>]:[<intervals>]". An empty > value would mean use the default. Sounds OK. Ultimately we should consider moving syncrepl into its own config entry. Perhaps for 2.5. Not sure if that affects slap_bindconf or not; that still seems to be useful in its current form. -- -- Howard Chu CTO, 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#6389) Allow setting syncrepl keepalive
by masarati＠aero.polimi.it 19 Nov '09

19 Nov '09

hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.19 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.131.62.113) > >> When configuring a replica using syncrepl, it should be possible to have an >> option that sets the keepalive used for the tcp connection between the replica >> and master. Support for this was added to libldap, but no corresponding support >> was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for >> configuring this, based in seconds. > > This is low priority. Few platforms provide support for > process/socket-specific keepalive settings. Usually you just set it > system-wide in the kernel. (Note that a single setting is insufficient, there > are 3 parameters that need to be set in concert.) I suggest moving this info into the slap_bindconf structure, to allow its exploitation anywhere connections need to be set up, and defining a syntax like keepalive="[<idle>]:[<probe>]:[<intervals>]". An empty value would mean use the default. p.

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 19 Nov '09

19 Nov '09

hyc(a)symas.com wrote: > Peter Palmreuther wrote: >> I modified slapd.conf to contain 'retry=3D"5 +"' instead of a 60 = second >> timeout. >>=20 >> I started both servers and checked "do_syncrepl" in server #1 was = followed >> by log information stating it connected to server #2. >>=20 >> I then rerun the test and this time it did not that much iterations, = but >> failed during the first run (with each run being 100 round of "add, = mod, >> delete"). >>=20 >> The URL with new log output is still the same, it's the = "debug-02.tar.*" >> files. >=20 > In both the new and old logs, the 2nd server is sending updates back = to the > first server. This can only happen if the serverID is misconfigured. = Please > post your slapd configs for both servers. Sorry, misconfiguration on my side when I replicated the real setup at = my home server. I'fe corrected configuration and rerun test. 'debug-03' is put on known URL, server configuration is ,=97=97=97=97=97 [ server #1 {egrep -v '^(#|\s*$)' slapd.conf} ] = =97=97=97=97=97=97=97=97=97 include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/dhcp.schema pidfile /home/pit/esolution/ldap1/run/slapd.pid argsfile /home/pit/esolution/ldap1/run/slapd.args modulepath /usr/local/libexec/openldap moduleload back_bdb moduleload back_monitor moduleload back_hdb access to dn.subtree=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,o=3Desolution,dc=3Ddeutscherv,dc=3Dde" = manage by dn.exact=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc=3D= de" read by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous auth access to dn.subtree=3D"dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous auth access to * by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by self write by users read by anonymous auth database hdb suffix "dc=3Ddeutscherv,dc=3Dde" directory /home/pit/esolution/ldap1/data/deutscherv.de rootdn "cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl index objectClass eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=3D001 provider=3Dldap://localhost:11389 type=3DrefreshAndPersist searchbase=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" schemachecking=3Don bindmethod=3Dsimple binddn=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc= =3Dde" credentials=3D"M1rr0rM3" retry=3D"5 +" serverID 1 mirrormode on database monitor `=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97 ,=97=97=97=97=97 [ server #2 {egrep -v '^(#|\s*$)' slapd.conf} ] = =97=97=97=97=97=97=97=97=97 include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/dhcp.schema pidfile /home/pit/esolution/ldap2/run/slapd.pid argsfile /home/pit/esolution/ldap2/run/slapd.args modulepath /usr/local/libexec/openldap moduleload back_bdb moduleload back_monitor moduleload back_hdb access to dn.subtree=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,o=3Desolution,dc=3Ddeutscherv,dc=3Dde" = manage by dn.exact=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc=3D= de" read by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous read access to dn.subtree=3D"dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous read access to * by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by self write by users read by anonymous auth database hdb suffix "dc=3Ddeutscherv,dc=3Dde" directory /home/pit/esolution/ldap2/data/deutscherv.de rootdn "cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl index objectClass eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=3D001 provider=3Dldap://localhost:10389 type=3DrefreshAndPersist searchbase=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" schemachecking=3Don bindmethod=3Dsimple binddn=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc= =3Dde" credentials=3D"M1rr0rM3" retry=3D"5 +" serverID 2 mirrormode on database monitor `=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97 --=20 Regards, Peter.=

1 0

Re: (ITS#6389) Allow setting syncrepl keepalive
by hyc＠symas.com 18 Nov '09

18 Nov '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.19 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.131.62.113) > When configuring a replica using syncrepl, it should be possible to have an > option that sets the keepalive used for the tcp connection between the replica > and master. Support for this was added to libldap, but no corresponding support > was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for > configuring this, based in seconds. This is low priority. Few platforms provide support for process/socket-specific keepalive settings. Usually you just set it system-wide in the kernel. (Note that a single setting is insufficient, there are 3 parameters that need to be set in concert.) -- -- Howard Chu CTO, 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#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 18 Nov '09

18 Nov '09

Peter Palmreuther wrote: > I modified slapd.conf to contain 'retry="5 +"' instead of a 60 second > timeout. > > I started both servers and checked "do_syncrepl" in server #1 was followed > by log information stating it connected to server #2. > > I then rerun the test and this time it did not that much iterations, but > failed during the first run (with each run being 100 round of "add, mod, > delete"). > > The URL with new log output is still the same, it's the "debug-02.tar.*" > files. In both the new and old logs, the 2nd server is sending updates back to the first server. This can only happen if the serverID is misconfigured. Please post your slapd configs for both servers. -- -- Howard Chu CTO, 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 18 Nov '09

18 Nov '09

CVS HEAD, including the two changes related to assertions (the change = log references ITS#6361), may fix this issue. I have been running the = new slapd for over 24 hours with no problems. This is much longer than = slapd would run for me before the new code.=

1 0

Re: (ITS#6166) Overlay/backend restructuring
by hyc＠symas.com 18 Nov '09

18 Nov '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE25/RE30 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Some wishes/loose thoughts about overlay/backend code: > > * Remove backends internally, making them like overlays? (RE30) > * Reduce copying of overlay data -op->o_bd->bd_info (RE25?) > * Lose slap_overinst, move its members into BackendInfo. * Re-factor Bind response handling to behave the same as every other request. (Instead of always deferring SUCCESS result to the frontend.) * Likewise for Extops. -- -- Howard Chu CTO, 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#6387) Valgrind reports issues in pcache
by hyc＠symas.com 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD,re24,2.4.19 > OS: irrelevant? > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.146) > Submitted by: ando > > > See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> Leaks are now fixed in HEAD. -- -- Howard Chu CTO, 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#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 18 Nov '09

18 Nov '09

hyc(a)symas.com wrote: > pitpalme+openldap(a)gmail.com wrote: >> [...] >> The logs are available here: >>=20 >> <url:http://pitpalme.is-a-geek.net/ldap/> >> [...] >=20 > The log shows that the problem is because the two servers are not = synchronized > before you begin your test. If you search for "do_syncrep" in the = ldap1 log, > you'll see that it was unable to connect to its provider at the very = beginning > of the file. It doesn't successfully connect until much later, 97% of = the way > down in the log file, after the majority of your testing has already = been > running. That delay is based on your syncrepl retry setting. Thanks for your analyses. I understand the servers were not immediately = synchronising, when I started to test. But the servers *were* = synchronized before the test started. I copied data directory of server = #1 to server #2, so they contained the very identical information. > When it finally connects it sends a somewhat out of date cookie to the = peer > server, and so it starts receiving results back. You get the "already = exists" > error because the entry you're trying to add has just been added by = syncrepl > itself. OK. > Part of the problem is the out-of-date cookie; the consumer checks = with > syncprov to make sure it has an up-to-date cookie but obviously in = your case > the cookie continues to change since you're still making changes to = the DB. > You can avoid this issue by making sure both servers' consumers are = connected > before performing any write ops, and you can assist in that by using a = faster > initial retry time in your syncrepl config. I modified slapd.conf to contain 'retry=3D"5 +"' instead of a 60 second = timeout. I started both servers and checked "do_syncrepl" in server #1 was = followed by log information stating it connected to server #2. I then rerun the test and this time it did not that much iterations, but = failed during the first run (with each run being 100 round of "add, mod, = delete"). The URL with new log output is still the same, it's the "debug-02.tar.*" = files. Thanks in advance. Regards, Peter=

1 0

(ITS#6389) Allow setting syncrepl keepalive
by quanah＠zimbra.com 18 Nov '09

18 Nov '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.131.62.113) When configuring a replica using syncrepl, it should be possible to have an option that sets the keepalive used for the tcp connection between the replica and master. Support for this was added to libldap, but no corresponding support was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for configuring this, based in seconds.

1 0

Re: ITS#6290 dynamic group documentation
by gavin.henry＠gmail.com 18 Nov '09

18 Nov '09

Thanks all. Will fix next week. On 16/11/2009, jonathan(a)phillipoux.net <jonathan(a)phillipoux.net> wrote: > This is a multi-part message in MIME format. > --------------060504090007030105050009 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > On 16/11/2009 03:30, hyc(a)symas.com wrote: >> Yeah, the example should have used groupOfURLs instead of groupOfNames. >> Notice >> that "member" is not a valid attribute in the groupOfURLs class: it can >> not be >> used to store static members, only dynamic references. > > Quick patch to fix this attached. Note that the PNG image in > admin/allusersgroup-en.png needs to be regenerated from source SVG - the > PNG is also attached. > > -- > -------------------------------------------------------------- > Jonathan Clarke - jonathan(a)phillipoux.net > -------------------------------------------------------------- > Ldap Synchronization Connector (LSC) - http://lsc-project.org > -------------------------------------------------------------- > > --------------060504090007030105050009 > Content-Type: text/x-diff; > name="admin-guide-its-6290.patch" > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename="admin-guide-its-6290.patch" > > Index: images/src/allusersgroup-en.svg > =================================================================== > RCS file: > /repo/OpenLDAP/pkg/openldap-guide/images/src/allusersgroup-en.svg,v > retrieving revision 1.1 > diff -u -p -u -r1.1 allusersgroup-en.svg > --- images/src/allusersgroup-en.svg 7 Nov 2007 22:52:55 -0000 1.1 > +++ images/src/allusersgroup-en.svg 16 Nov 2009 10:15:30 -0000 > @@ -106,7 +106,7 @@ > y="78.033184" > id="tspan5379">objectClass: <tspan > style="font-weight:bold" > - id="tspan5396">groupOfNames</tspan></tspan><tspan > + id="tspan5396">groupOfURLs</tspan></tspan><tspan > sodipodi:role="line" > x="116.88309" > y="92.036435" > Index: admin/overlays.sdf > =================================================================== > RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/overlays.sdf,v > retrieving revision 1.46 > diff -u -p -u -r1.46 overlays.sdf > --- admin/overlays.sdf 19 Aug 2009 17:23:43 -0000 1.46 > +++ admin/overlays.sdf 16 Nov 2009 10:15:31 -0000 > @@ -551,18 +551,23 @@ directory. > > In {{F:slapd.conf}}(5): > > +> include /path/to/dyngroup.schema > +> ... > > overlay dynlist > -> dynlist-attrset groupOfNames labeledURI member > +> dynlist-attrset groupOfURLs labeledURI member > + > +Note that we must include the {{F:dyngroup.schema}} file that defines the > +{{F:groupOfURLs}} objectClass used in this example. > > Let's apply it to the following entry: > > > cn=allusers,ou=group,dc=example,dc=com > > cn: all > -> objectClass: groupOfNames > +> objectClass: groupOfURLs > > labeledURI: > ldap:///ou=people,dc=example,dc=com??one?(objectClass=inetOrgPerson) > > The behavior is similar to the dynamic list configuration we had before: > -whenever an entry with the {{F:groupOfNames}} object class is retrieved, > the > +whenever an entry with the {{F:groupOfURLs}} object class is retrieved, the > search specified in the {{F:labeledURI}} attribute is performed. But this > time, > only the distinguished names of the results are added, and as values of the > {{F:member}} attribute. > Index: admin/allusersgroup-en.png > =================================================================== > RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/allusersgroup-en.png,v > retrieving revision 1.1 > diff -u -p -u -r1.1 allusersgroup-en.png > Binary files /tmp/cvsEkGNLJ and allusersgroup-en.png differ > > --------------060504090007030105050009 > Content-Type: image/png; > name="allusersgroup-en.png" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; > filename="allusersgroup-en.png" > > iVBORw0KGgoAAAANSUhEUgAAAaMAAABsCAYAAADHXN0hAAAABHNCSVQICAgIfAhkiAAAIABJ > REFUeJztnXecFEX2wL87s5HdZZe4JIkCKmIigyhggMPjlKAIKEbEAKbzPL3g6ZnwZzgVFRUV > 9cSAopJEPZKCZMlIhiUvcQPLApvm98frdnp6e7p7dnd2dqG+n898dru7pqr6dU29rqpX70Wh > KE98ka6AQqFQVEWiI12B05CmQE6kK6FQKBRViHeVMip/soDsSFdCoVAoqhD5nkjXQHFakQ60 > t/hfUfl5CRgT6UpEgHTKp52eqfIrN5QyqhjWIetJxcioaTFwP+A1pckBahnO3Qgsr6A6KhQK > RcRQyqjiuAWIBZoBzwKjgc9MaQqAv1ZwvU4Hqvp0c1Wvv0JRZpQyqjiKgULgKDAN+CMwEOhg > SPMf4G6gXpA8BgJDbMpoouWdA2QCHxmuZSCK7hdgG/A5EBPqTQDPAXuA48BvQG8X3ykk8J5e > BZ4xHL8AHELW27YBnbTzjZD7ydbq/3fDdzKAx4FlwGqHfMycDywAcpFpmttCqKtb2gNrkecw > HXiPwGkcq/qXpV4ZwD+B+cAG4GMg3qZ+lwBrDPVLNV23a0tuCfb8WiC/g0u04wbIc+uhHdu1 > sQzgXmATIqeXgbOAn4A8YBaQbErvVi527c1MRcjPLg+7thKqjBSnIT4gxeL8OuAmi/OrgYcN > aQYhDe517Zx5mu5t4JMgZXuB9cArQAKiaLoYrmcgIzGv9llCYAN2y0CgJhAFDEc6/mratXSs > 14zsOtIuWto62nEjoCHyorQK6cBjkQ5rIyIj/X6+1u4zyiYfMzHADqSj8SAvAzlANxd1dUsM > sBsYpR13RToFszIy1r+s9coAvkGerUfL+zmb+u0EHtLKvhzppPT6ObUlNzg9vxGIoqkG/ICs > uejYtbEMLX0q0Bw4AiwEWgNJiNJ51JCXk1zSkXbqVF8jFSE/uzyc2kqoMqoMTIx0BU43QlVG > s4CnDWkGIY3nGPImE8qaUVek0QWb8snA31hBpgpfMxxP0tJYfWbYlLsV/wgkndCV0YXAQaAX > gSO1TsgbqnFdbTQyotPvp6fhWrB8zHRH3sKNswLjgDdc1BXcyekyYK+p3C8pqYyM9S9rvTKA > qwzHvZDRoRXdgQNIR6rzraF+Tm3JjQycnh/AVGT0uAaIC1IWBLaxDOBKU72NcniQwI7NSS7p > SDt1U1+dipCfXR5ObSVUGVUGJqq56shSB5muMLId+BR4ApgdQl71gV1IpxUMo8n5CQKNJUYS > vEPIN6W7B6itldUAedsqLauBfwAvAi2BmUgn0Eirz3pD2lj8U1ogP0infA6ayktDpoCKDed2 > Au1c1teNnOoC+0zX9likN9a/rPUC6SCN/6cFSZem5W3cpL3D8L9TW3IjAzfPbzyikO4CTpny > t2tjGYb/T1ocm+vmRi5u6qtTEfKzy8NNWwlVRhFHKaPI0RKZ951vce0ZZH47PYT89iGjKS9Q > VIr6vIdMN1ixHOgDtAGeR97aNmrXNhP4hmhFPoGNPwWZttJ5V/vUAiYg0w+TgMPAubj3bGGV > zwOmNAeQjseD/8fcGH+H5VRXN3I6iHSgRhoRfKRSHvUC2XC9xvD/Aaw5gChMI3WRqUVwbktu > ZJCB/fNLQkZ37wNPApORF7PStjE7muIsF6f6GqkI+dnl4dRWqiTKgKHi8CDKvwZwDbLoORnr > abjdwAf415N07AwYliCN8XlkgTbUeeqRwEVBPjdraZKREVW6dnwVolSdWI1/2qAx0M9w7Txk > ztuDTE8e1/5fhHROTyFz5gCtCL4nJFg+ELjWthiZ339Uu94OGIZ/OsauruBOTouQDu0+7bgL > 0sHYUdZ6ATyCrBOkAH9DFLqOWQYeoK923BQxqNFxaktuZWD3/F5D2v6dyNTU29r50rYxO+zk > ouNU34qWn10eTm1FobBdM/JpnxxgKfLGHm1KY1wsrYd0qG4NGEB+FDOQzjgT+NBwLQMZien8 > A38H4JYoZF56KzAHMbRYh7+TTMd6zagTMtJbjiwmT8Q/h90JeWvNQRaqp+A3QmiIKOws7br+ > 1mh1P3b5zECsi3QuQBZ0c5GpkDtN+QSrayh0RKZ8dGurD5B1Oh1z/ctarwykTW1CZPAJ/k4V > SsqgPbASsa6chkwNG9e0mhK8Lbkl2PO7FllTq6mlS0La1DCc25hZbp/jNxQBsUb9ynDsJJd0 > /O3Urr1FQn52edi1lVBlVBmobGtYVZ5gykgRObxIJx7pOfLJyBpWuLBSbjqVRQaRwE4ubjmT > 5VdRKGVUzihlpNDpjN9ApBfyBnt2GMsrj073dETJpWqgrOkUijBxATJVGIuY6I5App4UCoUi > 7KiRkUKhUITORGVNp1AoFIqIo5TR6U06KqSDQqGoAihlpFAoFIqIo5SRQqFQKCKOUkYVQ1lC > OziFjShNSAeFQqGoVChlFH68wHfAFsTBYV1Kej64CPH03AoJvmf08H0V4j4oGL8iZsRJyA7w > L/C721coFArFGYiVaXdZQzuEipuQDgqFQlGZUKbdFUBpQjuE4nZkJBIUbA+icBpTtpAOCoVC > UeEoDwzhp6yhHewIh7t9hUKhqHDUyCj8lDW0g50BQzjc7SsUCkWFo5RR+ClGDBDaIJE9DyJT > a26xM2BYgoQTWIe42+9HYKRKhUKhUJyBKN90CoVCETrKgEGhUCgUkUcpI4VCoVBEHKWMFAqF > QhFxlDJSKBQKRcRRyijyOIVFTicynhMiVe7pRGNgAVCAGLcMimx1FIrKi1JGlZ8ngJ1lzGMP > 1oplILAYyANygf8BPcpY1pnCtcB84Biy12s1MJrADcd/R1w9LQIewu8pw0eg/8H3tHOfGM7p > 6XzI9oAjwGSgkUUaY14KRZVEeWCo/HwcpnzvAv4PGAXMQDq1K4EbgXlhKjNcxCCjj4rifvz+ > A1ciHtO7AK8jTm/v0K410/5O0D6lYRVwGLgUGADEIvvJFAqFIijB9hmdj0zX5CLTX7cZrmUA > DwCbEB91HyOeGnTS8Y9qGiGhKLK17/3dkC5YmIq3EL94+7S8hgMJWpphFnXV3+yN5dqFqXgB > 2cybhYTA6ORw3ikkRjetjBPIht63Ebm+YUhTqJ0bpdVzh3a+JTAFkc9JZNSn1zUV/0gjUTv3 > qnY8xiLvR7W8TwCf4veEXkOTgw940vC9fob8OyLP22f6nEPoIyM93SPa8TabNEY8wEvAfu2e > jiIjuTSLtApFpJkY6Qqcblgpoxiks/w70kF0QBSG7qk7AxmJpGrfnY90/jrpiFLwIG/JY5C3 > 4waIP7pBiN+79cAriKIxuxwyT9NdinRQRqVnRi8XRIHURBTVcETBVNPKSAfqaOkaAQ1tzoMo > F2OnayQFGQX4EJl8ifjzC6aMjiPxn/6LuEbSO+c5iAIpRkZMHQhURrpisVNG64G/aH99yKgH > ZHpOnzozP+vN2rV/IqOnXdrxj1pZdSmdMooDxmvHk4OkMdNHu7YGeBwZBS8FWlikVSgijVJG > 5YyVMuqOjBCM63Pj8HeuGQS6++lD4NtvOqIUOiFv/F7DtdFIZ+wUpsKsjK5FRkZ26OVaoYep > uBBxb9SLwICAwc47cSMiwz347/N7giujEYZzN2nn0vHLeqJ2bjyBykhXwnbKqKd23Es7Pqod > 36EdH7Oo/zwCFdcs7fhWQ5rSrBnpnzmIQrPLS2eAdm0B8sJyHsqBrqLyojwwVABpSKdRbDi3 > k8Dpkj2m/62mUhohb8jrkRHRRmRRPA53YSqMHEFGEnYjIyPBwlSsBv4BvKjl+QXSWQY770Q9 > 7e9m/B7ON9ikn2v4Xx95bcYv699M18x4g5wHv9GI/rcGIuvD2nEiUN30nfra38MER39GxrL1 > lwirda/5iBICGeE1tsnbyExgOvKi8iXSbrYhU4UKRaVDKaPwcwBRJEZZN9bO6xg7y0amazoZ > SCd3LtKhnAM0B/oTGKbCCp/p+FfkzX6ARVrz27MepuJGrW5NEYWkp3sXaIcs1ifgX8cKdt6O > fdrflvjvpY1N+pOG//cavqvL+lzDtXxDWn30amdS39aUJhM4hSiHE8j9P2BI3xeJ1Avwg02+ > unLrqP2NRuRkvGbkXeAKZNoxCVkDdMNJZB2rNjI6n4I8i1tdfl+hUFRhgq0Z7QQeQzrJdsh0 > 26Xa9QzkzTcFedP+Cen8ddLxrxmtAf6NdO4gnZ9+bT2yLmAVpmI1cL2pXiORDnYoMoWViqwN > jTOV2xnpzPVR1FX4Le/OQ97WPcg61mfAWJvzYG/AUB3/mtFiYCr+aTOraTqjmXMyosx8wM/I > aKxYS6t3/Fu061OBD/BPf1lN0+1Dps8OWJT/kOG7v2rl6d/70JDOapruVsN3lyJTnj5EwRnD > f5in4FoYyuhtSrMVkZf+uQy4Gpk2fBZpe6vwG2YoFJUNtWZUzgSzprsAWIhY0+0C7jRc063p > NiKGDZ/gVzYQuHbTEFnAztLSLkfWmEBGLDOQEU8mgZ3iUK2cLALXWQYhYSis9hnp5UYhHfFW > RGm+joSsuBJZN1qj1SULefuuY3Me7A0YQAw7NiBv9t8gIwMfsr6jY6WMAFrjtyg8hXT2fQ3X > eyHGJCcRhfQpwZXRndo9n0DW5RIJZCB+C8mT2v0+SOAI2EoZAdyLvDzkI0YYP1Nyf5fVepC+ > BvazKY35cx0yoluIyL8IWbccj994Q6GoTChlVM6EI4TETuDics6zMpNsOp6NyPXhCio/mKJT > KBThY6La9Fq5qY2MKPY4JTyNeBNZR1mDTPX1QkZ6n0ayUgqFQlGVKM+RUQdkCmiMU8LTjEcQ > 5VuIKKFp+I0JKgI1MlIoKh41TVfOqEivCoVCETpqn5FCoVAoIo9SRgqFQqGIOEoZhZ/ayPTd > xnJOW57fBVkryTUd+7R8Ac7Wjg9bpPEh3gM2EGiKbM7DDjf1N9exvBmE7EVyexxujPItQszt > K2KfUFnbkplwP7fKhJKdbLHQt4wcR7yB1Lc5DyhlpCgf/oVsED0H2d9UzzZ15aU/8G0IxxXF > v5DNq6mIN3Q7r+cKRaSph/imfATZu9gH8cAS7LwiDFgZMFi9Ka1AvDAUIZtRX0Hc3+hptyCb > S48hm2T/ZPhuX2Sz6ynE79t7yN4cq3KCpQW4G2kYRxGvzmUZGelpdC/V7YNc18MqWLnhsaq/ > Ux2d5JiOKMfjlJSjuS4xiPVeV5fH/bTy87X6/RfxbA5+WS3TjqO14wxD+V7tvNVHxyw/3bHr > m9qx3fO1q5+TfEJtS2acnttVSMDBE1rZH4Qol2B1GarV+3Mt3Wva8SPacbD2Ug//7+5d5M19 > OeLFZK5WzlzEP2FVl53d9+3aTCgyMroUG6F9722b86Cs6codt8ror4hLlyuAr7XrNxvS+hC3 > PI8hD/k44mj0fGQ6bIn2/b/id0FjLscu7UWIq5wsxPuDXofSKqPzEM8JJ5EfUmKQPEJRRm7q > 6EaOjyLTa8fwy9GqLlcjHZTHxfEF2r0dRtwq6a6FvjPJaol2bKWM1hnqaP4kaWl0+V2slblS > O34c++frVD8n+YTSlsw4Pbc2SGeXB/wNCUlifDt2kotTXSbgV9jFiFcSvRMM1l7qGcr4APgK > /9ToS0gnq8uqKsvO7vtObSYUGen00up+CPlN2J1XyqiccaOMEpE3i52I25qT2vWXDGkP4P8B > 6Q1yINKA9AZQiL+z2mtRjl1aPVCbHq20BiU7+gKsldEhQxrjmoYP+UF2tbiu56G/uVlhrr9T > Hd3IUXe8CjAJvxyt6vIW8I7LY122/6cdxyAvDUWIDz9dVou161bK6GLEP6HVR1eAZvnqeaZg > /3yd6uckn1Dakhmn5/Y303UzTnJxqkuiVm/j70I/H6y96B3tIeR31107Xql9d4h2/Banh+ys > vu/UZkKREYjbqWyt7rrDYrvzygNDBBihfSYjQdiuB54ieCdtFYNmAoG+2oot0til1f216V6v > T1l87yjyplcPeVvS14GswiMMQUZGo5A30o5Yh0PwIj8KPWCeG4LV0Y0cYxD5+ZDwD8HqAhLj > SfcZGOVw7IT+PHTP47Us0vyX4B7Jkwl8MdADGu7B7/BUx+r5XueynnbysSKUdmfXtiB4bCUn > uTjVpZohXRJ+57tu2ssRRBZ629W95+vyNq6xV2XZlSWulVsZRQH3If2IMQxMsPNBO8BIcTbi > HLMxMnx8wz55lSRW+5uDPMB+FmnqIm8Y6YjiyEOcY25GfkD9kWmmg8gbSpJ23sg0m7R6MLeh > iPPT3pRkCvLj/QQZqvfXzlst4M9C5ukvQUZG9+APMGdkDqK02iJTCnb8z6GObuRYG5mT3oEs > lupyNNclEZHLbO1aR4fj6Yj39NuRZ9RRq893SEeSgXQkbYDBWCuHwQQ6xDWSZzqeScmXALvn > O96hfvo0oJ183JY1GnmrronEsHJ6blO1vEZo97Qb8XbxtHbdSS52dbkf+Bix0Por8Azivb0r > 7tpLKFRF2dl936lNh0oq8CQSU+w7F+cB/zxjMTJ8Wow8VK8pTQ6Bb3g3IgtY5clY4OVyzrMi > cTNNVwPpvPMR5fKxdv1VQ9otiCLORRqM2YBhKdLZnUDCQ9xmUY5dWpCF0kPIM3+VkgulSci6 > VYZ2bS/ybIxvgeZpuK74h/LVLa6XxoAhWB3LKkdjXcbgX/TGxTFIZ7ZSKz8TUdrG38e92vmj > iAWceZrODU6m8XbP165+TvIJtS2la+lTtWOnttUbWUM5iUztvm8rBff3/RetHq9o6fT1mZex > by/6FJR+v5214++1Yz0C8dtUfdnZfd+uzYQiI5AoAj5kJG8k2PmJIIpmODJKqqlVaAsyD6qz > Dhme/Z/hXDiU0de4nwqJJDWRuETdTOetlJGi4gl1r8dGpD27Pa7qlOdemASkg53LmRHWXMku > PPyujG4yXWiNzKV30I7XIcPIHPxrB2Zl9AKi0bOQ8MadghR6Pv44MOn43xA+QoaSh7XzrSy+ > W5E0Q95o7kUWOScjZo9ZyFvDCkqO4pQyqhyU98bD043ylE8fpF9oWg55VQWU7MJDUAOGTYgC > 6o5/r8RGZD3nb8g0npEuyHzleYhCaoT1AnUMMof6HhKNsh0yD78ZuAXpyKdr1yuKGKTeF5k+ > Oci85g7tswhRktsRZaSovBxGvWnaUZ7y+R6Zkj1TULILE3YGDIeQeVYjTyHznS+azuchVixt > gfkEj7/TGVmLeB5Zo1qGDM+GAL+EUvEykARcjti6X46YF25H5jBXIcpwJTLXr1AoFIoKwE4Z > 1aFkh7wdCXL2BH7LIhAF9Q9ESbVErH9GI5YjRtIQRWU0a9yJjJDCRQyytnMF0BNRmEuQ+t+n > 1b001iIKhUKhKCeCKaOWyNrOfItrzyD24emm8+9qn1qITf3fkV3ERg4gU3ge/AqpMX5b9fKk > CzAMuAExyJiFKMxFBLffVygUCkUE8Bj+RiPTctcgU1WTsbaW2424g3jYcO48xNjBg981hpUT > 1sXIlN6j2vV2iMIwm82WluaIDftWZLf8LmTvSzfE2eQ8lCICGaH+gMhpL+L+w8iPiNNTJ+w2 > rp5Edm6Xlicoucnw38j64lbkBeM/2vnyKK8slEfZ5vuNQwxntiH3uwpxPVMWDiO/ie1avreW > Mb/ywouYPteJdEUUkcXozygHaRQPEDhqWkfgD6EeonB0ZdUJWKN9PwvZMBmsYV0ALESs6XYR > aMr9LaUz7W4PfImMsF7UyogEVcWargFwofb/hci+Ar0zvQrxO+UGO2XUkbIt9BYS2AY/QV6Q > 9HXMeMSQRt+fEUllVNZ7hZL3+wXSpvUNqm2QF8EBQb7vDXLeyGH8e7y6IM+9fvDkpS6nNNxJ > 1d5jqCgbVd43XTNkDSsdWaNKtE0dfsKljAYgLwRrEUMP46jFh4z6vkTWvwYbrvVE1sfWIG/W > fSzy7oW8FOhv5V8Q+OLhVPZTyIh3i6lso3Kwq8dVwK/atTVa2ue1vH9CRrMXICNqO9kay/sM > MY7ZgOzyNvon+xpYr5U51eG8W4xll+Z5BLvfVAK5Bb8vML2sZ7X63qOduxl5FgsRy9dCQ3qj > MgJZE9Z9Cdo9I3M5dvIqbVtNQdaYw6XsFJWbKquMopAfxUFkbSqYC4yKJhzKqBEy2myhHd+B > /JCNZeq7v5vhd+BYBzHH1/eFnYVMyRkVdjvEbN1oQHJAS+u27NHa/02QjdH6m7beQdvVo572 > nYu1ax788jOOFG5AOj07jArBaAX6ODLdBSXjESU7nAeZzkwP8qlmUXZpn4eb+22JrLXqHbaP > wA79LEThNNCO7ye4MuqDTFnXcVE3cznB5FXatqqzlvAaMykqL1VSGcUjb76LkR9nZSIcymgI > fpcbIB3RKfxv+z78frdA3qhjkQ7tIPKmrX82IxuadRYha4Q6MVp++jqMm7KN9zsd/6hK76Dt > 6nEj4uLfirIoo4eQkcHPyFu+fg9NkFHgG0jnmuxw3i1mZVSa51FaZVTNcH0IshdQJ4WSymgv > cq+r8Hswd6qbuZxg8iptW9X5EfdOXhWnF1XOa7cXmUbKQfYIKWMEId/wfzEywvAgb5pX2HzP > i2xw1tFd3Mdj7XW7NNjV4yLcrbWsRPaDpSA+u+zohvj36qil/QPwZ+3aTmTtpZdWn+eRkUKw > 83mIFWYwY45WlHRqCqV/HjqrEKMg8/12RabRigznrMq3ozclndS6qZuxnGDycoOVbHTiEfc4 > CkWl5zlkIbuy7q4P5zSdHoTKaurDSC7yo07TvtfDcK29Ke0fKVnf1YgFotuy9Wm6plhP09nV > Iw15W9en6bz410myCZxu+wwxYNAjT8YDD1LSgKEv8mav8yGiUECmr/Qp3ThgP2KBGey8W8wj > IyNun4f5fr9E/EPqBgznIQYMxvU8c1mNcT9NZ8SpbuZygsmrtG1V54Ch7oozi0oxTZeBu7eq > 1oh7nkhZTLkhXAYMA5F7/w2ZfjIGpbL7gffAv5C/EenMjWQgoxMjTyHejt2W/S+tjG0EOhM9 > id/Dt109rkRGAr8hb+c9tPPP4DdpTkCmc57VyklHFulfoqRpdwxiDfg/ZBT9Fn5l1BsZWazW > 6vG0w3m3uFFGYC8H8/0mIKbruhm2ecHfqiwQc+3tiFXs08hWC51gysipbuZy7ORV2rZ6If7I > uIozjyqljF7H/xZeWakqpt121EOmxcpi1ZSMTOtU1hHs6YxxbWc4fkVc2XkTCXinODMJuzJy > syblVhktp/Jb2pwOygikUzjbMZU1bZA1BXOwP0XF8CzyW1mPeMePtPd7N3iRjfCKM5eJEDz0 > QyPEw3Y2ojD+bvjic4iPuePIcNwYkTADMaddhvwgQKxvpiGGB5lIuAhj+ru0fPIQbwwxlGQd > wUPqVhZOF2WkUCgUFclEkPl33VtCI6AhYuGyColwGYssKm7Ev3g6EFlIjkKmArLwTw9kIBvi > 9BjxXkQpvYLMg8cgu78xpP8B8WlXVyvnNkryGZU/wJlSRgqFQhE6E6OQ/QU3Ik5RdXPeTojN > f038ZqSjEbNZK4WwFfExtwRRLkOQ6IUg5qjTEIudQovvmtM/jyg2s5PV3oiJ7tVu7y4C+IDU > Sa9MyvckxLnx7aZQKBRnJPkez+6hI/sd1g4nRmMd+qERYgm13vDdWPxmmiMRDwi1EQXTAL8J > Ksi0n059ZIOclSKySn+cknGUQEZPoxGXKB9ZXK80xKXERZ8s8IXq8yvsjHnj6WmAZ9A1g285 > u1mrw45fqEBefnvMhG4duj/XuV23LeZrE74Yf0dUVFTxrTfcOaG88jTy4rjnJl5x6dV/u6Rt > +52h1vtMw61MnSjtM63qKPn5iZatIMZjy9APkxAz0HMpaY7ZBhm9dMUfenczwS2n9iHuRbwE > btYrDXcj/rsOIT7HFKcJLZqe/UnD+meZ419VujwVCkV48GAd+mER4kTxKfyb21ohG+GSkV3S > 6dr5q7B3y7ME2cz2PP59IF1s0tuxB7H0egfZUKeIMCdOnigXLx7X9Rk0+6wGjZ28K0Q8T4VC > ER6igfeR3fPFyKjj39r/f0D29uxHFNRmZErvB8T/1Tpk+m0dgdN5ZooR/2dvIiOaQiTExKJS > 1nkF4mH4G8Ql0GicXcRElDFvPD0DoEXTlm/u3JN+Q3FxcULjho0/q1+3wdZf1yy7v6CwoE5q > So35t99416sx0THFABs2r683d9HsO3OPH7vA5/PFVEtI3NCtQ/d39Kmk0uSps2bDqkum/PjN > DYWFBbVSklMXDel/82spySmnXJY7DfA0b9zi7d37dg0AfH+++7HbZ8ya2q2ouCj6T1f3/ymI > DKbdeO1Nw5ue1SwT4IPP373L6/WevOX6Oz6GwOmLpSsXtfhl2fyHCwoL6iRWS/wtNiY2MyYm > NidUuRvzXLF2eZMFS38adfLkyeZerzenWeMWnw7oe/3/9LQ7dm07d96iOY8XFOSnpSSnLL7l > hjtfTohPKASZxmtYr9E3h44c6lxYVFAjMSFxs/G6GbuynOTglhfHPTexft0G049mHbm4sLAw > JbFa0uah/YePTU5KzgfYumNz7R9+mnnf8bzc86OiovIbpDWcOmzALV841c8pXyN2ZZhxeqab > tm2oO2v+j/ccz8ttCxSnVE9dPPKm+14JRSbB6rN+09r6M2ZPe7VHl55/63hxl207dm2r+dWM > L97scGGn53p0vWLtR5Pev+XQ0YNXFBUVJcXExB684JwL373yst4rdHk0bdTs0937dl1bWFhY > q06tujMv7XjZlJlzZzxy4mReq2oJib8N6z/8mZo1ap2o6vKzy8OpzYQio2B4EHf11RG3Ktfi > X7/Zi1jNpWrX2yNOEH3AKGQfSi/E5cj5+DfX1aOk76t0RCElI+tBtxqumdM/g0zH2bEVMbI4 > hijCYVSBDZbpu7cPS4iPTy8uLkpK373jzqUrF/8jLi5+D0Bm1tErZs6Z3h3gaOaRhBlzpr6Q > cyy7S/Wk6r/WqVV35vG83LazF/z43P4De5NLk6eR7Tu33Vw9KXmtx+Nm7zjrAAAORUlEQVTJ > y8rJvPyr6Z/fFmq5O3Zvvy2xWuLGpMSk3wD2H9x78f4DezuUVUYnTp6I/nnJT/+sn9bgf4/c > /djgNq3aTj6adbRHWfOc+8usf9WqUXv5I/c8Nqhr+0uf35q+eeT8JfPO09PsP7iv25Brh/1l > yHU335Z3Iq/5zDnTexrzyDmW3eLeW+9/9P47/jziVP6peubroZRVXuTk5rS455b7H3twxCN3 > FxUXJXz93aQhAMXFRVHTZk15MrFa4q7Rtz88ZNA1g0cfOJTRa/qsKZe6qV+wfI3YlWElE7tn > WlBY4Plu9rSnEuIT9t0z/P6ho29/eOj5rdqGNA1vV582rdvub9GkxYQFy+b/JftYdtyM2VMf > ql2zzqweXa9YC1C7Zp2tw/oPv+8v9zw+sHnj5l+uWLf8sexj2br3EA4czuh808BbH+p31XX3 > HT566Mrv5kx7rEeXXmNHDL1nqM9XHPP9vBlGZ8NVUn52ebhpM6HKyIqq5ijVSB5wH/AxMup6 > EPgngV6DKxVtWrd9o2+vfoteeeeFd/IL8hvVrlXnf7cNHvH++IlvPXAk88jVR7OONAd+mr/0 > p86FhYW142Ljdva7uv84gG9nftXw2PFj7Rcs/fmy6/sNmRFqnsZ6tD33wrG9e/Rd+sO87zqu > XPfrv45kHukJvB1KuWc3bfnuwGsG/y7rO4fe80Z5yGjZqsWtfb7imBv6DZni8Xh9Pbpesfa3 > zetWGNOM+3js47nHj1lulK6WUG3Lfbc++KQ5z2JfccKQ626a5PF4fV3aX7p5/eZ1czdv33R5 > 9049fgNo07rtl/XTGh4DqFWj9qKs7KMBvunatG47TR9hpqbUWGm+HkpZdoRyb62bnzNDr9M5 > Z587beW6X+8HPlr868JWBQX5acMG3PJRTHRMcbPGLY42qn/W9D37dnVbtmpxplP9guVrrItd > Gchm2wCZ2D3TJSsWti4sLKwxbMAtH8TFxhUBdOt4mb4e7UomTvUZeM3g79/88LWOH3z2zn8A > 3w39hv5bz+OaK//0i/7/dX0GzX75nReGrN+4pmnXDt03AZzb8vzJdWunHa9bO+343IWz1icm > Ju284LyL9gCk1a73S2ZOZsDG4qooP7s83LTpUGVkRVVWRjpLkHWvgYhV4PPAOCToXm4E61WC > 5o1bbAfwer3HKYBaNWpvBYiOjskFKC4ujgE4npdbC+BU/qkm//1qwmfGPHLzcuuVJk8jjRs0 > 2QXQqP5Zu1eu+5Xi4qKk43nHY0Ipt3WLc9eUVg525OTm1IiNiT3o8Xh/N5yJj084YEzTv8+g > sSdPnbTaGE1cbGyJqbOc3JwaMdExh415VkuodjD7WPbvXiZSklN/n+r1er0nCwrzjdahJFZL > Ov77dY83v8CXXz1Y/Z3KsiOUe0upnpql/59avUZWUWFRKkBmdmZtn88XM/b9V8bp130+X0xC > QrXtrmQRJF8jdmWY0zo90+yc7JoxMTGH9E6wNDJxU58WTc7+YdX6FU+0bNZqbGK1xN+90n81 > /fM/7N6/+5qiosLqUUQVFRYV1jxx6uTvMdJqpNTI1P/3eDz5CXEJ/mOvt8Bn+o1VRfnZ5eGm > zYQqIytOB2UEMnX4FeLcsSdwL+IW5XNEMTm+kZqIR5xflivR3uiAB+3xeCwbT2K1pCMAsbFx > uy887+K3jdeMDz2UPI3s2rfzrHNbtcnYs393I/mONzexWmJBKOXGx8WXmAO3IyoqqvBUvv8H > UVhYmOj1ekvIuHpS9czCwsKAH29+QX5KfFz876boX8/88oHjx3PbWpWTkJCwZdRtD/3TnGdB > YUHt4uKiKP0HlXcir05sTGyWVR5lwaksJzmEcm+Hjx6qiwRH5NCRg3W90d4sgOrJ1TO9Xm/O > gyMeudvYgQD8vHhuGydZBMs34D5tyrCSid0zTa2eeqSgoKBOQWGBx7y+6VYmTvU5mnkkYf3m > tXfVqlHrxx27tg/bf2DvL/XTGh5bsXZ5k+27tt/ap0ffP+tv8q+888J4u/txoirKzy6Pivr9 > nC7KSMcHzNE+DYARyObdfYjBw7eIV2InHkOmAccSgfgq3TtevnjL9k1H8/NPnbVl+8be1ZNT > tp88eaJmVk7WJZe0bV/m6bC1G1Y/kL5nx4qcY9ntAWrVqDWvrOU6GTDEx8VvX79p7UWtW5z7 > 45btm+pk52R1qlsnrcS8doeLOm9aumpJ1A/zvuvQu0ffZRu3/paWcyy7Y3xc/O9pr+09YOyJ > E3mx5u8CxMXFl4jDpOV56vMpEwfdeO2wr5atWtLiaNaRnp0v6fqk3T255b1Px40qKiqKH3nz > qJecynKSQyj3tnn7xoGXtG2/DmDj1g2Da9eoMx+gW4fuG5avXnrsk68/Gta/z/WTkpOS89du > WN3weF5uNTeyCJavEbsyOrfrtsVCJkGfaZf23TYtXbU4c+Lkj24deM3gT6Kjo4tXrFl2tj5N > 5EYmTvWZ/N0Xd1VLSNwyYti9r42fOG70tz98Peqe4aOfP3EiL8ETFZXfrHGLgwCz5/94cX5B > fpnCWFRF+dnlEe7fj05FKqN0xJ3Q8goqbx9imv4M4jniOiSqaD6ilL5F3OyXeJNAIoTORtak > HkNGWLZvL+VJzRq1TvTpec1ff14y7/ac3Jx2WTlZl0ZHR2cmVUta36j+WfvLmn+zxi3+m75n > x/XFxcUJqdVTfx7Q94YJZS13/8G9FxcVFcVjWp/S6XBhp3cXr1j48KvjX7wmNjbuUHJydcvI > rQnxCYWXduj+7OIVC+/fuHXD4Ojo6GPVk1KWGdM0rNcoJMu6hPiEwh5dej31y7KfR700bsyN > Hq/3WIsmLd+7rHNPOytQ15zKP1W7bq20ZW7KcpJDKPeWVrveL59M/vA/hUWFNVOSUxYP6HvD > pwAej9f3p94Dnvhh3nd3j/v49U8AT2xM7N42rdt+7EYWwfI1YleGlUzsnqnH4/X9odcfn5y9 > 4Md7xn38+qdollx6Z+pGJnb1mTlneufsnOz2wwYMvxdgYN8b3psw6b2xU374ume/q66dt3Hb > hoXvTnzrrdiYmEPVEhJ3xsXGlWnzc1WVX7A8wv370alIC7R0/MpoD6IcKkoxGblIK/taxNPE > AkT5LEBCJxQiFn7GzncpEuNnnkPePiB1yvtTik8W+EpYsSkqlpfeHvPhZZ0uf7rjxV22hauM > gsICz9j3Xxk38uZRo4zrEOEmXF4jyiPfSMmkMqDk556oKO+6G0b226Udlgg7Ho29257TgVXa > 50nEVVF34FLE3LwJYhBhfmvviPjO+wZxdb+1YqqqKC17M/ZULyoqTKmf1jCsbo9iomOKHx75 > 15HhLKOqoWRSNs5U+XkIDPmg+56zCx8RLOSEPqLQeRWZIjPzlpZuKjJaGu6QbzjZj7g+uh+J > NNkU2eibFiR9f8QY4i3EL5+iErJo+YJWEyd/NCGtTr2pygODQlE1iEKUzUIkpHGhdm4Fsl/n > CaTTnYN4X9iLhHLogCiORsjU1F7tu420/ECUUa72PbCfputik28kuBfZu2RHEaKkX8Nveaem > 6RQKhcIFwabpxuIPH9ERaIZ0tEWIIcCbiCLRwzu0RUJO7CmneuWFKd/SEIVY4VmRh0zxrUVC > b8zALzeFQqFQlBKP9tcYwsEYPmKj9nlIO7caf8iJI8AXSEC8shKufEvDXYiRQx4yYhyLrCe1 > RdwidUPcFT2BuDEqqyfyCmPMG09PG/PG0zO27thc6aYYX357zITFv/5i6XB3whfj7/hw0ntW > ARcVlQC7ZxcKZ+pzVvITPBbnMvCHjzhH+zRH1ktAwk20Q0ZPCfjXk/IRhaVjF/HUykw6WL4V > SRwSGt2oeHRXHlVK8VQ1VLgHheLMxkoZ2YWPOA/rkBMgo5srtf8bA/1syj2KKB0du3wrklPI > 2pVSPC6pzCEkwsWp/FPeSNdBoTjdsOpI7MJHZALjKRlyAsRR6YdIBNjdSKiJYLyATH+NB/4C > rLHJt8qjQkhEJoREqK7tnUIJNEhrOOXQkUNdfb7iuHp16s/KzMk8595b7n9WL+/9z965Owp8 > tw8Z+Y65LiqsRElUWInKL79whpXo0fXKocayPFiHfAgWPmIJwUNOLEGm9tojU3rD8FvSgSga > 3XruU63cVEQJ2eV72qBCSDhT3iEkQnFt7xRKIPtYdquRN9/3yAN3/vnezu26zj2Wm9Pu4OED > iSCjpaNZRy5r07rtbKt7UmElSspEhZWo3PILd1iJSVMn3mws73TzTVepUSEknCnvEBKhuLZ3 > DiVw3lQ9oF6zxi2OJlZLXD9/ybzuA68Z/P28hbPbeb3ROZ0u6VpiQ7QKK6HCSlRF+YU7rMSu > vTsDXsaUMqpAVAgJZ8o7hEQoru2dQgkYw0wANG7YdFb67h19ge937NrWM6122pxg96TCSgSi > wkpUfvmFPayEzxfgvFUpowpEhZCITAgJN5QmlEDPrlcuGvfx6/etWLu8Sc6xnI5XXHr1B1bp > VFgJa5mosBKBVDb5VXRYCaWMKiEqhET5hpBwQ2lCCSQnJefXSKnxy0+L5jyakJCwuWXz1r+v > c6qwEpEPi6DCSlStsBJKGVVCVAiJ8g0h4YYu7bttKk0ogdYtzp21cPmCq5s0avaq8bwKK1E5 > wiKosBJVJ6xERYaQOBNQvunOMLZs31Tn65lfvnvHkJHDateskwcqrIQVZ0pYBCuU/KxxCiGh > UChCYMGyn/+UmlJjvq6I4MwNAWCHkknZOBPkp5SRQlEKMrMz48dPfOuTmOiYQ3/o9ccnI10f > haKqo6bpyhcfkDp37tzjezYfrRPpyigUCkVlJZXY7H4j++kzChMjWpnTEB/2DmIVCoVCURK1 > ZhQGLkKCCioUCoXCHTXVNF35si3SFVAoFIqqyP8DrqC+qm2XwigAAAAASUVORK5CYII= > --------------060504090007030105050009-- > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

Re: (ITS#6382) Error in set example (groups of groups)
by gavin.henry＠gmail.com 18 Nov '09

18 Nov '09

Thanks. Will fix this next week as I'm with my son in hospital until Friday. Gavin. On 16/11/2009, andreas(a)canonical.com <andreas(a)canonical.com> wrote: > Full_Name: Andreas Hasenack > Version: head > OS: linux > URL: ftp://ftp.openldap.org/incoming/andreas-hasenack-091116.tar.gz > Submission from: (NULL) (63.133.153.66) > > > The picture set-recursivegroup.png has a typo in the reference to > accountadm. It > should be under ou=group, not ou=people, in the upper left box. > > For reference, it's published here: > http://www.openldap.org/doc/admin24/access-control.html#Sets%20-%20Granting… > > The andreas-hasenack-091116.tar.gz tarball I'm uploading has a fixed .svg > file > (the source) as well as an exported png one. > > I wrongly uploaded that file as openldap-guide-fix.tar.gz: you can delete > that > one. > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

Re: (ITS#6371) problem with ber_flatten2
by h.b.furuseth＠usit.uio.no 18 Nov '09

18 Nov '09

dave.daugherty(a)centrify.com writes: > Version: 2.2.6 and 2.4.17 This bug was fixed in OpenLDAP 2.4.18. > 1) Is the zero terminator really necessary? Yes. Much OpenLDAP code expects bervalues to be \0-terminated. lber.h now has a LBER_BV_NOTERM flag for not \0-terminating it. > 2) If so, seems like it should only be done if we actually allocated > a new buffer (which does leave one byte at the end). That would have been a cleaner default for the input value, but not for the output value:-( In any case, this function was probably first written for internal use - for accessing a BerElement. That code does deal with \0-termination. This quirk should be documented though. Currently ber_flatten is not documented at all. -- Hallvard

1 0

Re: (ITS#6386) Usage of ldap_init_fd
by hyc＠symas.com 18 Nov '09

18 Nov '09

vitaly.kroivets(a)gmail.com wrote: > Full_Name: Vitaly > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.115.180.11) > > > I try to use function ldap_init_fd, but it fails . Thanks for the report, a fix is now in CVS HEAD. Please test. > > ldap_init_fd (sockfd , 1 ,host_uri , &server); > > ... > rc = ldap_simple_bind_s(server, bind_dn, password); > if (rc != 0) { > fprintf(stderr, "ldap_simple_bind_s: %s", (*ldap_err2string)(rc)); > return 1; > } > > rc = ldap_search_s(server, ludp->lud_dn, ludp->lud_scope, > ludp->lud_filter, ludp->lud_attrs, 0, &result); > > ... > fails with segmentation fault: > > #0 find_connection (ld=0x8073ae8, srv=0x807cd50, any=1) at request.c:629 > #1 0x080571ba in ldap_chase_referrals (ld=0x8073a08, lr=0x807cc98, > errstrp=0x807ccbc, sref=-1, hadrefp=0xbffff84c) at request.c:1356 > #2 0x0804c620 in try_read1msg (ld=0x8073a08, msgid=2, all=1, > lc=0x8073ae8, > result=0x8071ce0) at result.c:805 > #3 0x0804bab0 in wait4msg (ld=0x8073a08, msgid=2, all=1, > timeout=0x8073ae8, > result=0x8071ce0) at result.c:390 > #4 0x0804dc5e in ldap_search_s (ld=0x8073a08, base=0x8071d80 "cn=US", > scope=0, filter=0x0, attrs=0x0, attrsonly=0, res=0x8071ce0) at > search.c:428 > #5 0x0804ab38 in main (argc=3, argv=0xbffff9d0) at /tmp/get.c:182 > (gdb) p lc > $1 = (struct ldap_conn *) 0x8073ae8 > (gdb) p *lc > $2 = {lconn_sb = 0x807bb30, lconn_refcnt = 3, lconn_created = 0, > lconn_lastused = 1258722436, lconn_rebind_inprogress = 0, > lconn_rebind_queue = 0x0, lconn_status = 3, lconn_server = 0x0, > lconn_ber = 0x0, lconn_next = 0x0} > (gdb) quit > > > > > -- -- Howard Chu CTO, 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#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 18 Nov '09

18 Nov '09

pitpalme+openldap(a)gmail.com wrote: > Hello, > > hyc(a)symas.com wrote: > >> Paste the debug log somewhere we can see it then. Might as well use = > debug >> level -1 while executing this sequence. And provide the debug output = > from both >> servers. > > I=92ve got 60MiB of log files (cumulated from both servers) from running = > slapd with "-d Any=93.=20 > Sadly this erroneous behavior did only happened after a couple of test = > runs, so it=92s a lot of "everything works normal" in this files. > > The logs are available here: > > <url:http://pitpalme.is-a-geek.net/ldap/> > > They're both equal regarding contents, just compressed differently for = > faster download if 'xz' as compression tool is available. > > The test DN that fails is "cn=3DMax = > Mustermann,ou=3DbulkTestPerl,ou=3Dtest,o=3Desolution,dc=3Ddeutscherv,dc=3D= > de". The log shows that the problem is because the two servers are not synchronized before you begin your test. If you search for "do_syncrep" in the ldap1 log, you'll see that it was unable to connect to its provider at the very beginning of the file. It doesn't successfully connect until much later, 97% of the way down in the log file, after the majority of your testing has already been running. That delay is based on your syncrepl retry setting. When it finally connects it sends a somewhat out of date cookie to the peer server, and so it starts receiving results back. You get the "already exists" error because the entry you're trying to add has just been added by syncrepl itself. Part of the problem is the out-of-date cookie; the consumer checks with syncprov to make sure it has an up-to-date cookie but obviously in your case the cookie continues to change since you're still making changes to the DB. You can avoid this issue by making sure both servers' consumers are connected before performing any write ops, and you can assist in that by using a faster initial retry time in your syncrepl config. -- -- Howard Chu CTO, 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#6387) Valgrind reports issues in pcache
by hyc＠symas.com 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it wrote: > masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD,re24,2.4.19 >> OS: irrelevant? >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (131.175.154.146) >> Submitted by: ando >> >> >> See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> > > The fix to ITS#6388 fixes the first valgrind warning of this ITS. The 2nd warning is just noise, you can shut it off in BerkeleyDB with "configure--enable-umrw" but the condition is harmless, and shutting it up imposes a performance penalty. -- -- Howard Chu CTO, 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#6383) Very Slow Query Response
by quanah＠zimbra.com 18 Nov '09

18 Nov '09

--On November 18, 2009 9:39:02 AM +0000 Bill MacAllister <whm(a)stanford.edu> wrote: >> For historical note this was caused by Cyrus-sasl being built >> incorrectly by the debian packagers when heimdal is used. >> > > I don't understand why you refer to this finding as historical. Not a historical finding. As a record for anyone who comes across this ITS and wants to know what was found. > If I > am reading this correctly you and Howard have found the underlying > cause. Now that the problem is understood can you suggest a way for > us to cause the problem in our test environments? At this point we > will really need to convince ourselves that the problem is indeed fixed > before we try to deploy 2.4 in our production environment again. To note, first off, this issue was not a bug in OpenLDAP, and the project went beyond its scope in tracking down why cyrus-sasl was behaving the way it was. Finding out test cases for you to explore is also beyond the scope of the OpenLDAP project when dealing with non-OpenLDAP issues. However, given what is known, i.e., that the NTLM code path was being called during SASL/GSSAPI binds, I would suggest you either set up a number of windows boxes that try and do SASL/GSSAPI auth with NTLM to a test server, or write a script that does that and run it from multiple systems. Some reference points: <http://www.netid.washington.edu/documentation/ldapAuth.aspx> It also seems it may be possible to use python-ldap to do this. I don't know if it is possible with Net::LDAP or Net::LDAPapi --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by h.b.furuseth＠usit.uio.no 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it writes: > Hash marks as line-long comment indicators is documented in slapd.conf(5). > It is also documented in recent 2.4 ldap.conf(5). It doesn't actually mention the word "comment" though. I'll tweak a bit so a search for that word will find it, and expand the examples a bit. -- Hallvard

1 0

Re: (ITS#6387) Valgrind reports issues in pcache
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD,re24,2.4.19 > OS: irrelevant? > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.146) > Submitted by: ando > > > See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> The fix to ITS#6388 fixes the first valgrind warning of this ITS. p.

1 0

(ITS#6388) A timeout of { -1, 0 } allows to never time out
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando Some code in back-ldap used a timeout of { -1, 0 } to disable any timeout set via ldap_set_option(). However, the code does not honor it (AFAIK). A fix that explicitly adds this feature is being committed (and documented in ldap_result(3)). p.

1 0

(ITS#6387) Valgrind reports issues in pcache
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD,re24,2.4.19 OS: irrelevant? URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> p.

1 0

(ITS#6386) Usage of ldap_init_fd
by vitaly.kroivets＠gmail.com 18 Nov '09

18 Nov '09

Full_Name: Vitaly Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.115.180.11) I try to use function ldap_init_fd, but it fails . ldap_init_fd (sockfd , 1 ,host_uri , &server); ... rc = ldap_simple_bind_s(server, bind_dn, password); if (rc != 0) { fprintf(stderr, "ldap_simple_bind_s: %s", (*ldap_err2string)(rc)); return 1; } rc = ldap_search_s(server, ludp->lud_dn, ludp->lud_scope, ludp->lud_filter, ludp->lud_attrs, 0, &result); ... fails with segmentation fault: #0 find_connection (ld=0x8073ae8, srv=0x807cd50, any=1) at request.c:629 #1 0x080571ba in ldap_chase_referrals (ld=0x8073a08, lr=0x807cc98, errstrp=0x807ccbc, sref=-1, hadrefp=0xbffff84c) at request.c:1356 #2 0x0804c620 in try_read1msg (ld=0x8073a08, msgid=2, all=1, lc=0x8073ae8, result=0x8071ce0) at result.c:805 #3 0x0804bab0 in wait4msg (ld=0x8073a08, msgid=2, all=1, timeout=0x8073ae8, result=0x8071ce0) at result.c:390 #4 0x0804dc5e in ldap_search_s (ld=0x8073a08, base=0x8071d80 "cn=US", scope=0, filter=0x0, attrs=0x0, attrsonly=0, res=0x8071ce0) at search.c:428 #5 0x0804ab38 in main (argc=3, argv=0xbffff9d0) at /tmp/get.c:182 (gdb) p lc $1 = (struct ldap_conn *) 0x8073ae8 (gdb) p *lc $2 = {lconn_sb = 0x807bb30, lconn_refcnt = 3, lconn_created = 0, lconn_lastused = 1258722436, lconn_rebind_inprogress = 0, lconn_rebind_queue = 0x0, lconn_status = 3, lconn_server = 0x0, lconn_ber = 0x0, lconn_next = 0x0} (gdb) quit

1 0

Re: (ITS#6383) Very Slow Query Response
by whm＠stanford.edu 18 Nov '09

18 Nov '09

--On Tuesday, November 17, 2009 09:11:23 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > > On Nov 16, 2009, at 9:03 PM, Bill MacAllister <whm(a)stanford.edu> wrote: > >> >> >> --On Monday, November 16, 2009 07:37:49 PM -0800 Quanah Gibson-Mount >> <quanah(a)zimbra.com> wrote: >> >>> >>> >>> --On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: >>> >>>> Full_Name: Bill MacAllister >>>> Version: 2.4.19+ >>>> OS: Debian 5 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (171.64.19.165) >>>> >>>> >>>> On a system where slapd is the top CPU process and is consuming 4% >>>> of the >>>> CPU simple queries are taking ten of seconds to complete. Here is >>>> an >>>> example query: >>> >>> Last time we saw this it appeared that it might be related to DNS. >>> How long does a netstat -a take on the affected systems when the >>> LDAP queries are slow? >> >> I don't have that number. I have only see it once in the test >> environment I am not sure how long it will take me to get it. Since >> this plastered the production service today, I will have to reproduce >> it though before we attempt another production upgrade. >> >> Not clear to me why a DNS issue would appear only under load and not >> at other times. And it seems strange that it appears in >> lenny/openldap-2.4 and not in etch/openldap-2.3. >> >> Bill >> >> -- >> Bill MacAllister, System Software Programmer >> Unix Systems Group, Stanford University > > For historical note this was caused by Cyrus-sasl being built > incorrectly by the debian packagers when heimdal is used. > > --Quanah I don't understand why you refer to this finding as historical. If I am reading this correctly you and Howard have found the underlying cause. Now that the problem is understood can you suggest a way for us to cause the problem in our test environments? At this point we will really need to convince ourselves that the problem is indeed fixed before we try to deploy 2.4 in our production environment again. Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 18 Nov '09

18 Nov '09

Hello, hyc(a)symas.com wrote: > Paste the debug log somewhere we can see it then. Might as well use = debug > level -1 while executing this sequence. And provide the debug output = from both > servers. I=92ve got 60MiB of log files (cumulated from both servers) from running = slapd with "-d Any=93.=20 Sadly this erroneous behavior did only happened after a couple of test = runs, so it=92s a lot of "everything works normal" in this files. The logs are available here: <url:http://pitpalme.is-a-geek.net/ldap/> They're both equal regarding contents, just compressed differently for = faster download if 'xz' as compression tool is available. The test DN that fails is "cn=3DMax = Mustermann,ou=3DbulkTestPerl,ou=3Dtest,o=3Desolution,dc=3Ddeutscherv,dc=3D= de". Thanks in advance and regards, Peter.=

1 0

(ITS#6385) Shutdown of broken syncrepl stanza cores
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando The test for SLAP_SYNC_SUBENTRY() is done on a NULL BackendDB *. A fix is coming. p.

1 0

Re: (ITS#6383) Very Slow Query Response
by rra＠stanford.edu 17 Nov '09

17 Nov '09

quanah(a)zimbra.com writes: > For historical note this was caused by Cyrus-sasl being built > incorrectly by the debian packagers when heimdal is used. Well, rather, that's a theory which currently looks good. It definitely hasn't been proven yet. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#6383) Very Slow Query Response
by quanah＠zimbra.com 17 Nov '09

17 Nov '09

On Nov 16, 2009, at 9:03 PM, Bill MacAllister <whm(a)stanford.edu> wrote: > > > --On Monday, November 16, 2009 07:37:49 PM -0800 Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: > >> >> >> --On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: >> >>> Full_Name: Bill MacAllister >>> Version: 2.4.19+ >>> OS: Debian 5 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (171.64.19.165) >>> >>> >>> On a system where slapd is the top CPU process and is consuming 4% >>> of the >>> CPU simple queries are taking ten of seconds to complete. Here is >>> an >>> example query: >> >> Last time we saw this it appeared that it might be related to DNS. >> How long does a netstat -a take on the affected systems when the >> LDAP queries are slow? > > I don't have that number. I have only see it once in the test > environment I am not sure how long it will take me to get it. Since > this plastered the production service today, I will have to reproduce > it though before we attempt another production upgrade. > > Not clear to me why a DNS issue would appear only under load and not > at other times. And it seems strange that it appears in > lenny/openldap-2.4 and not in etch/openldap-2.3. > > Bill > > -- > Bill MacAllister, System Software Programmer > Unix Systems Group, Stanford University For historical note this was caused by Cyrus-sasl being built incorrectly by the debian packagers when heimdal is used. --Quanah

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by masarati＠aero.polimi.it 17 Nov '09

17 Nov '09

> sorry for two consecutive mails but I hit send before finishing to > think... where does is this bit about comments in the manual page? It > seems I'm not able to find it (nor the search facility in man too). I'm > doing man 5 ldap.conf, the man has all the configuration variables > explained well but not a word about where to put comments. Hash marks as line-long comment indicators is documented in slapd.conf(5). It is also documented in recent 2.4 ldap.conf(5). p.

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by luca.pasquali＠dada.net 17 Nov '09

17 Nov '09

sorry for two consecutive mails but I hit send before finishing to think... where does is this bit about comments in the manual page? It seems I'm not able to find it (nor the search facility in man too). I'm doing man 5 ldap.conf, the man has all the configuration variables explained well but not a word about where to put comments.

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by luca.pasquali＠dada.net 17 Nov '09

17 Nov '09

> Not a bug. Only lines beginning with "#" are comments as documented in > ldap.conf(5). yes, it might be a cool new feature... :)

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by rein＠OpenLDAP.org 17 Nov '09

17 Nov '09

luca.pasquali(a)dada.net wrote: > in ldap.conf if i configure like this: > > dorius01 ~ # cat /etc/ldap.conf | head -2 > base dc=dada,dc=net > uri ldaps://ldap.us.backplane/ > dorius01 ~ # > > all works, but if I put a comment like this: > > dorius01 ~ # cat /etc/ldap.conf | head -2 > base dc=dada,dc=net > uri ldaps://ldap.us.backplane/ # foobar comment blah blah... > dorius01 ~ # > > this does not work at all and I'm not able to login via ldap+ssh, for istance. Not a bug. Only lines beginning with "#" are comments as documented in ldap.conf(5). Rein

1 0

(ITS#6384) ldap.conf - problem with comments
by luca.pasquali＠dada.net 17 Nov '09

17 Nov '09

Full_Name: luca pasquali Version: 2.4.19 OS: gentoo GNU/Linux URL: Submission from: (NULL) (195.110.97.5) in ldap.conf if i configure like this: dorius01 ~ # cat /etc/ldap.conf | head -2 base dc=dada,dc=net uri ldaps://ldap.us.backplane/ dorius01 ~ # all works, but if I put a comment like this: dorius01 ~ # cat /etc/ldap.conf | head -2 base dc=dada,dc=net uri ldaps://ldap.us.backplane/ # foobar comment blah blah... dorius01 ~ # this does not work at all and I'm not able to login via ldap+ssh, for istance.

1 0

Re: (ITS#6383) Very Slow Query Response
by whm＠stanford.edu 16 Nov '09

16 Nov '09

--On Monday, November 16, 2009 07:37:49 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > > --On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: > >> Full_Name: Bill MacAllister >> Version: 2.4.19+ >> OS: Debian 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.165) >> >> >> On a system where slapd is the top CPU process and is consuming 4% of the >> CPU simple queries are taking ten of seconds to complete. Here is an >> example query: > > Last time we saw this it appeared that it might be related to DNS. > How long does a netstat -a take on the affected systems when the > LDAP queries are slow? I don't have that number. I have only see it once in the test environment I am not sure how long it will take me to get it. Since this plastered the production service today, I will have to reproduce it though before we attempt another production upgrade. Not clear to me why a DNS issue would appear only under load and not at other times. And it seems strange that it appears in lenny/openldap-2.4 and not in etch/openldap-2.3. Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

1 0

Re: (ITS#6383) Very Slow Query Response
by quanah＠zimbra.com 16 Nov '09

16 Nov '09

--On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: > Full_Name: Bill MacAllister > Version: 2.4.19+ > OS: Debian 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.165) > > > On a system where slapd is the top CPU process and is consuming 4% of the > CPU simple queries are taking ten of seconds to complete. Here is an > example query: Last time we saw this it appeared that it might be related to DNS. How long does a netstat -a take on the affected systems when the LDAP queries are slow? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6383) Very Slow Query Response
by whm＠stanford.edu 16 Nov '09

16 Nov '09

Full_Name: Bill MacAllister Version: 2.4.19+ OS: Debian 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) On a system where slapd is the top CPU process and is consuming 4% of the CPU simple queries are taking ten of seconds to complete. Here is an example query: % time ldapsearch -x -h ldap1.stanford.edu -b dc=stanford,dc=edu uid=whm # extended LDIF # # LDAPv3 # base <dc=stanford,dc=edu> with scope subtree # filter: uid=whm # requesting: ALL # ...data... # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 0.001u 0.000s 0:18.13 0.0% 0+0k 0+0io 0pf+0w Here is a backtrace: ldap1:/var/log# gdb slapd 24029 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Attaching to program: /usr/sbin/slapd, process 24029 Reading symbols from /usr/lib/libtcmalloc_minimal.so.0...done. Loaded symbols for /usr/lib/libtcmalloc_minimal.so.0 Reading symbols from /usr/lib/libldap_r-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/libldap_r-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/libldap_r-2.4.so.2 Reading symbols from /usr/lib/liblber-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/liblber-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/liblber-2.4.so.2 Reading symbols from /usr/lib/libdb-4.8.so...Reading symbols from /usr/lib/debug/usr/lib/libdb-4.8.so.debug...done. done. Loaded symbols for /usr/lib/libdb-4.8.so Reading symbols from /usr/lib/libodbc.so.1...done. Loaded symbols for /usr/lib/libodbc.so.1 Reading symbols from /usr/lib/libslp.so.1...done. Loaded symbols for /usr/lib/libslp.so.1 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /usr/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/lib/libssl.so.0.9.8 Reading symbols from /usr/lib/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.8 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f89261b86f0 (LWP 24029)] [New Thread 0x44bef950 (LWP 24047)] [New Thread 0x443ee950 (LWP 24046)] [New Thread 0x40a74950 (LWP 24045)] [New Thread 0x43bed950 (LWP 24044)] [New Thread 0x433ec950 (LWP 24043)] [New Thread 0x42beb950 (LWP 24042)] [New Thread 0x423ea950 (LWP 24041)] [New Thread 0x41be9950 (LWP 24040)] [New Thread 0x413e8950 (LWP 24039)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/sasl2/libntlm.so.2...done. Loaded symbols for /usr/lib/sasl2/libntlm.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/libdb-4.6.so...done. Loaded symbols for /usr/lib/libdb-4.6.so Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/libgssapiv2.so.2...done. Loaded symbols for /usr/lib/sasl2/libgssapiv2.so.2 Reading symbols from /usr/lib/libgssapi.so.2...done. Loaded symbols for /usr/lib/libgssapi.so.2 Reading symbols from /usr/lib/libkrb5.so.25...done. Loaded symbols for /usr/lib/libkrb5.so.25 Reading symbols from /usr/lib/libasn1.so.8...done. Loaded symbols for /usr/lib/libasn1.so.8 Reading symbols from /usr/lib/libroken.so.18...done. Loaded symbols for /usr/lib/libroken.so.18 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libheimntlm.so.0...done. Loaded symbols for /usr/lib/libheimntlm.so.0 Reading symbols from /usr/lib/libhx509.so.3...done. Loaded symbols for /usr/lib/libhx509.so.3 Reading symbols from /usr/lib/libwind.so.0...done. Loaded symbols for /usr/lib/libwind.so.0 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /usr/lib/ldap/back_hdb-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/back_hdb-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/back_hdb-2.4.so.2 Reading symbols from /usr/lib/ldap/back_monitor-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/back_monitor-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/back_monitor-2.4.so.2 Reading symbols from /usr/lib/ldap/valsort-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/valsort-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/valsort-2.4.so.2 Reading symbols from /usr/lib/ldap/dynlist-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/dynlist-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/dynlist-2.4.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 0x00007f89240a0715 in pthread_join () from /lib/libpthread.so.0 (gdb) thr apply all bt Thread 10 (Thread 0x413e8950 (LWP 24039)): #0 0x00007f8923e15b78 in epoll_wait () from /lib/libc.so.6 #1 0x0000000000438fdf in slapd_daemon_task (ptr=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/daemon.c:2460 #2 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f8923e155ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 9 (Thread 0x41be9950 (LWP 24040)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df100d in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f00500 in ?? () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f00aca in sasl_encodev () from /usr/lib/libsasl2.so.2 #8 0x00007f8924f00b72 in sasl_encode () from /usr/lib/libsasl2.so.2 #9 0x00007f8925b24585 in sb_sasl_cyrus_encode (p=0x3c2e2be0, buf=0x39a3740 "0\202\001�002\001\004d\202\001�\004*uid=carimer,cn=accounts,dc=stanford,dc=edu0\202\001\2170>\004\tsuService11\004\006dialin\004\003afs\004\006leland\004\005email\004\003pts\004\004seas\004\bkerberos0\020\004\003uid1\t\004\acarimer0\034\004\020suKerberosStatus1\b\004\006active0\031\004\rsuEmailStatus1\b\004\006active0\201"..., len=458, dst=0x3c2e2c50) at cyrus.c:165 #10 0x00007f8925b298a1 in sb_sasl_generic_write (sbiod=0x37a3f420, buf=0x39a3740, len=458) at sasl.c:716 #11 0x00007f8925905b70 in sb_debug_write (sbiod=0x3c2feb10, buf=0x39a3740, len=458) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:852 #12 0x00007f8925904f61 in ber_int_sb_write (sb=0x3ca3d300, buf=0x39a3740, len=458) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:445 #13 0x00007f892590112e in ber_flush2 (sb=0x3ca3d300, ber=0x41a674e0, freeit=0) at /tmp/buildd/openldap-2.4.19/libraries/liblber/io.c:246 #14 0x0000000000451c56 in send_ldap_ber (op=0x3a875800, ber=0x41a674e0) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:191 #15 0x0000000000455857 in slap_send_search_entry (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:1260 #16 0x00007f8920597320 in hdb_search (op=0x3a875800, rs=0x41be8c90) at search.c:961 #17 0x00000000004c70be in overlay_op_walk (op=0x3a875800, rs=0x41be8c90, which=op_search, oi=0x2e0fa00, on=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:669 #18 0x00000000004c72e5 in over_op_func (op=0x3a875800, rs=0x41be8c90, which=op_search) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:721 #19 0x00000000004c73b3 in over_op_search (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:748 #20 0x0000000000440844 in fe_op_search (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #21 0x00000000004401af in do_search (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #22 0x000000000043cbd6 in connection_operation (ctx=0x41be8de0, arg_v=0x3a875800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #23 0x000000000043d162 in connection_read_thread (ctx=0x41be8de0, argv=0x91) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #24 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #25 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #26 0x00007f8923e155ad in clone () from /lib/libc.so.6 #27 0x0000000000000000 in ?? () Thread 8 (Thread 0x423ea950 (LWP 24041)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df18a4 in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #7 0x00000000004a85d0 in slap_sasl_bind (op=0x3bb9b800, rs=0x423e9c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1528 #8 0x0000000000464126 in fe_op_bind (op=0x3bb9b800, rs=0x423e9c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #9 0x0000000000463d2b in do_bind (op=0x3bb9b800, rs=0x423e9c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #10 0x000000000043cbd6 in connection_operation (ctx=0x423e9de0, arg_v=0x3bb9b800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #11 0x000000000043d162 in connection_read_thread (ctx=0x423e9de0, argv=0x94) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #12 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #13 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f8923e155ad in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () Thread 7 (Thread 0x42beb950 (LWP 24042)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df16f0 in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f0510e in sasl_server_start () from /usr/lib/libsasl2.so.2 #8 0x00000000004a8599 in slap_sasl_bind (op=0x340cd800, rs=0x42beac90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1522 #9 0x0000000000464126 in fe_op_bind (op=0x340cd800, rs=0x42beac90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #10 0x0000000000463d2b in do_bind (op=0x340cd800, rs=0x42beac90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #11 0x000000000043cbd6 in connection_operation (ctx=0x42beade0, arg_v=0x340cd800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #12 0x000000000043d162 in connection_read_thread (ctx=0x42beade0, argv=0x29) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #13 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #14 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #15 0x00007f8923e155ad in clone () from /lib/libc.so.6 #16 0x0000000000000000 in ?? () Thread 6 (Thread 0x433ec950 (LWP 24043)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df100d in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f00500 in ?? () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f00aca in sasl_encodev () from /usr/lib/libsasl2.so.2 #8 0x00007f8924f00b72 in sasl_encode () from /usr/lib/libsasl2.so.2 #9 0x00007f8925b24585 in sb_sasl_cyrus_encode (p=0x2e29e000, buf=0xe58cc10 "0\r\002\002\004He\a\n\001", len=15, dst=0x2e29e070) at cyrus.c:165 #10 0x00007f8925b298a1 in sb_sasl_generic_write (sbiod=0x2e3f50f0, buf=0xe58cc10, len=15) at sasl.c:716 #11 0x00007f8925905b70 in sb_debug_write (sbiod=0x2e389b70, buf=0xe58cc10, len=15) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:852 #12 0x00007f8925904f61 in ber_int_sb_write (sb=0x2e3b88d0, buf=0xe58cc10, len=15) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:445 #13 0x00007f892590112e in ber_flush2 (sb=0x2e3b88d0, ber=0x4326a480, freeit=0) at /tmp/buildd/openldap-2.4.19/libraries/liblber/io.c:246 #14 0x0000000000451c56 in send_ldap_ber (op=0x33ce9400, ber=0x4326a480) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:191 #15 0x00000000004528a1 in send_ldap_response (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:548 #16 0x00000000004531ee in slap_send_ldap_result (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:706 #17 0x00007f892059765d in hdb_search (op=0x33ce9400, rs=0x433ebc90) at search.c:1028 #18 0x00000000004c70be in overlay_op_walk (op=0x33ce9400, rs=0x433ebc90, which=op_search, oi=0x2e0fa00, on=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:669 #19 0x00000000004c72e5 in over_op_func (op=0x33ce9400, rs=0x433ebc90, which=op_search) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:721 #20 0x00000000004c73b3 in over_op_search (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:748 #21 0x0000000000440844 in fe_op_search (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #22 0x00000000004401af in do_search (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #23 0x000000000043cbd6 in connection_operation (ctx=0x433ebde0, arg_v=0x33ce9400) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #24 0x000000000043d162 in connection_read_thread (ctx=0x433ebde0, argv=0x17) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #25 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #26 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #27 0x00007f8923e155ad in clone () from /lib/libc.so.6 #28 0x0000000000000000 in ?? () Thread 5 (Thread 0x43bed950 (LWP 24044)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2ebbed8) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x000000000043c414 in connection_next (c=0x2ebbec0, index=0x43beb96c) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:893 #5 0x00007f892036adfa in monitor_subsys_conn_create (op=0x32d96c00, rs=0x43becc90, ndn=0x0, e_parent=0x3b680f8, ep=0x43beba48) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/conn.c:500 #6 0x00007f8920365077 in monitor_entry_create (op=0x32d96c00, rs=0x43becc90, ndn=0x0, e_parent=0x3b680f8, ep=0x43beba48) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/entry.c:90 #7 0x00007f8920363420 in monitor_send_children (op=0x32d96c00, rs=0x43becc90, e_parent=0x3b680f8, sub=1) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/search.c:53 #8 0x00007f89203635c7 in monitor_send_children (op=0x32d96c00, rs=0x43becc90, e_parent=0x3b68058, sub=1) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/search.c:123 #9 0x00007f8920363a13 in monitor_back_search (op=0x32d96c00, rs=0x43becc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/search.c:245 #10 0x0000000000440844 in fe_op_search (op=0x32d96c00, rs=0x43becc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #11 0x00000000004401af in do_search (op=0x32d96c00, rs=0x43becc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #12 0x000000000043cbd6 in connection_operation (ctx=0x43becde0, arg_v=0x32d96c00) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #13 0x000000000043d162 in connection_read_thread (ctx=0x43becde0, argv=0x69) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #14 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #15 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #16 0x00007f8923e155ad in clone () from /lib/libc.so.6 #17 0x0000000000000000 in ?? () Thread 4 (Thread 0x40a74950 (LWP 24045)): #0 0x00007f8923e0ece2 in select () from /lib/libc.so.6 #1 0x00007f892193e729 in ?? () from /usr/lib/libkrb5.so.25 #2 0x00007f892193edce in krb5_sendto () from /usr/lib/libkrb5.so.25 #3 0x00007f892193f06f in krb5_sendto_context () from /usr/lib/libkrb5.so.25 #4 0x00007f892191eb34 in ?? () from /usr/lib/libkrb5.so.25 #5 0x00007f892191efbf in ?? () from /usr/lib/libkrb5.so.25 #6 0x00007f892191f89b in ?? () from /usr/lib/libkrb5.so.25 #7 0x00007f892191f94e in ?? () from /usr/lib/libkrb5.so.25 #8 0x00007f8921920054 in krb5_get_credentials_with_flags () from /usr/lib/libkrb5.so.25 #9 0x00007f89219300c2 in krb5_mk_req_exact () from /usr/lib/libkrb5.so.25 #10 0x00007f8921919a9c in ?? () from /usr/lib/libkrb5.so.25 #11 0x00007f8921919eb8 in krb5_digest_probe () from /usr/lib/libkrb5.so.25 #12 0x00007f8921bddf1b in ?? () from /usr/lib/libgssapi.so.2 #13 0x00007f8921bdbcd9 in ?? () from /usr/lib/libgssapi.so.2 #14 0x00007f8921bd60cc in gss_acquire_cred () from /usr/lib/libgssapi.so.2 #15 0x00007f8921be13f1 in ?? () from /usr/lib/libgssapi.so.2 #16 0x00007f8921bd60cc in gss_acquire_cred () from /usr/lib/libgssapi.so.2 #17 0x00007f8921df17ef in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #18 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #19 0x00007f8924f0510e in sasl_server_start () from /usr/lib/libsasl2.so.2 #20 0x00000000004a8599 in slap_sasl_bind (op=0x3c185800, rs=0x40a73c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1522 #21 0x0000000000464126 in fe_op_bind (op=0x3c185800, rs=0x40a73c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #22 0x0000000000463d2b in do_bind (op=0x3c185800, rs=0x40a73c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #23 0x000000000043cbd6 in connection_operation (ctx=0x40a73de0, arg_v=0x3c185800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #24 0x000000000043d162 in connection_read_thread (ctx=0x40a73de0, argv=0x93) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #25 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #26 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #27 0x00007f8923e155ad in clone () from /lib/libc.so.6 #28 0x0000000000000000 in ?? () Thread 3 (Thread 0x443ee950 (LWP 24046)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df1c8e in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #7 0x00000000004a85d0 in slap_sasl_bind (op=0x354b8c00, rs=0x443edc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1528 #8 0x0000000000464126 in fe_op_bind (op=0x354b8c00, rs=0x443edc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #9 0x0000000000463d2b in do_bind (op=0x354b8c00, rs=0x443edc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #10 0x000000000043cbd6 in connection_operation (ctx=0x443edde0, arg_v=0x354b8c00) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #11 0x000000000043d162 in connection_read_thread (ctx=0x443edde0, argv=0x96) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #12 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #13 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f8923e155ad in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () Thread 2 (Thread 0x44bef950 (LWP 24047)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df100d in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f00500 in ?? () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f00aca in sasl_encodev () from /usr/lib/libsasl2.so.2 #8 0x00007f8924f00b72 in sasl_encode () from /usr/lib/libsasl2.so.2 #9 0x00007f8925b24585 in sb_sasl_cyrus_encode (p=0x3c934960, buf=0xfdea740 "0\202\001�002\001\004d\202\001�\004(uid=tayah,cn=accounts,dc=stanford,dc=edu0\202\001\2150>\004\tsuService11\004\006dialin\004\003afs\004\006leland\004\005email\004\004seas\004\003pts\004\bkerberos0\016\004\003uid1\a\004\005tayah0\034\004\020suKerberosStatus1\b\004\006active0\031\004\rsuEmailStatus1\b\004\006active0\201�\004\vo"..., len=454, dst=0x3c9349d0) at cyrus.c:165 #10 0x00007f8925b298a1 in sb_sasl_generic_write (sbiod=0x3cb61690, buf=0xfdea740, len=454) at sasl.c:716 #11 0x00007f8925905b70 in sb_debug_write (sbiod=0x3ca07cc0, buf=0xfdea740, len=454) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:852 #12 0x00007f8925904f61 in ber_int_sb_write (sb=0x3caca750, buf=0xfdea740, len=454) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:445 #13 0x00007f892590112e in ber_flush2 (sb=0x3caca750, ber=0x44a6d4e0, freeit=0) at /tmp/buildd/openldap-2.4.19/libraries/liblber/io.c:246 #14 0x0000000000451c56 in send_ldap_ber (op=0x3c185000, ber=0x44a6d4e0) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:191 #15 0x0000000000455857 in slap_send_search_entry (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:1260 #16 0x00007f8920597320 in hdb_search (op=0x3c185000, rs=0x44beec90) at search.c:961 #17 0x00000000004c70be in overlay_op_walk (op=0x3c185000, rs=0x44beec90, which=op_search, oi=0x2e0fa00, on=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:669 #18 0x00000000004c72e5 in over_op_func (op=0x3c185000, rs=0x44beec90, which=op_search) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:721 #19 0x00000000004c73b3 in over_op_search (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:748 #20 0x0000000000440844 in fe_op_search (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #21 0x00000000004401af in do_search (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #22 0x000000000043cbd6 in connection_operation (ctx=0x44beede0, arg_v=0x3c185000) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #23 0x000000000043d162 in connection_read_thread (ctx=0x44beede0, argv=0x82) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #24 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #25 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #26 0x00007f8923e155ad in clone () from /lib/libc.so.6 #27 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f89261b86f0 (LWP 24029)): #0 0x00007f89240a0715 in pthread_join () from /lib/libpthread.so.0 #1 0x00007f8925b1c5f3 in ldap_pvt_thread_join (thread=1094617424, thread_return=0x0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:197 #2 0x0000000000439d2e in slapd_daemon () at /tmp/buildd/openldap-2.4.19/servers/slapd/daemon.c:2835 #3 0x000000000041afdd in main (argc=3, argv=0x7fff0941e0b8) at /tmp/buildd/openldap-2.4.19/servers/slapd/main.c:950 #0 0x00007f89240a0715 in pthread_join () from /lib/libpthread.so.0 (gdb)

1 0

(ITS#6382) Error in set example (groups of groups)
by andreas＠canonical.com 16 Nov '09

16 Nov '09

Full_Name: Andreas Hasenack Version: head OS: linux URL: ftp://ftp.openldap.org/incoming/andreas-hasenack-091116.tar.gz Submission from: (NULL) (63.133.153.66) The picture set-recursivegroup.png has a typo in the reference to accountadm. It should be under ou=group, not ou=people, in the upper left box. For reference, it's published here: http://www.openldap.org/doc/admin24/access-control.html#Sets%20-%20Granting… The andreas-hasenack-091116.tar.gz tarball I'm uploading has a fixed .svg file (the source) as well as an exported png one. I wrongly uploaded that file as openldap-guide-fix.tar.gz: you can delete that one.

1 0

RE : RE : (ITS#6367) syncprov ... changed by peer, ignored
by olivier.chirossel＠sfr.com 16 Nov '09

16 Nov '09

i made the test look's good thank's Regard's=20 Olivier ________________________________________ De : Howard Chu [hyc(a)symas.com] Date d'envoi : dimanche 15 novembre 2009 19:16 =C0 : CHIROSSEL Olivier Cc : openldap-its(a)openldap.org Objet : Re: RE : (ITS#6367) syncprov ... changed by peer, ignored CHIROSSEL Olivier wrote: > sorry for this > > the url is ok now Thanks. This is now fixed in HEAD. > > Cdt, > > Olivier > ________________________________________ > De : Howard Chu [hyc(a)symas.com] > Date d'envoi : vendredi 13 novembre 2009 23:33 > =C0 : CHIROSSEL Olivier > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#6367) syncprov ... changed by peer, ignored > > olivier.chirossel(a)sfr.com wrote: >> Full_Name: olivier chirossel >> Version: 2.4.17 and 2.4.19 >> OS: linux >> URL: http://86.64.145.174:8080/ >> Submission from: (NULL) (62.39.9.251) >> >> >> in refreshend persist mode, the replication is incorrect for an entry wh= ich be >> delete/add after master restart and before the reconnection of the slave= . > >> 2) master set up >> >> on /etc/openldap tar xvf slapd_master.tar (get on the url ) > > The URL you provided always times out for me, so I've been unable to set = up > this test. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs