Re: (ITS#7277) Slapadd segfaults if binddn contains ou or dc statements
by o.loch＠gmx.net
--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.
Sorry for the wrong bug report and thanks again!
KR,
Oliver=20
Am 21.05.2012 um 01:46 schrieb Howard Chu:
>> I played with it a bit and as soon as one adds "ou=3D..." or "dc=3D..."=
to the
>> binddn it raises an error. In this example config and in the "real =
world".
>>=20
>> Imho there aren't any limitations to the binddn option?
>=20
> No, there are no limitations on binddn. Your example is invalid since =
you have not loaded any schema to define the "ou" or "dc" attributes. =
The error message from slapadd is correct.
>=20
> --=20
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>=20
>=20
--Apple-Mail=_E91EDB34-885C-4527-B3A7-0CF927EAA88D
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHCDCCBfCg
AwIBAgIDA6CuMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTIwMTI5MTQ0MTM3WhcNMTMwMTI5MjE0MTE4WjBTMRkwFwYDVQQNExB6N0V1VjY4Q0xvemRSRHkx
MRcwFQYDVQQDDA5vLmxvY2hAZ214Lm5ldDEdMBsGCSqGSIb3DQEJARYOby5sb2NoQGdteC5uZXQw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCmfq20gcAUPUePSPavAqfHQTuq75yNv9dj
TkYkP1kWeohKxHnznc1so0WuaMo1Azt/01Z1zdMZ3m5Ix3Q1UxuVRh+ciRockHJZ36uWWesMLdwh
/cdvgEeR+wqfceYuuW4Du8MDh9/+z4NCBJ6kvYQUXKZibthLaLssazBoHmvVDiwvmvDk2bLim+sC
ywRelWWFAnlVDGFTsHN9DKe1jXljLDnNwcHRzJroSx01Dh4AhMMkz8ZUQtx3GInhZLjErRCdZ3Oj
HDmZ8U2ABo1W7Hccux1U/70y6fOVOrQW7hkv1jPpGp1+713ONg4wc8PiGOHZHnIENBGBKOCGjd70
7zU9AgMBAAGjggOpMIIDpTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF
BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBF4b2lWP7cPi3uyf1fhXOfHBuA7MB8GA1UdIwQYMBaA
FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBkGA1UdEQQSMBCBDm8ubG9jaEBnbXgubmV0MIICIQYDVR0g
BIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh
cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t
L2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5n
IHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBD
QSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs
aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAn
FiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMi
IG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu
c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGG
LWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0
MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEA
aFgkPDQLgfzA2OCcUUaavf3yBb0JX83kkHtqpPJPs8AM7MEHgSwPtvDPfrArLZRVleQ5rE42QDrl
UJQ1FBrSaRaGERjihOvbXy3UglGk23zZfpV+tG3FM/K6r3aoOTghqldly/nnXptgUiV+Xc8GVZgZ
3v9M8bqx4ypL4VTxZ9FrIKQ6IoLyuxCFRUutk/UaN9bT4bVjLrlC3E5jltmtdjFPcQOGsZ3B5IeC
A8wWWiUrClvj1WJvBvgJ7o48F6mjdJYWZqzAQkQVkA0GmPsEb9YdWEyqygCnb1/oHmPYLzd7GZMS
8Yr0BFbSWB4vFdCI+eQg+xwBLD+bp8s4M+DodTGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk
aWF0ZSBDbGllbnQgQ0ECAwOgrjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA1MjExNzI3MDFaMCMGCSqGSIb3DQEJBDEWBBR7+zXEwhx2
T0J+cWFbzao725HBOjCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln
bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll
bnQgQ0ECAwOgrjCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQIDA6CuMA0GCSqGSIb3DQEBAQUABIIBACE6nneTvZzl9cCgd7q/2Ee65O3vXs3BzLCeXlCC
iS1yOOvo9udFSZlwY8tpSo8fKX6YDHAmRVliE/X+dUOPtIboyYJPIx+pJM66sULMDya194rYd9He
VeHA0//o0hTeGBzVBoWto3+qH3fmQKNCrHd1mZOhfVgkWAn0W9K2YayJGV0sFDJaTYQ+2jlgrZHM
AC1vhQltCcdOh5qF1X6YaOueFupm86bVo3YKuwY42VxkCAl9fAanwKR61pmXcH0wvACPgjO0d81w
oUwhlNJ7aTJ2/yMrAh13qn06nwLMxjjUE1HzYH78zHLLoSZVmo0p49ykzLYVVRQzZVMtBpmMy7UA
AAAAAAA=
--Apple-Mail=_E91EDB34-885C-4527-B3A7-0CF927EAA88D--
11 years, 4 months
(ITS#7277) Slapadd segfaults if binddn contains ou or dc statements
by o.loch＠gmx.net
Full_Name: Oliver Loch
Version: 2.4.31
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.134.36.68)
Hello,
first of all some basic information:
OpenLDAP Version:
[root@ls1 slapd.d]# slapd -V
@(#) $OpenLDAP: slapd 2.4.31 (Apr 24 2012 01:06:25) $
nobody@ovide:/build/src/openldap-2.4.31/servers/slapd
[root@ls1 slapd.d]#
OS:
Linux ls1 3.3.6-1-ARCH #1 SMP PREEMPT Sun May 13 10:52:32 CEST 2012 x86_64
GNU/Linux
Distribution:
ArchLinux
What I'm doing:
I have a Master/Master setup with actually two masters. To roll out the second
master I created a small configuration that is added to the OpenLDAP database
via slapadd.
The config:
======>8========SNIP========================
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 1 ldap://server1.foo.bar
olcServerID: 2 ldap://server2.foo.bar
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}back_bdb.la
olcModuleLoad: {1}back_hdb.la
olcModuleLoad: {2}accesslog
olcModuleLoad: {3}memberof
olcModuleLoad: {4}refint
olcModuleLoad: {5}unique
olcModuleLoad: {6}syncprov
olcModulePath: /usr/lib/openldap
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=master,cn=config
olcRootPW: {SSHA}5e/wtWWZVQPCNf+92o8jYiO56wvh5cRQ
olcSyncrepl: rid=001 provider=ldap://server1.foo.bar bindmethod=simple timeout=0
network-timeout=0 binddn="cn=syncer1,ou=users,cn=foo,cn=bar"
credentials="supersecret" keepalive=0:0:0 starttls=no searchbase="cn=config"
scope=sub schemachecking=off type=refreshAndPersist retry="5 +"
olcMirrorMode: TRUE
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
===========SNAP========8<====================
When adding the configuration to the - empty - slapd.d configuration directory
via:
slapadd -F /etc/openldap/slapd.d -n 0 -l /root/base.ldif
"slapadd" segfaults as soon as the "binddn" parameter inside the olcSyncrepl
attribute contains things like "ou" or "dc". So using
"cn=syncer1,ou=users,dc=foo,dc=bar" as binddn is not possible:
=========SNIP=======>8=======================
[root@ls1 slapd.d]# slapadd -F /etc/openldap/slapd.d/ -n 0 -l /root/base.ldif
4fb89a89 invalid bind config value binddn=cn=syncer1,ou=users,dc=foo,dc=bar
4fb89a89 olcSyncrepl: value #0: Error: parse_syncrepl_line: unable to parse
"binddn=cn=syncer1,ou=users,dc=foo,dc=bar"
.
4fb89a89 failed to add syncinfo
slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=19):
_################# 86.13% eta none elapsed none spd 313.2 k/s
Closing DB...Segmentation fault
[root@ls1 slapd.d]#
===========SNAP========8<====================
But using "cn=syncer1,cn=users,cn=foo,cn=bar" is:
========>8==================SNIP==============
[root@ls1 slapd.d]# slapadd -F /etc/openldap/slapd.d/ -n 0 -l /root/base.ldif
_#################### 100.00% eta none elapsed none fast!
Closing DB...
[root@ls1 slapd.d]#
======SNAP================8<=================
I played with it a bit and as soon as one adds "ou=..." or "dc=..." to the
binddn it raises an error. In this example config and in the "real world".
Imho there aren't any limitations to the binddn option?
If you need further information feel free to contact me.
Thanks!
Kr,
Oliver Loch
11 years, 4 months
(ITS#7276) [PATCH] MozNSS: allow CA certdb together with PEM CA bundle file
by jvcelak＠redhat.com
Full_Name: Jan Vcelak
Version: master
OS: Linux
URL: ftp://ftp.openldap.org/incoming/jvcelak-20120518-update-nss-allow-ca-cert...
Submission from: (NULL) (209.132.186.34)
With Mozilla NSS crypto backend:
Prior to this patch, if TLS_CACERTDIR was set to Mozilla NSS certificate
database and TLS_CACERT was set to a PEM bundle file with CA
certificates, the PEM file content was not loaded.
With this patch and the same settings, OpenLDAP can verify certificates
which are signed by CAs stored both in certdb and PEM bundle file.
This problem was found with FreeIPA which is setting CA PEM bundle using
ldap_set_option(&ld, LDAP_OPT_X_TLS_CACERTFILE, ...), while TLS_CACERTDIR with
certdb is set in system ldap.conf file.
The attached file is derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in the following patch(es) were developed by Red
Hat. Red Hat has not assigned rights and/or interest in this work to any party.
I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under
the following terms.
Red Hat hereby place the following 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.
11 years, 4 months
Re: (ITS#7274) delta-syncrepl MMR infinite loop
by quanah＠zimbra.com
--On Wednesday, May 16, 2012 10:27 PM +0000 quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.31
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.108.184.39)
We can see that the script turning it into a master ran here:
Thu May 17 16:05:46 2012 *** Running as zimbra user:
/opt/zimbra/libexec/zmldapenable-mmr -s 2 -m
ldap://zre-ldap002.eng.vmware.com:389/
so 16:05:46
In the accesslog, we see:
dn: cn=accesslog
objectClass: auditContainer
cn: accesslog
structuralObjectClass: auditContainer
contextCSN: 20120517225152.913667Z#000000#000#000000
contextCSN: 20120517230823.615364Z#000000#001#000000
contextCSN: 20120517230546.409118Z#000000#002#000000
dn: reqStart=20120517230546.000019Z,cn=accesslog
objectClass: auditAdd
structuralObjectClass: auditAdd
reqStart: 20120517230546.000019Z
reqEnd: 20120517230546.000020Z
reqType: add
reqSession: 100
reqAuthzID: cn=config
reqDN: cn=zimbra
reqResult: 0
reqMod: objectClass:+ organizationalRole
reqMod: description:+ Zimbra Systems Application Data
reqMod: cn:+ zimbra
reqMod: structuralObjectClass:+ organizationalRole
reqMod: entryUUID:+ 40f78bea-34be-1031-8a5d-e1466f667e19
reqMod: creatorsName:+ cn=config
reqMod: createTimestamp:+ 20120517224907Z
reqMod: entryCSN:+ 20120517224907.221672Z#000000#000#000000
reqMod: modifiersName:+ cn=config
reqMod: modifyTimestamp:+ 20120517224907Z
reqEntryUUID: 40f78bea-34be-1031-8a5d-e1466f667e19
entryUUID: 948929e2-34c0-1031-9a14-c93bd10ff0f2
creatorsName: cn=config
createTimestamp: 20120517224907Z
entryCSN: 20120517224907.221672Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20120517224907Z
so it is tracking "000" as a third master? This seems to be why the
original server (which was 000 before being promoted to 001) replicates
these entries back to itself.
--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
Re: (ITS#7133) slapd dies with SIGSEGV on SIGHUP
by openldap＠stormcloud9.net
I too am experiencing this issue. I attempted to apply the patch from
commit 7ff18967d7d2e49baa9d80f1b9408b276f3982e0, but it wont apply
cleanly to 2.4.31. I was going to apply it by hand, but it appears the
last 2 chunks have had a lot of changes in that area of the code.
Is there any chance of getting the patch re-based for 2.4.31?
Thanks
11 years, 4 months
(ITS#7274) delta-syncrepl MMR infinite loop
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.31
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.108.184.39)
The following problem did not occur for me in previous OpenLDAP releases.
However, I can reproduce it 100% of the time with OpenLDAP 2.4.31.
Basic configuration scenario is as follows:
Set up a stand alone OpenLDAP server -- Just cn=config and primary DB.
Basic database for the server is created (note all entries now have SID value
0)
Update the server to be delta-sync MMR -- Set sid=1, Mirror Mode, and add
accesslog DB. Add syncrepl stanza for a second server
Install second server as a delta-sycnrepl MMR pair -- cn=config, accesslog DB,
primary DB, SID=2
Servers now go into infinite loops due to the SID=0 entries.
Server SID=1 logs:
May 16 14:33:24 zre-ldap002 slapd[17422]: do_syncrep2: rid=100
cookie=rid=100,sid=002,csn=20120516212017.543213Z#000000#000#000000
May 16 14:33:24 zre-ldap002 slapd[17422]: slap_queue_csn: queing 0x58d2ced
20120516212017.543213Z#000000#000#000000
May 16 14:33:24 zre-ldap002 slapd[17422]: slap_graduate_commit_csn: removing
0x4699f50 20120516212017.543213Z#000000#000#000000
May 16 14:33:24 zre-ldap002 slapd[17422]: syncrepl_message_to_op: rid=100 be_add
cn=zimbra (68)
May 16 14:33:24 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 delta-sync lost
sync on (reqStart=20120516213237.000019Z,cn=accesslog), switching to REFRESH
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN:
cn=zimbra, UUID: add167b2-33e8-1031-8f62-f1c6fd57f8b3
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID
add167b2-33e8-1031-8f62-f1c6fd57f8b3
May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical
CSN cn=zimbra 20120516212017.543213Z#000000#000#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=zimbra
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry
unchanged, ignored (cn=zimbra)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN:
cn=admins,cn=zimbra, UUID: add18ab2-33e8-1031-8f63-f1c6fd57f8b3
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID
add18ab2-33e8-1031-8f63-f1c6fd57f8b3
May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical
CSN cn=admins,cn=zimbra 20120516212017.544170Z#000000#000#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100
cn=admins,cn=zimbra
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry
unchanged, ignored (cn=admins,cn=zimbra)
(etc, going through all 000 SID entries).
Once it finishes, it starts over:
May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical
CSN cn=com_zimbra_click2call_mitel,cn=zimlets,cn=zimbra
20120516212615.543144Z#000000#000#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100
cn=com_zimbra_click2call_mitel,cn=zimlets,cn=zimbra
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry
unchanged, ignored (cn=com_zimbra_click2call_mitel,cn=zimlets,cn=zimbra)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN:
cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra, UUID:
5a64830a-33ea-1031-8fbb-f1c6fd57f8b3
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID
5a64830a-33ea-1031-8fbb-f1c6fd57f8b3
May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical
CSN cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra
20120516213323.905859Z#000000#001#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100
cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry
unchanged, ignored (cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra)
May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100
LDAP_RES_SEARCH_RESULT
May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100
cookie=rid=100,sid=002,csn=20120516213323.905859Z#000000#001#000000;20120516213237.680889Z#000000#002#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: slap_queue_csn: queing 0x5805da0
20120516213237.680889Z#000000#002#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: slap_graduate_commit_csn: removing
0x5805620 20120516213237.680889Z#000000#002#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100
cookie=rid=000,sid=002,csn=20120516212017.543213Z#000000#000#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: slap_queue_csn: queing 0x58d2ced
20120516212017.543213Z#000000#000#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: slap_graduate_commit_csn: removing
0x5805bc0 20120516212017.543213Z#000000#000#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_op: rid=100 be_add
cn=zimbra (68)
May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 delta-sync lost
sync on (reqStart=20120516213237.000019Z,cn=accesslog), switching to REFRESH
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN:
cn=zimbra, UUID: add167b2-33e8-1031-8f62-f1c6fd57f8b3
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID
add167b2-33e8-1031-8f62-f1c6fd57f8b3
May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical
CSN cn=zimbra 20120516212017.543213Z#000000#000#000000
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0)
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=zimbra
May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry
unchanged, ignored (cn=zimbra)
On the second MMR master server, it logs:
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138856 SRCH attr=* +
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138856 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138857 SRCH
base="cn=accesslog" scope=2 deref=0
filter="(&(objectClass=auditWriteObject)(reqResult=0))"
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138857 SRCH attr=reqDN
reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
May 16 14:36:15 zre-ldap003 slapd[26137]: syncprov_search_response:
cookie=rid=100,sid=002,csn=20120516212644.426510Z#000000#000#000000;20120516213448.200519Z#000000#001#000000;20120516213237.680085Z#000000#002#000000
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138858 ABANDON
msg=138858
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138859 SRCH base=""
scope=2 deref=0 filter="(objectClass=*)"
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138859 SRCH attr=* +
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138859 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138860 SRCH
base="cn=accesslog" scope=2 deref=0
filter="(&(objectClass=auditWriteObject)(reqResult=0))"
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138860 SRCH attr=reqDN
reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138861 ABANDON
msg=138861
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138862 SRCH base=""
scope=2 deref=0 filter="(objectClass=*)"
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138862 SRCH attr=* +
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138862 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138863 SRCH
base="cn=accesslog" scope=2 deref=0
filter="(&(objectClass=auditWriteObject)(reqResult=0))"
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138863 SRCH attr=reqDN
reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138864 ABANDON
msg=138864
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138865 SRCH base=""
scope=2 deref=0 filter="(objectClass=*)"
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138865 SRCH attr=* +
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138865 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138866 SRCH
base="cn=accesslog" scope=2 deref=0
filter="(&(objectClass=auditWriteObject)(reqResult=0))"
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138866 SRCH attr=reqDN
reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
May 16 14:36:15 zre-ldap003 slapd[26137]: syncprov_search_response:
cookie=rid=100,sid=002,csn=20120516212644.426510Z#000000#000#000000;20120516213448.200519Z#000000#001#000000;20120516213237.680085Z#000000#002#000000
May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138867 ABANDON
msg=138867
However, I can get a working delta-sync MMR pair if I do the following:
Set up a stand alone OpenLDAP server -- Just cn=config and primary DB.
Basic database for the server is created (note all entries now have SID value
0)
Update the server to be delta-sync master: add accesslog DB.
Install second server as a replica.
Update first server to be delta-sync MMR: Set sid=1, mirrormode=true on primary
DB, add syncrepl stanza for second server
Update second server to be delta-sync MMR: Set sid=2, mirrormode=true on primary
DB, add accesslog DB, add syncprel stanza for first server
In this scenario everything works as expected.
The issue seems to be caused in the first scenario by server 2 replicating the
DB with SID=0 bits from the primary server, and that looping back to the first
server endlessly, instead of being permanently ignored.
--Quanah
11 years, 4 months
(ITS#7273) Sig abort crash in slapd using GSSAPI auth in slap_listener at daemon.c:1891
by stefan.wold＠su.se
Full_Name: Stefan Wold
Version: 2.4.31
OS: Ubuntu and Lunar Linux
URL:
Submission from: (NULL) (77.238.32.111)
I can reproduce a sig abort crash in both Ubuntu and Lunar Linux using OpenLDAP
2.4.31. This crash only seem occur when I run ~20 concurrent ldap searches using
-YGSSAPI for authentication, using simple bind (-x) I can't reproduce the crash.
Usually slapd crash within a couple of hours using GSSAPI. My test case is quite
simple, I start 20 threads that loop the following command: ldapsearch -h server
-YGSSAPI uid=user
In Ubuntu openldap is linked against cyrus-sasl which links to MIT kerberos. In
Lunar Linux cyrus-sasl is linked against heimdal. In this case it doesn't seem
to matter which kerberos implementation is used.
Here's a brief gdb backtrace:
Core was generated by `/usr/lib/slapd -d 0 -h ldap:/// ldaps:/// -f
/etc/openldap/slapd.conf'.
Program terminated with signal 6, Aborted.
#0 0x00007f70313293c5 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007f70313293c5 in raise () from /lib/libc.so.6
#1 0x00007f703132a83b in abort () from /lib/libc.so.6
#2 0x00007f703132226e in __assert_fail_base () from /lib/libc.so.6
#3 0x00007f7031322312 in __assert_fail () from /lib/libc.so.6
#4 0x00000000004310e7 in slap_listener (sl=0x15c30d0) at daemon.c:1891
#5 0x0000000000431109 in slap_listener_thread (ctx=<optimized out>,
ptr=<optimized out>) at daemon.c:2093
#6 0x00007f7032e7dcda in ldap_int_thread_pool_wrapper (xpool=0x15ff920) at
tpool.c:688
#7 0x00007f703165cce0 in start_thread () from /lib/libpthread.so.0
#8 0x00007f70313c7abd in clone () from /lib/libc.so.6
For a full backtrace: https://gist.github.com/a82d5b3dfdac7abc8e27
--
Sincerely
Stefan Wold
IT services, Stockholm University
Sweden
11 years, 4 months
Re: (ITS#7272) Implement hasSubordinates in back-ldif
by h.b.furuseth＠usit.uio.no
michael(a)stroeder.com wrote:
> It would be handy to have operational attribute 'hasSubordinates'
> returned for entries under cn=config.
If so, that can hopefully be done in back-config.
It'd be a bit costly in back-ldif - one stat() per read_entry,
plus an attempted rmdir(parent dir) in delete/modifyDN so that
read_entry can assume there are subordinates if the dir exists.
Hallvard
11 years, 4 months
