openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

Re: (ITS#8210) slapd-sock: second subsequent bind fails
by michael＠stroeder.com 10 Aug '15

10 Aug '15

This is a cryptographically signed message in MIME format. --------------ms010905090300000505030204 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Ouch! This was caused by a stupid typo in my test script (not even the so= cket listener demon). =3D> you can close this ITS --------------ms010905090300000505030204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDgxMDIwMTYzOVowLwYJKoZIhvcNAQkEMSIE IN0rkT8RP7qlBKrXk/xlwi5XOTHkEhE0LBzpK0MTyVPiMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQA6PYpjB145s6zVte9XShsZ6a5c8BzGgSr+igVbZKSCeOJXdMnfh7vC NbsXC33U8E534/tSvho+oY3SkSUl2VyxASEIWywl0Xsl6ij/0IwPdF7mMci0ARJj2TIs/uwV FXMWMZqMBq5Yc/3Br9PVMkAsocAOWUxrlkzFZQlw4mk7NM1J5yrO9Rvh4ivdf0Pap1B8WzrO pOE488SO3Q53i2dJMX1N+am0SAfvEu+Q+/s4lTVzA3uvsWt4AGNqjmRgZMLJbJy1ecNTyk/E LzLJtyC4NwHEutomoQGP/MczC3iXMflxmvdaPRJlpWu2DhxU+GlBVMZTD8oBfG+ZfkxXvYaq AAAAAAAA --------------ms010905090300000505030204--

1 0

Re: (ITS#8054) Operation duration logging
by hyc＠symas.com 10 Aug '15

10 Aug '15

Hallvard Breien Furuseth wrote: > Den 10. aug. 2015 14:41, skrev Hallvard Breien Furuseth: >> It's total time which is interesting when looking for hot spots >> which need attention. So I suggest that plus either one of the >> others, or percentage of the total spent doing one of the others. > > Sorry - total+one of the other was silly probably, it just > leaves us calculating the missing one when looking for that > one. Total + percentage of one of the others makes sense, > or (etime, qtime) since a high value still will stand out. > Yes, I prefer explicit (etime, qtime) - anyone who needs the total can add it up themselves. -- -- 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#8054) Operation duration logging
by h.b.furuseth＠usit.uio.no 10 Aug '15

10 Aug '15

Den 10. aug. 2015 14:41, skrev Hallvard Breien Furuseth: > It's total time which is interesting when looking for hot spots > which need attention. So I suggest that plus either one of the > others, or percentage of the total spent doing one of the others. Sorry - total+one of the other was silly probably, it just leaves us calculating the missing one when looking for that one. Total + percentage of one of the others makes sense, or (etime, qtime) since a high value still will stand out. -- Hallvard

1 0

Re: (ITS#8054) Operation duration logging
by h.b.furuseth＠usit.uio.no 10 Aug '15

10 Aug '15

Den 05. aug. 2015 18:38, skrev hyc(a)symas.com: >clem.oudot(a)gmail.com wrote: >> Seems other LDAP servers have choosen 'etime' (see >> http://ludopoitou.com/2015/02/24/about-auditing-ldap-operations/). Why >> not try to use the same word? > > etime is fine with me. The other problem here is that it's counting duration > from when slapd received the request (which is fine) but usually the op gets > queued immediately after. For this etime to be useful we need to know both the > amount of time spent queued, and the amount of time spent actually executing. > qtime and etime? It's total time which is interesting when looking for hot spots which need attention. So I suggest that plus either one of the others, or percentage of the total spent doing one of the others. -- Hallvard

1 0

Re: (ITS#8198)
by peter＠adpm.de 08 Aug '15

08 Aug '15

Hi, you may want to have a look at Followup 1 for ITS#8205: I added a manual page for pbkdf2 and adapted it's Makefile to install it too. The commit can be found on my github repo: https://github.com/marschap/openldap/commit/f63202e8aa68e3391f52d2481f649ca… BTW: I successfully tested your nettle patch with by Debian-based server. Thank you! Best Peter -- Peter Marschall peter(a)adpm.de

1 0

(ITS#8205)
by peter＠adpm.de 08 Aug '15

08 Aug '15

Hi, I extended the patch series with a manual page for pbkdf2 * https://github.com/marschap/openldap/commit/f63202e8aa68e3391f52d2481f649ca… contrib/passwd/pbkdf2: add man page, install it too Best Peter -- Peter Marschall peter(a)adpm.de

1 0

(ITS#8214) slapo-rwm silently fails to convert config lines without rwm- prefix to cn=config
by ryan＠openldap.org 08 Aug '15

08 Aug '15

Full_Name: Ryan Tandy Version: OS: URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan A slapd.conf stanza like: overlay rwm rewriteEngine on works correctly in normal usage. Converting this to cn=config does not emit any olcRwmRewrite values, but succeeds nonetheless. The prefixed version: overlay rwm rwm-rewriteEngine on is converted correctly. In general, cn=config doesn't accept the unprefixed values at all, which is fine, but at least trying to ldapadd such a value returns an error. Considering this unimportant for now since the omitting the prefix is "strongly discouraged" by the man page.

1 0

Re: (ITS#8213) When using the rwm, openldap down
by ryan＠nardis.ca 08 Aug '15

08 Aug '15

Hi, Patched in git master: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=7380… Please test the patch, and report any problems with it. Thanks!

1 0

(ITS#8213) When using the rwm, openldap down
by ohno＠designet.co.jp 07 Aug '15

07 Aug '15

Full_Name: Kimiyoshi Ohno Version: 2.4.41 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.211.13.215) When I changed configuration for openldap, openldap stopped. (Aborted) I was carried out the following operations. (1) I created the following environment. ---- ---- ---- ---- # ldapsearch -LLL -Y EXTERNAL -b 'olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config' -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-rewriteEngine on olcRwmRewrite: {1}rwm-rewriteContext searchFilter olcRwmRewrite: {2}rwm-rewriteRule "aaa" "111" ":@" olcRwmRewrite: {3}rwm-rewriteRule "bbb" "222" ":@" ---- ---- ---- ---- (2) I created the following ldif file. ---- ---- ---- ---- dn: olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config changetype: modify delete: olcRwmRewrite olcRwmRewrite: rwm-rewriteRule "aaa" "111" ":@" - ---- ---- ---- ---- (3) I was carried out ldapmodify. ---- ---- ---- ---- # ldapmodify -Y EXTERNAL -H ldapi:/// -f down.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config" ldap_result: Can't contact LDAP server (-1) ---- ---- ---- ---- In this case, openldap has stopped. : : 55c45c8b connection_get(16) 55c45c8b ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 55c45c8b SASL Canonicalize [conn=1000]: authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 55c45c8b slap_sasl_getdn: conn 1000 id=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [len=55] 55c45c8b SASL Canonicalize [conn=1000]: slapAuthcDN="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 55c45c8b SASL proxy authorize [conn=1000]: authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 55c45c8b connection_get(16) 55c45c8b conn=1000 op=1 do_modify: dn (olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config) => ldap_bv2dn(olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config,0) <= ldap_bv2dn(olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(clcOverlay={0}rwm,olcDatabase={1}bdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config)=0 55c45c8b conn=1000 op=1 modifications: 55c45c8b delete: olcRwmRewrite 55c45c8b one value, length 32 55c45c8b [slapd:0] unknown command '' slapd: rwm.c:2195: rwm_cf_gen: Assertion `rc == 0' failed. Aborted Is this openldap BUG?

1 0

Re: (ITS#8054) Operation duration logging
by hyc＠symas.com 05 Aug '15

05 Aug '15

clem.oudot(a)gmail.com wrote: > 2015-02-11 18:33 GMT+01:00 <h.b.furuseth(a)usit.uio.no>: >> On 11. feb. 2015 12:38, Michael Str=C3=B6der wrote: >>> h.b.furuseth(a)usit.uio.no wrote: >>>> Cool feture, but please use fewer characteres in the already >>>> bloated log. How about "time=3D<integer>us" or even omit the "us"? >>> >>> +1 >>> >>> But 'time' sounds a bit general. >>> How about 'tdu' or even 'td' as abbreviation for "time duration"? >> >> I don't think so. You can't see from that what it means unless you >> already know, so you have to look it up just to see if you're >> interested. 'time' you can decide to look up if you are interested. >> > > Seems other LDAP servers have choosen 'etime' (see > http://ludopoitou.com/2015/02/24/about-auditing-ldap-operations/). Why > not try to use the same word? etime is fine with me. The other problem here is that it's counting duration from when slapd received the request (which is fine) but usually the op gets queued immediately after. For this etime to be useful we need to know both the amount of time spent queued, and the amount of time spent actually executing. qtime and etime? -- -- 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs