May 2012 - openldap-bugs

Re: (ITS#7280) accesslog write to subentry of log database

by openldap＠stormcloud9.net

This is a multi-part message in MIME format. --------------060900070300040405040602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sent: Sun May 27 2012 19:02:08 GMT-0400 (EDT) From: Howard Chu <hyc(a)symas.com> To: openldap(a)stormcloud9.net openldap-its(a)openldap.org Subject: Re: (ITS#7280) accesslog write to subentry of log database > openldap(a)stormcloud9.net wrote: >> Full_Name: Patrick Hemmer >> Version: 2.4.31 >> OS: Linux RHEL6 >> URL: >> Submission from: (NULL) (98.211.220.204) >> >> >> This is a feature request (mostly). >> >> Currently the accesslog overlay is only capable of writing to the >> base DN of a >> log database, and not a subentry of that database. Specifying the DN >> to a >> specific subentry for the "logdb" parameter ends up writing to the >> base DN of >> the database instead. >> >> The main reason for this is so that multiple accesslog overlays can >> write to the >> same backend database, and not have to create a separate database for >> each >> overlay. Currently if you try to give multiple accesslog overlays the >> same >> database, it causes deadlock issues (or it appears to be a deadlock) >> and write >> operations end up hanging. I'm not sure if this should be considered >> a bug, or >> just noted as "don't try and do that". > > Don't do that. Closing this ITS. > This is nonconstructive. I know not to do that, I'm the one who filed the ITS... You don't address the feature request at all, only that it currently doesn't work which is why the request was filed in the first place. Is logging multiple accesslog overlays to the same backend database unfeasible? -Patrick --------------060900070300040405040602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000066"> Sent: Sun May 27 2012 19:02:08 GMT-0400 (EDT) From: Howard Chu <a class="moz-txt-link-rfc2396E" href="mailto:hyc@symas.com"><hyc(a)symas.com></a> To: <a class="moz-txt-link-abbreviated" href="mailto:openldap@stormcloud9.net">openldap(a)stormcloud9.net</a> <a class="moz-txt-link-abbreviated" href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a> Subject: Re: (ITS#7280) accesslog write to subentry of log database <blockquote cite="mid:4FC2B270.9090900@symas.com" type="cite"><a class="moz-txt-link-abbreviated" href="mailto:openldap@stormcloud9.net">openldap(a)stormcloud9.net</a> wrote: <blockquote type="cite">Full_Name: Patrick Hemmer Version: 2.4.31 OS: Linux RHEL6 URL: Submission from: (NULL) (98.211.220.204) This is a feature request (mostly). Currently the accesslog overlay is only capable of writing to the base DN of a log database, and not a subentry of that database. Specifying the DN to a specific subentry for the "logdb" parameter ends up writing to the base DN of the database instead. The main reason for this is so that multiple accesslog overlays can write to the same backend database, and not have to create a separate database for each overlay. Currently if you try to give multiple accesslog overlays the same database, it causes deadlock issues (or it appears to be a deadlock) and write operations end up hanging. I'm not sure if this should be considered a bug, or just noted as "don't try and do that". </blockquote> Don't do that. Closing this ITS. </blockquote> This is nonconstructive. I know not to do that, I'm the one who filed the ITS... You don't address the feature request at all, only that it currently doesn't work which is why the request was filed in the first place. Is logging multiple accesslog overlays to the same backend database unfeasible? -Patrick </body> </html> --------------060900070300040405040602--

11 years, 4 months

1
0
0 / 0

Re: (ITS#7280) accesslog write to subentry of log database

by hyc＠symas.com

openldap(a)stormcloud9.net wrote: > Full_Name: Patrick Hemmer > Version: 2.4.31 > OS: Linux RHEL6 > URL: > Submission from: (NULL) (98.211.220.204) > > > This is a feature request (mostly). > > Currently the accesslog overlay is only capable of writing to the base DN of a > log database, and not a subentry of that database. Specifying the DN to a > specific subentry for the "logdb" parameter ends up writing to the base DN of > the database instead. > > The main reason for this is so that multiple accesslog overlays can write to the > same backend database, and not have to create a separate database for each > overlay. Currently if you try to give multiple accesslog overlays the same > database, it causes deadlock issues (or it appears to be a deadlock) and write > operations end up hanging. I'm not sure if this should be considered a bug, or > just noted as "don't try and do that". Don't do that. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

11 years, 4 months

1
0
0 / 0

(ITS#7281) [cxx sasl] Gentoo build 2.4.31-r1 gcc-4.7 SaslInteractionHandler.cpp

by nheghathivhistha＠gmail.com

Full_Name: David Kredba Version: 2.4.31 OS: GNU/Linux-3.4.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.112.13.17) make[2]: Entering directory `/var/tmp/portage/net-nds/openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' /bin/sh ../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -O2 -pipe -ggdb -march=native -D_GNU_SOURCE -c -o SaslInteractionHandler.lo SaslInteractionHandler.cpp x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -O2 -pipe -ggdb -march=native -D_GNU_SOURCE -c SaslInteractionHandler.cpp -fPIC -DPIC -o .libs/SaslInteractionHandler.o SaslInteractionHandler.cpp: In member function ‘virtual void DefaultSaslInteractionHandler::handleInteractions(const std::list<SaslInteraction*>&)’: SaslInteractionHandler.cpp:56:27: error: ‘STDIN_FILENO’ was not declared in this scope SaslInteractionHandler.cpp:67:27: error: ‘STDIN_FILENO’ was not declared in this scope SaslInteractionHandler.cpp:85:23: error: ‘STDIN_FILENO’ was not declared in this scope make[2]: *** [SaslInteractionHandler.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' make: *** [all-recursive] Error 1 * ERROR: net-nds/openldap-2.4.31-r1 failed (compile phase): * emake failed I tried to add someof Google suggested header files (unistd.h etc) but no luck. Thank you.

11 years, 4 months

1
0
0 / 0

Re: (ITS#7277) Slapadd segfaults if binddn contains ou or dc statements

by quanah＠zimbra.com

--On Monday, May 21, 2012 5:27 PM +0000 o.loch(a)gmx.net wrote: > > --Apple-Mail=_E91EDB34-885C-4527-B3A7-0CF927EAA88D > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=iso-8859-1 > > Hello, > > thanks for the reply. I followed your advice and played a bit with it = > and now it's working. > > It's interesting that you always have to include the core.schema even if = > you use a replicated config. <http://dictionary.reference.com/browse/core?s=t> noun 2. the central, innermost, or most essential part of anything. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

11 years, 4 months

1
0
0 / 0

(ITS#7280) accesslog write to subentry of log database

by openldap＠stormcloud9.net

Full_Name: Patrick Hemmer Version: 2.4.31 OS: Linux RHEL6 URL: Submission from: (NULL) (98.211.220.204) This is a feature request (mostly). Currently the accesslog overlay is only capable of writing to the base DN of a log database, and not a subentry of that database. Specifying the DN to a specific subentry for the "logdb" parameter ends up writing to the base DN of the database instead. The main reason for this is so that multiple accesslog overlays can write to the same backend database, and not have to create a separate database for each overlay. Currently if you try to give multiple accesslog overlays the same database, it causes deadlock issues (or it appears to be a deadlock) and write operations end up hanging. I'm not sure if this should be considered a bug, or just noted as "don't try and do that".

11 years, 4 months

1
0
0 / 0

Re: (ITS#7279) Apparently mdb "approx" index generation failure for mdb_add for syncrepl consumer

by brandon.hume＠dal.ca

On 05/24/12 02:08 PM, Michael Ströder wrote: > Are these the exact logs lines? I'm asking because $DN sounds to me like a > variable name used in a configuration template. Can cou please check that? No, that was me editing the line. Sorry, I should have labeled it as such.

11 years, 4 months

1
0
0 / 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes

by michael＠stroeder.com

This is a cryptographically signed message in MIME format. --------------ms080105030301050607030109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable fumiyas(a)osstech.co.jp wrote: > Full_Name: SATOH Fumiyasu > Version: master > OS:=20 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.p= atch > Submission from: (NULL) (220.100.28.128) >=20 >=20 > This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes= > to slapd-sha2 module. >=20 > This patch depends on > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch > (http://www.openldap.org/its/index.cgi?findid=3D7269). I've not tested the patch yet. But I'd appreciate if SHA-2 support would = be available in the main source and not only under contrib/. Any objections against extending libraries/liblutil/passwd.c? Ciao, Michael. --------------ms080105030301050607030109 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyNDE4MDEzOFowIwYJKoZIhvcNAQkEMRYE FBBgedro2DSLuBwkyOrjr9ML7MbLMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAV8R0Hvk9iikbkpo4qm7yXeMwCsMbrDGhTWapYclEgt0tOJNJ945Zejk4slxyhECYfRDf 0BSn5GX8RKSzas408ybxgWfCeviPhHZhjB5+akya8OcFmyQ/eoGHFeK0uZNlG2PPs42dNgf9 Zi6P0vrfF/L+Nn9PsurDrKIkV5HOMwbm7tAJdpfkOVsmW1S50Wx18PjgjSs2DujKh8HYq211 BsdE19cU3IfMZPOdVW+GTSZmpJdzr4Zl8H9jtoyNiH4JHoSqI2eXlIQGqP+2x2Koj6F/il0r BXIxhEMN88wcp0QhX2TERg32wqKhLUK2kns2n75NyKEFh1sbo5v+SAQndQAAAAAAAA== --------------ms080105030301050607030109--

11 years, 4 months

1
0
0 / 0

Re: (ITS#7279) Apparently mdb "approx" index generation failure for mdb_add for syncrepl consumer

by michael＠stroeder.com

This is a cryptographically signed message in MIME format. --------------ms060600050204060402060803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable brandon.hume(a)dal.ca wrote: > May 24 11:50:41 node2 slapd[25282]: null_callback : error code 0x50 > May 24 11:50:41 node2 slapd[25282]: syncrepl_entry: rid=3D001 be_add $D= N failed > (80) Are these the exact logs lines? I'm asking because $DN sounds to me like = a variable name used in a configuration template. Can cou please check that= ? Ciao, Michael. --------------ms060600050204060402060803 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyNDE3MDgyNVowIwYJKoZIhvcNAQkEMRYE FAiOlD00zt7MfnmG7hCZfrsEL7koMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAQKcLJh/AADvbF4KTIcbr8XbQ/WRU+LfEJf3+n70z//r4/LIvlyCVT7Wld9rfI/14pmzS UOvfchywdnHEV4n4WCCOsBp0aqJQZUv3CA6n7mAqTHPYvORyjJ+YpNiLZj5u5W1qCXXn1Vwy 1pF+Lorl4t4yY3kC2v7wFHVV2KGaz/EMATMdoCeRSHW8x1gq8KMrblcKr2TzCT0HJkY+5ZJ8 qZRYlC8rjZIToht1dYIK5ZfHvMsLN7nz/ltPM4s5yuu7VGZFNCo3m5MIamZlKvSflK/0cHIQ VolbZgmDoogion7BSeeTp7pHsHuIlKuXLJXCIvnhvnDb8rgUBDEMLM80hgAAAAAAAA== --------------ms060600050204060402060803--

11 years, 4 months

1
0
0 / 0

(ITS#7279) Apparently mdb "approx" index generation failure for mdb_add for syncrepl consumer

by brandon.hume＠dal.ca

Full_Name: Brandon Hume Version: 2.4.31 OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 URL: http://den.bofh.ca/~hume/mdb_approx_indexfail.tar Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) An empty syncrepl consumer using mdb backend will suffer index generator failures when populating its database from the provider and using "approx" index options. The failure manifests in syslog (with olcLogLevel=Stats) as the following: May 24 11:50:41 node2 slapd[25282]: null_callback : error code 0x50 May 24 11:50:41 node2 slapd[25282]: syncrepl_entry: rid=001 be_add $DN failed (80) These problems don't seem to occur when populating the provider using slapadd. The problem only seems to manifest when the new entry arrives via syncrepl. Playing with gdb, it seems like indexer() ends up being called with { bv_len = 0, bv_val = "" } when indexing "givenName". Could be because "givenName" on the troublesome entry is only one character? A minimalist DIT and config are provided in the tarfile in the link. The two nodes are running in mirrormode, and I'm not sure if that makes a difference. To reproduce: - On provider: slapadd -b cn=config -l mdb_approx_indexfail_config.ldif - On provider: slapadd -b dc=dal,dc=ca -l mdb_approx_indexfail_dit.ldif - On consumer: slapadd -b cn=config -l mdb_approx_indexfail_config.ldif - Start provider, confirm no errors - Start consumer, null_callback errors should appear immediately.

11 years, 4 months

1
0
0 / 0

(ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes

by fumiyas＠osstech.co.jp

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch Submission from: (NULL) (220.100.28.128) This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes to slapd-sha2 module. This patch depends on ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch (http://www.openldap.org/its/index.cgi?findid=7269).

11 years, 4 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2012