RE: (ITS#7198) slapd coredumps when Master server unavailable
by andre.cardinal＠bell.ca
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.
11 years, 7 months
Re: (ITS#7198) slapd coredumps when Master server unavailable
by michael＠stroeder.com
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--
11 years, 7 months
(ITS#7198) slapd coredumps when Master server unavailable
by andre.cardinal＠bell.ca
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>
11 years, 7 months
(ITS#7197) olcTLSVerifyClient missing options
by quanah＠OpenLDAP.org
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.
11 years, 7 months
(ITS#7196) libmdb: MDB_COMMIT_PAGES greater than IOV_MAX causes mdb_txn_commit failures
by roy.keene＠us.army.mil
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.
11 years, 7 months
Re: (ITS#7191) libmdb: Alignment of MDB_db members
by roy.s.keene＠usace.army.mil
Hallvard,
This also works. My naive approach was due to working out what
the issue was with the original assigment and then trying to determine
which members were not aligned correctly.
Thanks,
Roy Keene
On Fri, 2 Mar 2012, Hallvard B Furuseth wrote:
> On Fri, 2 Mar 2012 08:03:00 GMT, roy.keene(a)us.army.mil wrote:
>> Breaking the assignment into an assignment of its members and using
>> the existing COPY_PGNO() alleviates this fault.
>
> memcpy would be simpler, if it is 'db' which is unaligned.
> Try this instead.
>
> --- mdb.c~ 2012-03-02 11:23:21
> +++ mdb.c 2012-03-02 11:25:06
> @@ -4699,4 +4699,3 @@ mdb_xcursor_init1(MDB_cursor *mc, MDB_no
> if (node->mn_flags & F_SUBDATA) {
> - MDB_db *db = NODEDATA(node);
> - mx->mx_db = *db;
> + memcpy(&mx->mx_db, NODEDATA(node), sizeof(MDB_db));
> mx->mx_cursor.mc_snum = 0;
>
>
--
(U) Roy Keene
(U) US Army Corps of Engineers IT (ACE-IT)
(U) Contractor
11 years, 7 months
(ITS#7193)
by barlone＠yandex.ru
Good day!
I found problem: function under macro BACKSQL_STR2ID incorrectly work with 'zerofilled' values/fields (for example "000009")
------------------------------------------
Best regards,
mailto:barlone@yandex.ru
11 years, 7 months
(ITS#7193)
by barlone＠yandex.ru
Good day!
I found some hint:
if define BACKSQL_ARBITRARY_KEY in back-sql.h, then all records presents in search result,
BUT LDAP entry do not contain any attribute! Just empty. Maybe it is another bug?
------------------------------------------
Best regards,
mailto:barlone@yandex.ru
11 years, 7 months
