(ITS#8215) Slapmodify delete support and documentation
by ondra＠mistotebe.net
Full_Name: Ondřej Kuzn.k
Version: master
OS:
URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150811-slapmodify-delete-...
Submission from: (NULL) (62.84.155.99)
It is only possible to delete entries in a back-ldif database. This patchset
implements the equivalent functionality in the other core databases, enables the
same in back-config and adds a slapmodify manpage. With that in place,
test007-slapmodify is switched to fail on errors now. ModRDN stays unimplemented
at this point.
An outstanding issue is that valgrind complains about a memory leak in bdb on
entry delete, which I have not been able to pinpoint nor fix.
The above patch is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the above patches were
developed by Ondřej Kuzník <ondra(a)mistotebe.net>. I have not assigned
rights and/or interest in this work to any party.
I, Ondřej Kuzník, hereby place the above modifications to OpenLDAP
Software (and only these modifications) into the public domain. Hence,
these modifications may be freely used and/or redistributed for any
purpose with or without attribution and/or other notice.
8 years, 1 month
Re: (ITS#8210) slapd-sock: second subsequent bind fails
by michael＠stroeder.com
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--
8 years, 1 month
Re: (ITS#8054) Operation duration logging
by hyc＠symas.com
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/
8 years, 1 month
Re: (ITS#8054) Operation duration logging
by h.b.furuseth＠usit.uio.no
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
8 years, 1 month
Re: (ITS#8054) Operation duration logging
by h.b.furuseth＠usit.uio.no
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
8 years, 1 month
(ITS#8214) slapo-rwm silently fails to convert config lines without rwm- prefix to cn=config
by ryan＠openldap.org
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.
8 years, 1 month
(ITS#8213) When using the rwm, openldap down
by ohno＠designet.co.jp
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?
8 years, 1 month
