openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

(ITS#7201) back-shell slapd.conf->cn=config conversion broken
by quanah＠OpenLDAP.org 07 Mar '12

07 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.28 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) As reported to the debian bug tracker. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662940

1 0

(ITS#7200) serverID 0 after serverID should fail loudly
by ebackes＠symas.com 05 Mar '12

05 Mar '12

Full_Name: Emily Backes Version: 2.4 OS: any URL: Submission from: (NULL) (98.155.30.248) This is an enhancement request, based on discussions and common failing use-cases we've encountered. Very often, people configure: serverID 1 ldap:... serverID 2 ldap:... ...etc... And for various reasons none of the ldap URIs match the local server and they end up in a faux-mmr where every server believes itself to be zero, resulting in great consternation when replication then fails awkwardly farther down the line. It's only meaningful to set serverID on "master" servers-- those accepting changes, so it seems reasonable to require that one of the serverIDs matches. This is probably easiest to enforce by requiring: * If serverID is zero, mirrormode must be off. Turning mirrormode on should require a non-zero serverID beforehand. It would be nice to test this at serverID setting time, but that requires state checking beyond what is easily provided to the config table, I think. Namely, if any serverIDs are specified, one of them must match and set to a non-zero value; any null serverID after all serverID num/uri pairs are considered should cause the config change or slapd.conf to be rejected. It's also possible that the is-this-a-local-change checks in syncprov.c may want to handle serverID 0 CSNs specially; they must exist only as part of a shared change-set that existed before the current mmr topology. New CSNs appearing with serverID 0 are evidence of unrecoverable misconfiguration.

1 0

(ITS#7199) back-mdb virtual process size unreasonable
by quanah＠OpenLDAP.org 05 Mar '12

05 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.29 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) A slapd server with accesslog & primary DB, where primary DB is 131MB and accesslog is 4.1MB has the following profile in top: 5929 zimbra 21 0 160g 105m 52m S 0.7 2.7 19:35.62 slapd where 160g is the virtual size, 105m is RES, 52m is shared 160gb for this seems somewhat... obscene. ;) My guess would be a memory leak?

1 0

RE: (ITS#7198) slapd coredumps when Master server unavailable
by andre.cardinal＠bell.ca 05 Mar '12

05 Mar '12

Thanks for your reply. These systems are in PRODuction...(not a playground) I am in the process of building our lab with the same configs. Just one question. When selecting refreshandpersist as the replication type, do we need to specify intervals, and retriess values? I think my setting of Intervals=00:00:00:10 Retries="30 +" May have starved the system by running out of file descriptors. -----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: March-05-12 10:16 AM To: Cardinal, Andre (520972) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7198) slapd coredumps when Master server unavailable andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.4.24 > OS: Oracle (Solaris) 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.47.249.246) > > > Our Openldap Master server crashed with a hardware memory error and the > slave/replica, which is read only, coredumped 2 hours later, and would coredump > 4 minutes after restarting slapd thereafter. Can you check whether that also happens with recent release 2.4.30? If yes, it would be helpful if you install OpenLDAP with debug symbols and grab a stack trace etc. See "What information should I provide when reporting an issue (bug)?": http://www.openldap.org/faq/data/cache/59.html Ciao, Michael.

1 0

Re: (ITS#7198) slapd coredumps when Master server unavailable
by michael＠stroeder.com 05 Mar '12

05 Mar '12

This is a cryptographically signed message in MIME format. --------------ms080906060103080409010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.4.24 > OS: Oracle (Solaris) 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.47.249.246) > > > Our Openldap Master server crashed with a hardware memory error and the= > slave/replica, which is read only, coredumped 2 hours later, and would= coredump > 4 minutes after restarting slapd thereafter. Can you check whether that also happens with recent release 2.4.30? If ye= s, it=20 would be helpful if you install OpenLDAP with debug symbols and grab a st= ack=20 trace etc. See "What information should I provide when reporting an issue (bug)?": http://www.openldap.org/faq/data/cache/59.html Ciao, Michael. --------------ms080906060103080409010309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwNTE1MTYxNFowIwYJKoZIhvcNAQkEMRYE FKAKYri2D9e4IJCdixF14t7Nk/MyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAoUCDo8hQNS6bro13hDJb4XbtSNMWvrlHx6haTIwDJbarSKJlBo8TVnax1cCdgC6SByGB 6wIejSS1yfC0Lh+yg+kQebnXY975kCMKjvUcDdjAIuEfYT6NCa1MxWzakprkkIH2YPDyILNx Tc5wqNn/EZX/2aMLrMlvvaGiN3nlqp0IgRzpMTMibOD/oX2oIm4vd5cJqCNBc9N0LTbHhoAK VoD/knw3ELQnQ+Kmi7Q6cJDVQRrIeUK6UqIP1edIMKT/UsYXucZziE8SzGmoTmv+EQwnefEx Y/FVgQ2ETRu3e5iwIYOMZorSTjUsw++yIuIDXz/mT7BA+ZHX+1w7tsyLxQAAAAAAAA== --------------ms080906060103080409010309--

1 0

(ITS#7198) slapd coredumps when Master server unavailable
by andre.cardinal＠bell.ca 05 Mar '12

05 Mar '12

Full_Name: Andre Cardinal Version: 2.4.24 OS: Oracle (Solaris) 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.47.249.246) Our Openldap Master server crashed with a hardware memory error and the slave/replica, which is read only, coredumped 2 hours later, and would coredump 4 minutes after restarting slapd thereafter. Disabling syncrepl stopped the coredumps. (i.e. commenting out all the lines in the syncrepl portion of slapd.conf in the replica. See following. Text in <> is sanitized for obvious reasons. # # 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 include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/ces.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/openldap-run/slapd.pid argsfile /usr/local/var/openldap-run/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la allow bind_v2 loglevel 256 #loglevel 4095 #logfile /var/log/ldap.log # The next three lines allow use of TLS for encrypting connections using a # test certificate #TLSCACertificateFile /usr/local/etc/openldap/certs/test_with_ca.pem #TLSCertificateFile /usr/local/etc/openldap/certs/test_with_ca.pem #TLSCertificateKeyFile /usr/local/etc/openldap/certs/test_with_ca.pem #ICM Certs for PROD TLSCACertificateFile /usr/local/etc/openldap/certs/Slave-ICM.pem TLSCertificateFile /usr/local/etc/openldap/certs/Slave-ICM.pem TLSCertificateKeyFile /usr/local/etc/openldap/certs/Slave-ICM.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! #configure timelimits and sizelimits sizelimit unlimited timelimit unlimited ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "<suffix>" rootdn "<Root DN>" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}<encrypted password> # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data #directory /data/openldap # Indices to maintain index objectClass eq index cesSubjectDN eq,pres index cn eq # #Equality Indexing for Replication # index entryCSN,entryUUID eq syncrepl rid=123 provider=ldap://<Master Server> type=refreshAndPersist interval=00:00:00:10 retry="30 +" searchbase="<suffix>" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=<bindDN>" credentials=<password>

1 0

(ITS#7197) olcTLSVerifyClient missing options
by quanah＠OpenLDAP.org 04 Mar '12

04 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.30 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) >From the manual page: olcTLSVerifyClient: <level> Specifies what checks to perform on client certificates in an incoming TLS session, if any. The <level> can be specified as one of the following keywords: never This is the default. slapd will not ask the client for a certificate. allow The client certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the ses- sion proceeds normally. try The client certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately ter- minated. demand | hard | true These keywords are all equivalent, for compatibility rea- sons. The client certificate is requested. If no cer- tificate is provided, or a bad certificate is provided, the session is immediately terminated. Note that a valid client certificate is required in order to use the SASL EXTERNAL authentication mechanism with a TLS session. As such, a non-default olcTLSVerifyClient setting must be chosen to enable SASL EXTERNAL authenti- cation. However, the code has: static slap_verbmasks vfykeys[] = { { BER_BVC("never"), LDAP_OPT_X_TLS_NEVER }, { BER_BVC("demand"), LDAP_OPT_X_TLS_DEMAND }, { BER_BVC("try"), LDAP_OPT_X_TLS_TRY }, { BER_BVC("hard"), LDAP_OPT_X_TLS_HARD }, { BER_BVNULL, 0 } }; Which means: a) allow is missing b) true is missing c) demand and hard set different flags. Not sure if that means any difference functionality wise, but according to the manual page, demand/true/hard are supposed to be the same behavior.

1 0

(ITS#7196) libmdb: MDB_COMMIT_PAGES greater than IOV_MAX causes mdb_txn_commit failures
by roy.keene＠us.army.mil 02 Mar '12

02 Mar '12

Full_Name: Roy Keene Version: 2.4.30 OS: Solaris 10 URL: Submission from: (NULL) (140.194.193.14) libmdb uses writev() to write data to a file descriptor, however it can request that writev() write more blocks than IOV_MAX causing mdb txn errors to be reported to the LDAP client. MDB_COMMIT_PAGES should not be defined to be greater than IOV_MAX. IOV_MAX on Solaris 10 is 16.

1 0

Re: (ITS#7195) delta-syncrepl fails to fallback on some errors
by hyc＠symas.com 02 Mar '12

02 Mar '12

ebackes(a)symas.com wrote: > Full_Name: Emily Backes > Version: 2.4 > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.155.30.248) > > > The delta-syncrepl code checks an explicit list of failure codes for cases that > merit falling back to syncrepl to regain syncronization. This list is missing a > few; in particular, rc=66 (Not a leaf!) slips through and creates a retry loop. Thanks, fixed in git master. -- -- 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#7195) delta-syncrepl fails to fallback on some errors
by ebackes＠symas.com 02 Mar '12

02 Mar '12

Full_Name: Emily Backes Version: 2.4 OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.155.30.248) The delta-syncrepl code checks an explicit list of failure codes for cases that merit falling back to syncrepl to regain syncronization. This list is missing a few; in particular, rc=66 (Not a leaf!) slips through and creates a retry loop.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs