- openldap-bugs - openldap.org

(ITS#5834) enable modrDN rewriting
by kouk＠noc.uoa.gr 28 Nov '08

28 Nov '08

Full_Name: Kostantinos Koukopoulos Version: HEAD OS: Solaris URL: ftp://ftp.openldap.org/incoming/Kostantinos-Koukopoulos-081128.patch Submission from: (NULL) (195.134.100.30) The 'modrDN' rewrite context, as mentioned in the slapo-rwm documentation, is not implemented. Instead there is a undocumented context called 'renameDN' which when undefined will use the default context. The submitted patch simply enables the 'modrDN' context.

1 0

Re: (ITS#5804) attribute value regex expantion
by kouk＠noc.edunet.gr 28 Nov '08

28 Nov '08

I got segfault with the latest cvs and I think it's related to this ITS. It happened when slapd was evaluating the acl pattern. by dn.exact,expand="uid=$1,ou=people,dc=domain,dc=gr" write The relevant info from the debugger was: <= check a_dn_pat: uid=1,ou=people,dc=domain,dc=gr t@3 (l@3) signal SEGV (no mapping at the fault address) in acl_mask_dn at line 914 in file "acl.c" 914 val->bv_val, tmp_matchesp ) ) /SCRATCH/NG/ldap.devel-2.4/UOAldap.sources/openldap-cvs-20081128/servers/slapd> /SCRATCH/NG/ldap.devel-2.4/UOAldap.sources/openldap-cvs-20081128/servers/slapd> /SCRATCH/NG/ldap.devel-2.4/UOAldap.sources/openldap-cvs-20081128/servers/slapd>where current thread: t@3 =>[1] acl_mask_dn(op = 0x3e4440, e = 0x3b217c, val = (nil), a = 0x36c118, matches = 0xfcffde64, bdn = 0x36cfd0, opndn = 0x3e44dc), line 914 in "acl.c" [2] slap_acl_mask(a = 0x36c118, mask = 0xfcfff138, op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), matches = 0xfcffde64, count = 5, state = 0xfcffde48, access = ACL_WADD), line 1184 in "acl.c" [3] slap_access_allowed(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = 0xfcffde48, maskp = 0xfcfff3e0), line 297 in "acl.c" [4] fe_access_allowed(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = (nil), maskp = 0xfcfff3e0), line 359 in "acl.c" [5] over_access_allowed(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = (nil), maskp = 0xfcfff3e0), line 312 in "backover.c" [6] access_allowed_mask(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = (nil), maskp = (nil)), line 462 in "acl.c" [7] bdb_add(op = 0x3e4440, rs = 0xfcfffcb0), line 284 in "add.c" [8] fe_op_add(op = 0x3e4440, rs = 0xfcfffcb0), line 334 in "add.c" [9] overlay_op_walk(op = 0x3e4440, rs = 0xfcfffcb0, which = op_add, oi = 0x3614f8, on = (nil)), line 670 in "backover.c" [10] over_op_func(op = 0x3e4440, rs = 0xfcfffcb0, which = op_add), line 722 in "backover.c" [11] over_op_add(op = 0x3e4440, rs = 0xfcfffcb0), line 768 in "backover.c" [12] do_add(op = 0x3e4440, rs = 0xfcfffcb0), line 194 in "add.c" [13] connection_operation(ctx = 0xfcfffe0c, arg_v = 0x3e4440), line 1090 in "connection.c" [14] connection_read_thread(ctx = 0xfcfffe0c, argv = 0xd), line 1216 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x326dd0), line 663 in "tpool.c" Turns out 'val' is nil and it doesn't seem like there's any check for that. Maybe naive fix: =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/acl.c,v retrieving revision 1.347 diff -u -r1.347 acl.c --- servers/slapd/acl.c 16 Nov 2008 02:22:27 -0000 1.347 +++ servers/slapd/acl.c 28 Nov 2008 14:28:34 -0000 @@ -911,7 +911,7 @@ if ( acl_string_expand( &bv, &bdn->a_pat, e->e_nname.bv_val, - val->bv_val, tmp_matchesp ) ) + (val?val->bv_val:NULL), tmp_matchesp ) ) { return 1; }

1 0

sync'ing fails for modrdn
by Steffen Kaiser 28 Nov '08

28 Nov '08

Hello, I have configured a central OpenLDAP, using Debian Etch, version: slapd 2.3.30-5+etch1, which is also a sync provider. Another Debian Etch box uses the sync: syncrepl rid=123 provider=ldap://example.com type=refreshAndPersist retry="5,2,30,2,60,+" interval=00:01:00:00 searchbase="basedn" filter="(objectClass=*)" scope=sub attrs="*,+" sizelimit=0 timelimit=0 schemachecking=on bindmethod=simple binddn="someDN" credentials="somePwd" starttls=critical This works fine, but moddn fails: for testing purpose I ldapadd : dn: c=testtt,ou=basedn c: testtt objectClass: country then: ldapmodrdn -r 'c=testtt,ou=basedn' 'c=testww' It works on the sync provider (schemacheck on) and the result is: dn: c=testww,ou=basedn objectClass: country c: testww But on the sync consumer: : syncrepl_entry: c=testww,ou=basedn : Entry (c=testww,ou=basedn attribute 'c' cannot have multiple values : entry failed schema check: attribute 'c' cannot have multiple values : null_callback : error code 0x13 : syncrepl_entry: be_modrdn (19) The testtt entry is still present on the secondary box. If I delete "testww" on the sync provider, the "testt" entry in the consumere is deleted. ==== Because I trust the sync provider I changed schemachecking=off of the syncrepl rid=123 entry Now I get this in the log: : syncrepl_entry: c=testww,ou=basedn : syncrepl_entry: be_modrdn (0) : syncrepl_entry: be_modify (0) For me it looks like that because of the sequence of the two operations, schema checking is not compatible with moddn and this should be noted in the man page. Bye, -- Steffen Kaiser

4 3

RE: (ITS#5832) Networking and Replication.
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 27, 2008 2:08:06 PM +0000 Nils.Hammar(a)cybercomgroup.com wrote: > ------=_NextPart_000_0029_01C950A1.DC1D8A50 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Further investigation into this issue seems to indicate that the problem > is more related to the Berkeley DB 4.7.25 database than it is related to > OpenLDAP itself. > > Sorry for causing trouble on this issue, I'll stick to 4.6 for the moment. That makes no sense to me, BDB isn't communicating at the network level... Everything at that level is LDAP protocol. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5831) Replication unreliable
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 27, 2008 11:08:43 AM +0000 nils.hammar(a)cybercomgroup.com wrote: > Right now I'm using BDB 4.6.21, since I wasn't able at all to make BDB > 4.7.25 (with patch) to work. Not even "make test" succeded with the first > test, it just hung. (which is another problem, probably not related to > this problem) Did you also patch BDB 4.7 with the patch included in the OpenLDAP/build directory distributed with the source? It's necessary on some servers. It would be nice if Oracle would release it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5832) Networking and Replication.
by Nils.Hammar＠cybercomgroup.com 27 Nov '08

27 Nov '08

------=_NextPart_000_0029_01C950A1.DC1D8A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Further investigation into this issue seems to indicate that the problem is more related to the Berkeley DB 4.7.25 database than it is related to OpenLDAP itself. Sorry for causing trouble on this issue, I'll stick to 4.6 for the moment. ------=_NextPart_000_0029_01C950A1.DC1D8A50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL+jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv H3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZI AYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2 YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8E KjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDCBgQYDVR0jBHoweKFj pGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFz cyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5ghEAzbp/VvDf5LxU/iKs s3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvhZyzWAJhTowIb6ZBL+BhEnw9G 9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy5gQxkU5dPPBzBTdj67+DWZj9 Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCCBOUwggPNoAMCAQICEE2vqtiu yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODEwMTQwMDAwMDBaFw0wOTEwMTcyMzU5NTlaMIIB HDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UE CxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEUMBIGA1UEAxQL TmlscyBIYW1tYXIxLDAqBgkqhkiG9w0BCQEWHW5pbHMuaGFtbWFyQGN5YmVyY29tZ3JvdXAuY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK9OCvNd7SoeHTv9CAtBkk2O4JDj37AtwYVzyz IiVvoqHZ9LEF8+WT4w+dUuFgsQfx1+bFd63U4SDuwzRj5KvIVbc+7FR1igcIdLZUU3Sxn4UbdPZT tcYeyWt5Y8IuJK/k81uAeAo4nPvzwbMrymoIN4mBsB/RuH8fmr7o+00W/QIDAQABo4HiMIHfMAkG A1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9J bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG 9w0BAQUFAAOCAQEAl5Y1KD8GgWQMmy6bFHps9DJqAG4TLPaGkz8IMg6Y9MbZeruhEZIYz5pZBJCs jjaejgiGIimQkirfVxg9aYl/hBPXDRmsyeruPg6Vx4GyQlS06ww/52ZYIawelQyyjk5tQQyQesJ4 bnfNiTdAXTlujPnCN3POKXIIyjFEkD8MESudFm6Pv4lfFDV4eHAC8qd/AbPnV2WRG+SOL9YDOoYd N/rxL/X18/zcb8vFdzDuci3StC43LjOIoVAH7JUTFs8LHXi9gJcMyUiYGgDJ8m4eq3P/a4smzKVM ScHKUwTfX1W8Zs9onmsWDvTzjULkgojba/zs6oBvkdw8yCvYQM4DADGCBHMwggRvAgEBMIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vqtiu yqYVrOEv8MvOnVMwCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDgxMTI3MTQwNzI2WjAjBgkqhkiG9w0BCQQxFgQUrD6KW0bWJzupmxglkrOq mpCpvY4wZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwggED BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0EgLSBHMgIQTa+q2K7KphWs4S/wy86dUzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vqtiu yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEBBQAEgYCpBG16o6yJunOIxpD8tXIeMLpr785llp0rSFzi Bl29rw1EWwsVlU5aRyHlKzZUOwdS/WhPLlAb10aQUcCHv+2QDcWjLId+zOjQiubYHNCyh7inWH+u 0dqDDTAMyVbBd6yDUWWIN7MQ+++vyCBJ0WCSDE2DsYhhg19h9v2C4s49KAAAAAAAAA== ------=_NextPart_000_0029_01C950A1.DC1D8A50--

1 0

(ITS#5832) Networking and Replication.
by nils.hammar＠cybercomgroup.com 27 Nov '08

27 Nov '08

Full_Name: Nils Hammar Version: 2.4.13 OS: CentOS 5.2 URL: Submission from: (NULL) (194.17.253.72) When running syncrepl between two nodes in MirrorMode the communication works as it should until there is a disturbance on the network stack on either node. This is applicable to Linux where iptables is used to filter traffic. Example: Node A and B are running and updates on A are replicated to B. An update is done on iptables on B and the iptables is reloaded through "/etc/init.d/iptables restart". Any further updates on A are no longer replicated to B until the slapd service is restarted on B. So it seems to me that there is no 'keep alive' or similar functionality in the networking that catches this kind of situation.

1 0

(ITS#5831) Replication unreliable
by nils.hammar＠cybercomgroup.com 27 Nov '08

27 Nov '08

Full_Name: Nils Hammar Version: 2.4.13 OS: CentOS 5.2 URL: http://www.bedug.com/pics/openldap/nils-hammar-081127.tgz Submission from: (NULL) (194.17.253.72) OpenLDAP 2.4.13 has caused me some problems. It doesn't work reliable when I try to set up MirrorMode replication following the example given in the documentation at http://www.openldap.org/doc/admin24/replication.html#MirrorMode What I do is to set up one node first using the setup in files found at: http://www.bedug.com/pics/openldap/nils-hammar-081127.tgz, then I import an LDIF file containing the data there. All is well so far, and then I start the second node (which is having a completely uninitialized database), and it starts to communicate with the node where I imported the LDIF file, but it soon "hangs" and no further progress is made. It doesn't seem to replicate any data at all. Using 2.4.12 everything works as I expect it to - the second node builds a mirror of the first. Right now I'm using BDB 4.6.21, since I wasn't able at all to make BDB 4.7.25 (with patch) to work. Not even "make test" succeded with the first test, it just hung. (which is another problem, probably not related to this problem)

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 26 Nov '08

26 Nov '08

Howard Chu wrote : >You said you pulled from HEAD on November 3, and still saw the problem. Either >your checkout was wrong, or your configuration was wrong, because the fix was >definitely present in HEAD by then. Hi Howard, This time I downloaded the release 2.4.13 and ran several tests with my collegues. I send the results for your information : Let two mirror servers A and B. The server A is the main one on which we do usually the write operations and B is the fail-over mirror. We initiate the directory at the time t0 and do all write operations on A. At the time t1 we do only one write on B. Then we resume write operations on A. At t2 we stop B for a cold backup and do one write operation on A. After B startup, A scans internally all objects writtent after t1, checking for the attributes objectclass and entryCSN. If we do a similar operation (write on A while B stopped) at t3, then after startup again all objects written after t1 and up to t3 are scanned (so more and more objects in the directory lifetime). The behaviour of the server B seems OK (it does not scans objects). This situation is produced if we set "syncprov-nopresent TRUE" on both servers. Otherwise (without this directive) the server A scans the objects twice : 1) Once ALL directory objects, checking for their objectclass only, 2) A second time the objects written after t1, checking for objectclass and entryCSN. On the other hand the server B scans the objects writtent before t1 ! I do not know slapd and syncprov internals but I think that if at each startup only the biggest contextCSN values of the servers were compared, the most recent objects would be checked (only one object in our example). But may be this is not feasible for technical reasons that I ignore ? Thanks for your patience Best Regards Ali

1 0

Re: (ITS#5829) Missing moduleload doc. confusing chain/distproc/slapi.
by hyc＠symas.com 25 Nov '08

25 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > slapd.conf(5)'s moduleload description should say which filename a > module has: foo.so or foo.la. (Or worse - is that different on > different OSes? Windows, anyone?) "foo.la" will work on all platforms. The actual shared object that the .la file points to may have different naming conventions on different platforms. > It should say where the standard installed modules are found. > Also that is a default modulepath which as far as I can tell from > strace includes the standard installation directory and the system > loader's standard load path. And again, is it OS-dependent? It > uses libtool's lt_dlopenext(), I haven't looked for what it does yet. I would expect that of course yes, the system loader's standard path is OS-dependent. > slapd.plugin(5) should mention that slapi itself is a module which > may need to be loaded. And that it's "slapi.la", not "plugin.la". > The chain and distproc overlays are not found in<overlay>.la but in > back_ldap.la. This should be documented. I suggest a "moduleload > back_ldap.la" statement before all the other directives, with > explanation. > > However, even if documented, people will miss that. One does't look > for doc about what one already "knows". > > The simplest and maybe most informative fix would be to add dummy > modules which simply give an error message that the overlays are found > in the back_ldap module. When the software knows exactly what must be done, failing with an error message is just annoying. If we were to do anything here at all, dummy modules would better be replaced by symlinks to the actual module, so that It Just Works. But I think just noting the discrepancy in the documentation is sufficient. > An alternative would be to move them to separate modules which depend on > back-ldap - and document their dependency on back-ldap. More correct I > guess, but personally I don't see how it's an improvement. That might > just be because I have had little to do with maintaining binary > distributions though. I don't think it's an improvement either. > A third would be to store a module registry where module names are > mapped to one or more module filenames to load. Overkill? More > general, but also more complex. Yes, overkill. And there are probably more modules out there than we would ever know about for a registry, so ultimately not useful. -- -- 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#5818) Limits chapter for Admin Guide
by ghenry＠OpenLDAP.org 25 Nov '08

25 Nov '08

----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > Full_Name: Andrew Findlay > Version: HEAD > OS: Linux > URL: > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > Submission from: (NULL) (88.97.25.132) > > > The Admin Guide says very little about size limits and time limits. > I have supplied a chapter to remedy the lack: I suggest putting it in > after the > Access Control chapter: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > > Please check the section on limits for paged results extra carefully. > I found the definition in slapd.conf(5) a little ambiguous. > > I have also provided patches to the master sdf file and to the two > config > directive > chapters: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits-patch-20081118 > > Andrew I've read through and made certain changes to fit our style, but nothing major and committed. Thanks Andrew! Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5829) Missing moduleload doc. confusing chain/distproc/slapi.
by h.b.furuseth＠usit.uio.no 25 Nov '08

25 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd.conf(5)'s moduleload description should say which filename a module has: foo.so or foo.la. (Or worse - is that different on different OSes? Windows, anyone?) It should say where the standard installed modules are found. Also that is a default modulepath which as far as I can tell from strace includes the standard installation directory and the system loader's standard load path. And again, is it OS-dependent? It uses libtool's lt_dlopenext(), I haven't looked for what it does yet. slapd.plugin(5) should mention that slapi itself is a module which may need to be loaded. And that it's "slapi.la", not "plugin.la". The chain and distproc overlays are not found in <overlay>.la but in back_ldap.la. This should be documented. I suggest a "moduleload back_ldap.la" statement before all the other directives, with explanation. However, even if documented, people will miss that. One does't look for doc about what one already "knows". The simplest and maybe most informative fix would be to add dummy modules which simply give an error message that the overlays are found in the back_ldap module. An alternative would be to move them to separate modules which depend on back-ldap - and document their dependency on back-ldap. More correct I guess, but personally I don't see how it's an improvement. That might just be because I have had little to do with maintaining binary distributions though. A third would be to store a module registry where module names are mapped to one or more module filenames to load. Overkill? More general, but also more complex.

1 0

Re: (ITS#5828) Some slap* man pages only talk about slapd.conf
by ghenry＠OpenLDAP.org 24 Nov '08

24 Nov '08

----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > On Mon, Nov 24, 2008 at 10:02:56AM +0000, ghenry(a)OpenLDAP.org wrote: > > > The following man pages still talk about only slapd.conf: > > > Will fix. > > When doing so, would it be possible to avoid the duplication that > has started showing up in the Admin Guide? One section for doing a > job with slapd.conf and another one for the same job using cn=config > seems like a sure-fire way to get inconsistent information. It also > means that updates take (at least) twice as long to write. We should maybe just pick on configuration method and stick to it throughout the whole guide. POssibly cn=config, then point to the man pages for normal slapd.conf, or the other way round. slapd.conf is easier for just copying and pasting, but saying that, so is an LDIF. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5828) Some slap* man pages only talk about slapd.conf
by andrew.findlay＠skills-1st.co.uk 24 Nov '08

24 Nov '08

On Mon, Nov 24, 2008 at 10:02:56AM +0000, ghenry(a)OpenLDAP.org wrote: > The following man pages still talk about only slapd.conf: > Will fix. When doing so, would it be possible to avoid the duplication that has started showing up in the Admin Guide? One section for doing a job with slapd.conf and another one for the same job using cn=config seems like a sure-fire way to get inconsistent information. It also means that updates take (at least) twice as long to write. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by h.b.furuseth＠usit.uio.no 24 Nov '08

24 Nov '08

ghenry(a)OpenLDAP.org writes: > Cool. I say we rewrite it all in Java, this C stuff is hard to understand ;-) Perhaps we should take this to -devel now... -- Hallvard

1 0

Re: (ITS#5825) syncrepl default is no retry
by h.b.furuseth＠usit.uio.no 24 Nov '08

24 Nov '08

hyc(a)symas.com writes: > Have to ensure that the default setting doesn't persist in cn=config, > so that it will keep warning until an explicit value is set. That's on my wish list for cn=config defaults in general. -- Hallvard

1 0

(ITS#5828) Some slap* man pages only talk about slapd.conf
by ghenry＠OpenLDAP.org 24 Nov '08

24 Nov '08

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry The following man pages still talk about only slapd.conf: slapacl slapauth slapdn slappasswd slaptest Things like: "It opens the slapd.conf(5) configuration file," Will fix. Gavin.

1 0

ITS#5039 Support config for start_tls in ldap.conf
by hyc＠symas.com 23 Nov '08

23 Nov '08

In 2.4.13 you can specify "starttls" as an URL extension for the URI in the config file. This was discussed in this thread http://www.openldap.org/lists/openldap-devel/200810/msg00053.html I think that's sufficient to fulfill this enhancement request. -- -- 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#5827) Syncprov persistent operations info leaking
by hyc＠symas.com 23 Nov '08

23 Nov '08

hyc(a)symas.com wrote: > I don't think the current fix is complete. Due to the Abandon check at 1190, > it's possible (though extremely unlikely) for an Abandon to arrive between the > start and end of a mod op, and cause the final decrement to be skipped still. > Probably need to do some restructuring to catch this, I'll look at this some more. Never mind, syncprov_op_cleanup already catches these cases. -- -- 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#5827) Syncprov persistent operations info leaking
by hyc＠symas.com 23 Nov '08

23 Nov '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (81.72.89.40) >>> Submitted by: ando >>> >>> >>> After heavily loading a MMR pool, valgrind finds the following: >>> >>> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely >>> lo >>> st in loss record 13 of 15 >> Most likely because we increment s_inuse at line 1250, at the beginning of a >> non-Delete write op, and don't decrement it at the end of the op. I think this >> should be simple to fix, will take a look. > > Seems to work. Thanks, p. I don't think the current fix is complete. Due to the Abandon check at 1190, it's possible (though extremely unlikely) for an Abandon to arrive between the start and end of a mod op, and cause the final decrement to be skipped still. Probably need to do some restructuring to catch this, I'll look at this some more. -- -- 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#5827) Syncprov persistent operations info leaking
by ando＠sys-net.it 23 Nov '08

23 Nov '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (81.72.89.40) >> Submitted by: ando >> >> >> After heavily loading a MMR pool, valgrind finds the following: >> >> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely >> lo >> st in loss record 13 of 15 > > Most likely because we increment s_inuse at line 1250, at the beginning of a > non-Delete write op, and don't decrement it at the end of the op. I think this > should be simple to fix, will take a look. Seems to work. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5827) Syncprov persistent operations info leaking
by hyc＠symas.com 23 Nov '08

23 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > After heavily loading a MMR pool, valgrind finds the following: > > ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely > lo > st in loss record 13 of 15 Most likely because we increment s_inuse at line 1250, at the beginning of a non-Delete write op, and don't decrement it at the end of the op. I think this should be simple to fix, will take a look. -- -- 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

(ITS#5827) Syncprov persistent operations info leaking
by ando＠sys-net.it 23 Nov '08

23 Nov '08

Full_Name: Pierangelo Masarati Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando After heavily loading a MMR pool, valgrind finds the following: ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely lo st in loss record 13 of 15 ==29650== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==29650== by 0x825903B: ber_memalloc_x (memory.c:226) ==29650== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==29650== by 0x82029CA: syncprov_op_search (syncprov.c:2200) ==29650== by 0x8104F7B: overlay_op_walk (backover.c:660) ==29650== by 0x81051B0: over_op_func (backover.c:722) ==29650== by 0x8105234: over_op_search (backover.c:744) ==29650== by 0x80897F6: fe_op_search (search.c:366) ==29650== by 0x8089196: do_search (search.c:217) ==29650== by 0x8085F41: connection_operation (connection.c:1090) ==29650== by 0x808641B: connection_read_thread (connection.c:1216) ==29650== by 0x8222E9C: ldap_int_thread_pool_wrapper (tpool.c:663) ==29650== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==29650== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==29594== 2,913 (160 direct, 2,753 indirect) bytes in 2 blocks are definitely lo st in loss record 10 of 15 ==29594== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==29594== by 0x825903B: ber_memalloc_x (memory.c:226) ==29594== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==29594== by 0x82029CA: syncprov_op_search (syncprov.c:2200) ==29594== by 0x8104F7B: overlay_op_walk (backover.c:660) ==29594== by 0x81051B0: over_op_func (backover.c:722) ==29594== by 0x8105234: over_op_search (backover.c:744) ==29594== by 0x80897F6: fe_op_search (search.c:366) ==29594== by 0x8089196: do_search (search.c:217) ==29594== by 0x8085F41: connection_operation (connection.c:1090) ==29594== by 0x808641B: connection_read_thread (connection.c:1216) ==29594== by 0x8222E9C: ldap_int_thread_pool_wrapper (tpool.c:663) ==29594== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==29594== by 0xD42DBD: clone (in /lib/libc-2.5.so) p.

1 0

Re: (ITS#5825) syncrepl default is no retry
by ando＠sys-net.it 23 Nov '08

23 Nov '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: irrelevant >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> Syncrepl by default uses no retry. This is extremely useless, as syncrepl with >> no retry will probably break, sooner or later, without notifying why it >> happened. > > Legacy behavior, since retry was added later... > >> I believe it would be safe to have either: >> >> - a "safe" retry value (not too often, e.g. every hour, forever) > > Sounds fine, just add it to the doc. > >> - a warning (or an error) if retry is not given when configuring syncrepl > > Sounds rather annoying. We could combine these: if no retry was configured, > give the warning and use a default of 1 hour. Have to ensure that the default > setting doesn't persist in cn=config, so that it will keep warning until an > explicit value is set. > >> Another interesting feature would be to register syncrepl-specific parameters in >> back-monitor's entry of each database, that > >> - show the status of syncrepl (whether it's up, if rp) >> >> - show the timestamp of the last successful refresh >> >> - show the timestamp of the last failed attempt, and the reason of the failure > > Sounds fine, but unless you can add these quickly I don't see any reason to > hold 2.4.13 for it. Didn't mean to :) By now, only the warning is being issued. I don't think I can implement the rest for 2.4.13, will need to wait for next release. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by ghenry＠OpenLDAP.org 22 Nov '08

22 Nov '08

----- hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: > > Pierangelo Masarati writes: > >> -ZZ should be deprecated, and -Z should simply and strictly > require > >> StartTLS. > > > > Good point. Except then people who are used to new clients will > > make insecure connections when using old clients. Maybe -Z should > > be an error instead... > > > > What I'd really really like to do is throw away all the options, > > rename the programs, and start over. This time with the same > option > > names in ldap tools, slap tools, and slapd itself. Goes with the > > someday-in-the-future library rewrite, I suppose. > > OpenLDAP 3.0... > > The question is, when do we stop the 2.x stream and begin 3.0? Cool. I say we rewrite it all in Java, this C stuff is hard to understand ;-) -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs