- openldap-bugs - openldap.org

Re: (ITS#9015) Replication goes haywire querying promoted master
by ondra＠mistotebe.net 23 Apr '19

23 Apr '19

On Tue, Apr 23, 2019 at 04:48:28PM +0000, quanah(a)openldap.org wrote: > In testing a particular use case/setup scenario, I found that it's possible to > cause a replica to slam a provider with unending requests. In this specific > case, I was setting up delta-syncrepl MMR, but I believe the issue applies to > standard syncrepl, and is not MMR specific. The scenario looks like this: > > Initially we have a stand alone server, which no overlays in place. The > configuration is done via cn=config, which allows for us to update the > configuration without a server restart. > > [...] > > I believe the problem is that the root entry for the database contains no > contextCSN. This is likely due to the fact that: > > [...] > > However, I think the overall behavior is undesirable. If there is no contextCSN > present, it should not lead to replication clients executing a potential DoS on > the provider. It also generated ~60GB of logs at loglevel stats in 1 day. Ok, I think this is consumer's fault and limited to refreshAndPersist deltasync (with or without MMR). Going by what I think I remember of the consumer code did: - on set up, it finds out there's no cookie to go by so it goes into refresh on the main DB - main DB responds with success but no/empty cookie - consumer starts over but again finds itself with no cookie, so it goes to step one But the consumer is actually up to date at that point as the search suggested, so it should just go ahead and do the refreshAndPersist on accesslog as it planned to originally. And as operations hit the main DB, they will replicate accordingly, even if that were to happen after the original search and before this one[0]. So in that case the behaviour would be as follows: - on set up, it finds out there's no cookie to go by so it goes into refresh on the main DB - main DB responds with success but no/empty cookie - consumer starts over, remembering that its cookie (albeit empty) is valid, so sends a refreshAndPersist search on accesslog DB - that yields no traffic, but will give it the right data once anything replication-worthy happens, job done - unless the connection is actually severed (restarts, ...) before anything needs replicating, we start from step one but no overhead was incurred, we're still fine [0]. Unless so much time has elapsed between the two searches (that happen on the same connection BTW) that some accesslog ops have already been expired. Expiration is usually configured in days, not seconds and an admin that doesn't notice a consumer going AWOL for that amount of time probably deserves that. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9015) Replication goes haywire querying promoted master
by quanah＠symas.com 23 Apr '19

23 Apr '19

--On Tuesday, April 23, 2019 7:07 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > The consumer should not be reconnecting more frequently than its retry > config. Since the consumer never disconnects, there is no reconnect. It connects a single time, and issues the same operation endlessly. Thus why when you look at the log file snippet I pasted, you see an OPERATION count in the MILLIONS. conn=1003 op=361869515 I.e., OPERATION 361,869,515 for connection 1003. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9015) Replication goes haywire querying promoted master
by hyc＠symas.com 23 Apr '19

23 Apr '19

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.47 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.144.40) > > > In testing a particular use case/setup scenario, I found that it's possible to > cause a replica to slam a provider with unending requests. In this specific > case, I was setting up delta-syncrepl MMR, but I believe the issue applies to > standard syncrepl, and is not MMR specific. The scenario looks like this: > > Initially we have a stand alone server, which no overlays in place. The > configuration is done via cn=config, which allows for us to update the > configuration without a server restart. > > The configuration is modified to load the syncprov and accesslog overlays, > create a new accesslog database, and to send all change data to the accesslog > db. > > After that is done, a secondary server is brought online with the same > configuration other than the serverID being different and the syncrepl statement > adjusted. > > When the secondary server is started, it pummels the initial provider with > queries like: > > Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SRCH > base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" > Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SRCH attr=* + > Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SEARCH RESULT > tag=101 err=0 nentries=0 text= > > (Averaging around 2000 queries/second on my server per syncrepl client). > > I believe the problem is that the root entry for the database contains no > contextCSN. This is likely due to the fact that: > > a) There was never a syncprov overlay present until I loaded this one in > b) The serverID was set prior to the syncprov overlay being loaded (So it went > from "0" to "1", with no changes ever recorded for "1"). > > Now there is a trivial ways to handle this, by making a change on the provider > prior to starting up the other servers. > > However, I think the overall behavior is undesirable. If there is no contextCSN > present, it should not lead to replication clients executing a potential DoS on > the provider. It also generated ~60GB of logs at loglevel stats in 1 day. The consumer should not be reconnecting more frequently than its retry config. -- -- 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#9015) Replication goes haywire querying promoted master
by quanah＠openldap.org 23 Apr '19

23 Apr '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) In testing a particular use case/setup scenario, I found that it's possible to cause a replica to slam a provider with unending requests. In this specific case, I was setting up delta-syncrepl MMR, but I believe the issue applies to standard syncrepl, and is not MMR specific. The scenario looks like this: Initially we have a stand alone server, which no overlays in place. The configuration is done via cn=config, which allows for us to update the configuration without a server restart. The configuration is modified to load the syncprov and accesslog overlays, create a new accesslog database, and to send all change data to the accesslog db. After that is done, a secondary server is brought online with the same configuration other than the serverID being different and the syncrepl statement adjusted. When the secondary server is started, it pummels the initial provider with queries like: Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SRCH attr=* + Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SEARCH RESULT tag=101 err=0 nentries=0 text= (Averaging around 2000 queries/second on my server per syncrepl client). I believe the problem is that the root entry for the database contains no contextCSN. This is likely due to the fact that: a) There was never a syncprov overlay present until I loaded this one in b) The serverID was set prior to the syncprov overlay being loaded (So it went from "0" to "1", with no changes ever recorded for "1"). Now there is a trivial ways to handle this, by making a change on the provider prior to starting up the other servers. However, I think the overall behavior is undesirable. If there is no contextCSN present, it should not lead to replication clients executing a potential DoS on the provider. It also generated ~60GB of logs at loglevel stats in 1 day.

1 0

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by hyc＠symas.com 22 Apr '19

22 Apr '19

siddjain(a)live.com wrote: > Full_Name: SIDDHARTH JAIN > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (173.226.196.10) > > > In some cases, OpenLDAP will modify the TLS certificate given to it before > sending it over to the client resulting in a certificate signature error. An > example of certificate it modifies is given below: OpenLDAP never touches the certificates you configure. If you're getting a corrupted certificate then there's either a bug in your storage/filesystem or in your SSL/TLS library. -- -- 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#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by siddjain＠live.com 22 Apr '19

22 Apr '19

Full_Name: SIDDHARTH JAIN Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.226.196.10) In some cases, OpenLDAP will modify the TLS certificate given to it before sending it over to the client resulting in a certificate signature error. An example of certificate it modifies is given below: -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIULFEF1JLNT6p0mzk7sbK8vQM/R+0wCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzANBgNVBAsTBmNsaWVudDAKBgNV BAsTA2puajEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MTcxNjQ5MDBa Fw0yMDA0MTYxNjU0MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMA0G A1UECxMGY2xpZW50MAoGA1UECxMDam5qMRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATQ+ACOVmhx0kUAMqLdl6i+s2// 3CgJi7YIYs4wwgMipNK7+s70Wwyva7lv6r2rOrpGOtlifCw4zSXB1E+DxKXho4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBT6olgSiuvK/c1P3/Gx+ljQL3yk FzAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQCN9saDTwXZ 4cefM27rUFT/1TqC3c7w8+NZNrJO3IYYFAIgHkGUYGABgiIEeQXyprd4AuLGhIZE mkhMI0uVeKWj1Jc= -----END CERTIFICATE----- The certificate returned to the client is however: -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIULFEF1JLNT6p0mzk7sbK8vQM/R+0wCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzAKBgNVBAsTA2puajANBgNVBAsT BmNsaWVudDEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MTcxNjQ5MDBa Fw0yMDA0MTYxNjU0MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMAoG A1UECxMDam5qMA0GA1UECxMGY2xpZW50MRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATQ+ACOVmhx0kUAMqLdl6i+s2// 3CgJi7YIYs4wwgMipNK7+s70Wwyva7lv6r2rOrpGOtlifCw4zSXB1E+DxKXho4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBT6olgSiuvK/c1P3/Gx+ljQL3yk FzAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQCN9saDTwXZ 4cefM27rUFT/1TqC3c7w8+NZNrJO3IYYFAIgHkGUYGABgiIEeQXyprd4AuLGhIZE mkhMI0uVeKWj1Jc= -----END CERTIFICATE----- which is different. The setup on which we have tested this is using the osixia/openldap docker image https://github.com/osixia/docker-openldap. we are able to reproduce the error on both mac and ubuntu. The server is started using following command: docker run -p 636:636 \ --name $NAME \ --volume ${PWD}/data/slapd/database:/var/lib/ldap \ --volume ${PWD}/data/slapd/config:/etc/ldap/slapd.d \ --volume ${PWD}/data/slapd/certs:/container/service/slapd/assets/certs \ --env LDAP_TLS_VERIFY_CLIENT=never \ --env LDAP_TLS_ENFORCE=true \ --env HOSTNAME=jnj-ldap-server \ --env LDAP_DOMAIN="jnj.com" \ --env LDAP_ADMIN_PASSWORD="superman" \ --env LDAP_LOG_LEVEL:-1 \ --detach osixia/openldap:1.2.4 --loglevel debug --copy-service and below is result of running openssl root@6fc2ae248018:/usr/src/app# openssl s_client -state -nbio -connect jnj-ldap-server:636 -CAfile jnj-ca-chain.pem -showcerts CONNECTED(00000003) Turned on non blocking io SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write R BLOCK SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello depth=2 C = US, ST = WA, L = Bellevue, O = Johnson & Johnson, CN = rca-jnj verify return:1 depth=1 C = US, ST = WA, L = Bellevue, O = Johnson & Johnson, OU = client + OU = jnj, CN = rca-jnj-admin verify return:1 depth=0 C = US, ST = WA, L = Bellevue, O = Johnson & Johnson, OU = jnj + OU = client, CN = jnj-ldap-server verify error:num=7:certificate signature failure verify return:1 depth=0 C = US, ST = WA, L = Bellevue, O = Johnson & Johnson, OU = jnj + OU = client, CN = jnj-ldap-server verify return:1 SSL_connect:SSLv3/TLS read server certificate SSL_connect:SSLv3/TLS read server key exchange SSL_connect:SSLv3/TLS read server done SSL_connect:SSLv3/TLS write client key exchange SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished SSL_connect:error in SSLv3/TLS write finished read R BLOCK SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS read change cipher spec SSL_connect:SSLv3/TLS read finished read R BLOCK --- Certificate chain 0 s:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/OU=jnj/OU=client/CN=jnj-ldap-server i:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/OU=jnj/OU=client/CN=rca-jnj-admin -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIULFEF1JLNT6p0mzk7sbK8vQM/R+0wCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzAKBgNVBAsTA2puajANBgNVBAsT BmNsaWVudDEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MTcxNjQ5MDBa Fw0yMDA0MTYxNjU0MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMAoG A1UECxMDam5qMA0GA1UECxMGY2xpZW50MRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATQ+ACOVmhx0kUAMqLdl6i+s2// 3CgJi7YIYs4wwgMipNK7+s70Wwyva7lv6r2rOrpGOtlifCw4zSXB1E+DxKXho4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBT6olgSiuvK/c1P3/Gx+ljQL3yk FzAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQCN9saDTwXZ 4cefM27rUFT/1TqC3c7w8+NZNrJO3IYYFAIgHkGUYGABgiIEeQXyprd4AuLGhIZE mkhMI0uVeKWj1Jc= -----END CERTIFICATE----- 1 s:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/OU=jnj/OU=client/CN=rca-jnj-admin i:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/CN=rca-jnj -----BEGIN CERTIFICATE----- MIICQTCCAeegAwIBAgIUBU9O3Wb3BDS8YuWRLYaKClbA9ZcwCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjMxOTAwWhcNMjQwMTMxMjMyNDAwWjB+MQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEbMAoGA1UECxMDam5qMA0GA1UECxMGY2xpZW50MRYwFAYDVQQDEw1y Y2Etam5qLWFkbWluMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEk4b8f5mWq+jf iMKQBVI8uU7btAF/LSSdXoOXYPW8JyJ23v5wtwRiQ/g4Al/6aIchvAC4QhJRUnz0 DMKuI7GCp6NmMGQwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFNuvs8Q9fpkg3oA+i2OEuR3qE96oMB8GA1UdIwQYMBaAFBGV3Han Nf1T5i8fvDh239lt5W9DMAoGCCqGSM49BAMCA0gAMEUCIQD/4+AUOMBdofQEVsH2 2A6UGiJQvuplLEBA9in0cZTcCQIgcV5K+KCs3a5RNYUWdllakGx8c1f6ISrmk4an gjeXphQ= -----END CERTIFICATE----- 2 s:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/CN=rca-jnj i:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/CN=rca-jnj -----BEGIN CERTIFICATE----- MIIB/TCCAaOgAwIBAgIUSsxdq02aJCyaIHkIRxRdKvWYG9swCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjExNDAwWhcNMzQwMTI4MjExNDAwWjBbMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEQMA4GA1UEAxMHcmNhLWpuajBZMBMGByqGSM49AgEGCCqGSM49AwEH A0IABCF30Cn+O5sD/9n6d3IQQEGiceCTD7gG/5t4dHR4xmvm84HNgRngGKGF4fny 6BXkPSyDguP+L5zozdWDb8dWTQejRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEBMB0GA1UdDgQWBBQRldx2pzX9U+YvH7w4dt/ZbeVvQzAKBggq hkjOPQQDAgNIADBFAiEAkCQcOP+PmyVIMgr/cUsk04qH8lXYO4DqDuH1WSNvGfEC IBZQGRehpZ604FgkD0YqmiGRV/OzU99em0g3jkmWJbJY -----END CERTIFICATE----- --- Server certificate subject=/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/OU=jnj/OU=client/CN=jnj-ldap-server issuer=/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/OU=jnj/OU=client/CN=rca-jnj-admin --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 2202 bytes and written 302 bytes Verification error: certificate signature failure --- New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384 Server public key is 256 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-ECDSA-AES256-GCM-SHA384 Session-ID: CAA7D5C4B5733C027877F5BC255EEA192B70E5D6125BC359B19CDDD3708BF857 Session-ID-ctx: Master-Key: 94727E3BE5361CCC34D02DDD797F62C7875A96283A1EB12FBD584749E36E804DE7BD402C81CDFC0F9F3DF0487BE38399 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1555951187 Timeout : 7200 (sec) Verify return code: 7 (certificate signature failure) Extended master secret: yes --- there is a certificate signature failure since the certificate returned to the client is different from the certificate provided to the server.

1 0

(ITS#9012) MDB maxsize gets truncated to 32-bit on Windows
by quanah＠openldap.org 21 Apr '19

21 Apr '19

Full_Name: Quanah Gibson-Mount Version: 2.4 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) When using a 64-bit build of OpenLDAP on windows with LMDB, you cannot have a database larger than 3GB (Any value over 3GB gets truncated to 3GB, at least until you overflow the 32-bit int value space).

1 0

(ITS#9011) add mdb_txn_flags()
by christopher＠gmerlin.de 21 Apr '19

21 Apr '19

Full_Name: Christopher Zimmermann Version: lmdb 0.9.23 OS: OpenBSD URL: Submission from: (NULL) (85.212.134.155) Hello, I'm working on a language binding of lmdb for OCaml. While doing so I missed a functin with with to check whether a transaction is read-only. To implement the functionality I propose the following change. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Christopher Zimmermann <christopher(a)gmerlin.de>. I have not assigned rights and/or interest in this work to any party. I, Christopher Zimmermann, 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. >From 2e573257a15edb0aebef3d522c262fa75c676f84 Mon Sep 17 00:00:00 2001 From: Christopher Zimmermann <madroach(a)gmerlin.de> Date: Sat, 20 Apr 2019 23:06:51 +0200 Subject: [PATCH] Add mdb_txn_flags() --- libraries/liblmdb/lmdb.h | 8 ++++++++ libraries/liblmdb/mdb.c | 7 +++++++ 2 files changed, 15 insertions(+) diff --git libraries/liblmdb/lmdb.h libraries/liblmdb/lmdb.h index 50ee37f..46ae389 100644 --- libraries/liblmdb/lmdb.h +++ libraries/liblmdb/lmdb.h @@ -989,6 +989,14 @@ MDB_env *mdb_txn_env(MDB_txn *txn); */ size_t mdb_txn_id(MDB_txn *txn); + /** @brief Retrieve the transaction's flags + * + * @param[in] txn A transaction handle returned by #mdb_txn_begin() + * @param[out] flags Address where the flags will be returned. + * @return A non-zero error value on failure and 0 on success. + */ +int mdb_txn_flags(MDB_txn *txn, unsigned int *flags); + /** @brief Commit all the operations of a transaction into the database. * * The transaction handle is freed. It and its cursors must not be used diff --git libraries/liblmdb/mdb.c libraries/liblmdb/mdb.c index 692feaa..fdf7618 100644 --- libraries/liblmdb/mdb.c +++ libraries/liblmdb/mdb.c @@ -2934,6 +2934,13 @@ mdb_txn_id(MDB_txn *txn) return txn->mt_txnid; } +int mdb_txn_flags(MDB_txn *txn, unsigned int *flags) +{ + if(!txn) return EINVAL; + *flags = txn->mt_flags & MDB_RDONLY; + return MDB_SUCCESS; +} + /** Export or close DBI handles opened in this txn. */ static void mdb_dbis_update(MDB_txn *txn, int keep) -- 2.20.1

1 0

Re: (ITS#7755) not replicated nodes after recovery
by quanah＠symas.com 19 Apr '19

19 Apr '19

--On Wednesday, November 27, 2013 5:26 AM +0000 dmitrii.fonariuk(a)gmail.com wrote: > Full_Name: Dmitrii Fonariuk > > I can conclude that the back is not replicated that DN, entryCSN value > that matches the value serverID. > > This is a bug or a feature? Hello, This would be a bug. However, it's most likely fixed since the 2.4.38 release, as there have been numerous replication related fixes since that time. If you can reproduce this issue with the current OpenLDAP release, please let us know. I apologize for the length in time in responding to this report. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9010) 2.5: Remove back-bdb and back-hdb
by quanah＠openldap.org 19 Apr '19

19 Apr '19

Full_Name: Quanah Gibson-Mount Version: 2.5 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) For 2.5, remove back-bdb and back-hdb from the OpenLDAP distribution. This depends on ITS#9009 in the long term, so that large DBs can be used in a 32-bit environment with LMDB. The work to remove bdb/hdb can start now, however.

1 0

(ITS#9009) 2.5: Switch to LMDB v1.0
by quanah＠openldap.org 19 Apr '19

19 Apr '19

Full_Name: Quanah Gibson-Mount Version: 2.5 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) For the OpenLDAP 2.5 release, we need to switch to using liblmdb v1.0 for the newer features, including MDB_VL32 support.

1 0

Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by quanah＠symas.com 19 Apr '19

19 Apr '19

--On Thursday, April 18, 2019 4:59 PM +0000 michael(a)stroeder.com wrote: > I considered contacting current SUSE maintainers of package openldap2. > > In preparation to that I tried to find out which bug caused this patch > to be developed. > > AFAIK the patch is not applied to the package anymore: > https://build.opensuse.org/package/show/network:ldap/openldap2 > > And I have no reference to further information. > > To OpenLDAP devs: > Does Howard's patch still make sense? > Is it worth to dig into SUSE's bugzilla to find out more? Hi Michael, Thanks for the updated information. It sounds like this patch is no longer necessary, so I'm going to close out the ITS. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8998) ldapi:// with SASL_NOCANON -> Local error (-2)
by hyc＠symas.com 18 Apr '19

18 Apr '19

michael(a)stroeder.com wrote: > On 4/18/19 3:36 AM, Quanah Gibson-Mount wrote: >> Does the patch referenced in ITS#7585 fix this for you?=C3=82=C2=A0 Be= en waiting=20 >> for years for RedHat to update with the IPR. ;) >=20 > Disclaimer: I'm not a C programmer. >=20 > Maybe it's me but AFAICS even if nocanon evaluates to True there's=20 > always a call into gethostname(). Does that make sense? >=20 > Ciao, Michael. I reproduced your issue, and applying the ITS#7585 patch fixes it for me.= Closing this as a dup of #7585. --=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/

1 0

Re: (ITS#7585) LDAPI with GSSAPI does not work if SASL_NOCANON=on
by hyc＠symas.com 18 Apr '19

18 Apr '19

rmeggins(a)redhat.com wrote: > Red Hat, Inc. 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. Thanks, fix applied in git master. -- -- 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#7585) LDAPI with GSSAPI does not work if SASL_NOCANON=on
by rmeggins＠redhat.com 18 Apr '19

18 Apr '19

Red Hat, Inc. 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.

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Thursday, April 18, 2019 8:09 PM +0000 henson(a)acm.org wrote: > On Thu, Apr 18, 2019 at 12:46:57PM +0200, Ond??ej Kuzn??k wrote: > >> If you still see crashes with the above, I might need you to explore the >> core file and accesslog a bit further. > > Hmm, actually, I haven't seen a crash for quite a while; I don't recall > exactly when the last one was but it's been ages. Right now I'm running > 2.4.46 with the patch for ITS#8927 applied, but without the last > ITS#8609 patch you had given me. > > I think the last crash was on 2.4.45 with the ITS#8927 patch. Maybe > something in 2.4.46 randomly fixed it? Hi Paul, Thanks for the follow up. I'm going to go ahead and close this ITS. If you do happen to see a crash again in the future, please follow up and we'll address it at that time. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 18 Apr '19

18 Apr '19

On Thu, Apr 18, 2019 at 12:46:57PM +0200, Ondřej Kuzník wrote: > If you still see crashes with the above, I might need you to explore the > core file and accesslog a bit further. Hmm, actually, I haven't seen a crash for quite a while; I don't recall exactly when the last one was but it's been ages. Right now I'm running 2.4.46 with the patch for ITS#8927 applied, but without the last ITS#8609 patch you had given me. I think the last crash was on 2.4.45 with the ITS#8927 patch. Maybe something in 2.4.46 randomly fixed it?

1 0

Re: (ITS#8998) ldapi:// with SASL_NOCANON -> Local error (-2)
by michael＠stroeder.com 18 Apr '19

18 Apr '19

On 4/18/19 3:36 AM, Quanah Gibson-Mount wrote: > Does the patch referenced in ITS#7585 fix this for you? Been waiting > for years for RedHat to update with the IPR. ;) Disclaimer: I'm not a C programmer. Maybe it's me but AFAICS even if nocanon evaluates to True there's always a call into gethostname(). Does that make sense? Ciao, Michael.

1 0

Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Thursday, April 18, 2019 1:12 PM +0000 michael(a)stroeder.com wrote: > On 4/18/19 12:44 AM, quanah(a)symas.com wrote: >> Sending this to your @suse.com email bounced. Please see below and >> update with an IPR as requested. Thanks! > > Since quite a while Howard Guo does not work for SUSE anymore. > > Do you need Howard's IPR notice or one from SUSE? Hi Michael & Howard, The problem is that while the ITS was filed from an @suse address, the patch is from Howard's @gmail address. At this point, we would need an IPR from both SuSE and Howard. Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by michael＠stroeder.com 18 Apr '19

18 Apr '19

I considered contacting current SUSE maintainers of package openldap2. In preparation to that I tried to find out which bug caused this patch to be developed. AFAIK the patch is not applied to the package anymore: https://build.opensuse.org/package/show/network:ldap/openldap2 And I have no reference to further information. To OpenLDAP devs: Does Howard's patch still make sense? Is it worth to dig into SUSE's bugzilla to find out more?

1 0

Re: (ITS#7624) Active Directory schema with OpenLdap
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Thursday, June 13, 2013 1:16 PM +0000 suresh.raja(a)vernal.is wrote: > 1. Need step-by-step configuration in Windows Server 2008 R2 > 2. How can i modify OpenLDAP server schema with Active Directory schema > 3. Can i Sync Active Directory and OpenLDAP(windows) > 4. Even my AD Server was Down, the schema should be in OpenLDAP, and > should be connect as locally... Hello, The ability to sync to OpenLDAP from AD has been added to OpenLDAP master and will be part of the OpenLDAP 2.5 release series. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by guohouzuo＠gmail.com 18 Apr '19

18 Apr '19

--0000000000008f3ffd0586cd1aa0 Content-Type: text/plain; charset="UTF-8" Hello Quanah. Sorry - my passion for Linux remains but I am no longer involved in OS foundation development at SUSE. Have a lovely Easter holiday! Kind regards, Howard On Thu, 18 Apr 2019 at 01:44, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, April 17, 2019 11:33 PM +0000 quanah(a)symas.com wrote: > > Hello, > > Sending this to your @suse.com email bounced. Please see below and > update > with an IPR as requested. Thanks! > > Regards, > Quanah > > > --On Thursday, November 30, 2017 2:02 PM +0000 hguo(a)suse.com wrote: > > > >> Full_Name: Houzuo Guo > >> Version: master > >> OS: > >> URL: ftp://ftp.openldap.org/incoming/houzuo-guo-171130.patch > >> Submission from: (NULL) (195.135.221.2) > >> > >> > >> In case that ldap connection is attempted on failed URLs prior to > >> establishing a successful connection, the failed connection sockets are > >> never freed. This patch plugs the socket descriptor leak. > > > > Hello, > > > > Thank you for the report! Please reply with an IPR statement as > > documented at > > > > <https://www.openldap.org/devel/contributing.html#notice> > > > > if you wish your patch to be reviewed for inclusion in the OpenLDAP > > software. > > > > Regards, > > Quanah > > > > > > -- > > > > Quanah Gibson-Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > <http://www.symas.com> > > > > > > > > > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > --0000000000008f3ffd0586cd1aa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hello Quanah.<div><br></div><div>Sorry - my passion for Li= nux remains but I am no longer involved in OS foundation development at SUS= E.<br></div><div><br></div><div>Have a lovely Easter holiday!</div><div><br= ></div><div>Kind regards,</div><div>Howard</div></div><br><div class=3D"gma= il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 18 Apr 2019 at 01:4= 4, Quanah Gibson-Mount <<a href=3D"mailto:quanah@symas.com">quanah@symas= .com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= ex">--On Wednesday, April 17, 2019 11:33 PM +0000 <a href=3D"mailto:quanah@= symas.com" target=3D"_blank">quanah(a)symas.com</a> wrote:<br> <br> Hello,<br> <br> Sending this to your @<a href=3D"http://suse.com" rel=3D"noreferrer" target= =3D"_blank">suse.com</a> email bounced.=C2=A0 Please see below and update <= br> with an IPR as requested.=C2=A0 Thanks!<br> <br> Regards,<br> Quanah<br> <br> > --On Thursday, November 30, 2017 2:02 PM +0000 <a href=3D"mailto:hguo@= suse.com" target=3D"_blank">hguo(a)suse.com</a> wrote:<br> ><br> >> Full_Name: Houzuo Guo<br> >> Version: master<br> >> OS:<br> >> URL: <a href=3D"ftp://ftp.openldap.org/incoming/houzuo-guo-171130.= patch" rel=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incoming= /houzuo-guo-171130.patch</a><br> >> Submission from: (NULL) (195.135.221.2)<br> >><br> >><br> >> In case that ldap connection is attempted on failed URLs prior to<= br> >> establishing a successful connection, the failed connection socket= s are<br> >> never freed. This patch plugs the socket descriptor leak.<br> ><br> > Hello,<br> ><br> > Thank you for the report!=C2=A0 Please reply with an IPR statement as<= br> > documented=C2=A0 at<br> ><br> > <<a href=3D"https://www.openldap.org/devel/contributing.html#notice= " rel=3D"noreferrer" target=3D"_blank">https://www.openldap.org/devel/contr= ibuting.html#notice</a>><br> ><br> > if you wish your patch to be reviewed for inclusion in the OpenLDAP<br= > > software.<br> ><br> > Regards,<br> > Quanah<br> ><br> ><br> > --<br> ><br> > Quanah Gibson-Mount<br> > Product Architect<br> > Symas Corporation<br> > Packaged, certified, and supported LDAP solutions powered by OpenLDAP:= <br> > <<a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_bla= nk">http://www.symas.com</a>><br> ><br> ><br> ><br> ><br> <br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">h= ttp://www.symas.com</a>><br> <br> </blockquote></div> --0000000000008f3ffd0586cd1aa0--

1 0

Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by michael＠stroeder.com 18 Apr '19

18 Apr '19

On 4/18/19 12:44 AM, quanah(a)symas.com wrote: > Sending this to your @suse.com email bounced. Please see below and update > with an IPR as requested. Thanks! Since quite a while Howard Guo does not work for SUSE anymore. Do you need Howard's IPR notice or one from SUSE? Ciao, Michael.

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by ondra＠mistotebe.net 18 Apr '19

18 Apr '19

On Wed, Nov 01, 2017 at 08:22:15PM +0000, henson(a)acm.org wrote: > On Fri, Oct 06, 2017 at 06:45:41PM -0700, Paul B. Henson wrote: >> but it looks like the same issue to me. I'm going to go ahead and >> recompile 2.4.45 with the ignore-invalid-accesslog-ops.patch and run >> that for a while and see what happens. > > Sadness :(, not one but two of my boxes crashed today, both running the > patch, with what appears to be the same issue: Hi Paul, I've updated the patch slightly to make sure invalid operations get logged and rejected so some action can be taken. Based on the backtrace, I can't see how an add modification could have ended up without values even with the previous version, however. A patch against master is available here: https://github.com/mistotebe/openldap/tree/its8609 And you can get one that applies on RE24 here: ftp://ftp.openldap.org/incoming/ndrej-Kuznik-20170327-ITS8609-ignore-invali… If you still see crashes with the above, I might need you to explore the core file and accesslog a bit further. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8998) ldapi:// with SASL_NOCANON -> Local error (-2)
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Monday, March 25, 2019 7:00 PM +0000 michael(a)stroeder.com wrote: > Full_Name: Michael Str.der > Version: 2.4.47 > OS: openSUSE Tumbleweed > URL: > Submission from: (NULL) (213.240.182.56) > > > Adding line > > SASL_NOCANON on Hi Michael, Does the patch referenced in ITS#7585 fix this for you? Been waiting for years for RedHat to update with the IPR. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#7585) LDAPI with GSSAPI does not work if SASL_NOCANON=on
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Friday, April 14, 2017 10:20 PM +0000 quanah(a)symas.com wrote: > Hello, > > Thanks for the report. Unfortunately, your submission does not follow > the ITS guidelines, meaning we can't really move forward with it at this > time. Please read over > <http://www.openldap.org/devel/contributing.html>, particularly the IPR > notice requirements as well as patch submission requirements. If you > can correct these issues, then the project can move forward with > including your work in the project. Note: Requested again today that RedHat follow the correct submission guidelines for this patch, this time in their bugzilla instance. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8881) slapd.access(5) state BDB and HDB are not primary backens
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Saturday, July 21, 2018 2:54 PM +0000 dpa-bugs(a)aegee.org wrote: > Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; > &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1 > 086;&#1074; Version: online manual > OS: Any > URL: > Submission from: (NULL) (92.192.99.60) > > > https://www.openldap.org/software/man.cgi?query=slapd.access&sektion=5&ap > ropos=0&manpath=OpenLDAP+2.4-Release says: Thanks for the report, this has been fixed for 2.4.48. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8984) Issue with socket buffer assertion failed
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Monday, February 25, 2019 7:23 PM +0000 gandhali.atre(a)plantronics.com wrote: > Full_Name: Gandhali Atre > Version: 2.4.44 > OS: Android > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (140.242.26.200) > > > Hi, > I have a product that allows to configure LDAP servers. Looks like when > changing the configurations or doing some search 1/10 times there is a > crash and below are the crash details. Hello, OpenLDAP 2.4.44 is quite old. Please update to a current release and let us know if the issue persists. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9006) sha2 module is not usable
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Thursday, April 11, 2019 5:14 AM +0000 aditya1606(a)gmail.com wrote: > Full_Name: Aditya > Version: 2.4.43 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.228.66.13) > > > I am not able to load the module due to this undefined symbol. > > $ nm pw-sha2.so | grep -i "lutil_passwd_add" > U lutil_passwd_add Hello, The SHA2 module gets loaded directly into slapd which has the necessary symbols. This ITS will be closed. I would also strongly advise upgrading to a current release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Wednesday, April 17, 2019 11:33 PM +0000 quanah(a)symas.com wrote: Hello, Sending this to your @suse.com email bounced. Please see below and update with an IPR as requested. Thanks! Regards, Quanah > --On Thursday, November 30, 2017 2:02 PM +0000 hguo(a)suse.com wrote: > >> Full_Name: Houzuo Guo >> Version: master >> OS: >> URL: ftp://ftp.openldap.org/incoming/houzuo-guo-171130.patch >> Submission from: (NULL) (195.135.221.2) >> >> >> In case that ldap connection is attempted on failed URLs prior to >> establishing a successful connection, the failed connection sockets are >> never freed. This patch plugs the socket descriptor leak. > > Hello, > > Thank you for the report! Please reply with an IPR statement as > documented at > > <https://www.openldap.org/devel/contributing.html#notice> > > if you wish your patch to be reviewed for inclusion in the OpenLDAP > software. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8781) "connection_read(248): no connection!" on 2.4.44
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Thursday, November 30, 2017 10:11 PM +0000 mramitsingh85(a)gmail.com wrote: > Full_Name: Amit kumar singh > Version: 2.4.44 > OS: CentOS release 6.9 (Final) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (14.141.104.38) > > > Issue on replication and get below error. > > Nov 30 17:03:55 host slapd[709]: connection_read(346): no connection! > Nov 30 17:03:55 host slapd[709]: connection_read(346): no connection! > Nov 30 17:03:55 host[709]: connection_read(362): no connection! > > I was searching issue and found that fixed ref: ITS#6548 on 2.4.27. But > strange thing is that it comes up again in 2.4.44. Not sure If I am > correct but need your help to look into it. Hello, This is not a bug. This commonly occurs when a client ends the connection without properly ending an unbind request first. The solution would be to fix the client involved. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Thursday, November 30, 2017 2:02 PM +0000 hguo(a)suse.com wrote: > Full_Name: Houzuo Guo > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/houzuo-guo-171130.patch > Submission from: (NULL) (195.135.221.2) > > > In case that ldap connection is attempted on failed URLs prior to > establishing a successful connection, the failed connection sockets are > never freed. This patch plugs the socket descriptor leak. Hello, Thank you for the report! Please reply with an IPR statement as documented at <https://www.openldap.org/devel/contributing.html#notice> if you wish your patch to be reviewed for inclusion in the OpenLDAP software. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8764) A small typo in README
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Monday, October 30, 2017 4:36 AM +0000 believelinan(a)aliyun.com wrote: > Full_Name: Nan Li > Version: 2.4.45 > OS: > URL: > Submission from: (NULL) (137.69.117.201) > > > I download source code of version 2.4.45, found a small typo in README at > line 32: > > 32 detailed instructions can be found in the OpenLDAP > Admnistrator's > > where "Admnistrator" should be "Administrator". Thanks for the report! This has been fixed in RE24. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8761) Comment for SLAPD_OVER_RETCODE define in portable.h is incorrect
by quanah＠symas.com 18 Apr '19

18 Apr '19

--On Monday, October 23, 2017 6:04 PM +0000 metzen(a)gmail.com wrote: > Full_Name: Matt McDonald > Version: > OS: > URL: > Submission from: (NULL) (2601:282:b01:175b:359:7f8e:53e6:7341) > > > The comment for the SLAPD_OVER_RETCODE entry in include/portable.hin > incorrectly describes it as the "Referential Integrity" overlay, when it > should indicate the "return code" overlay. Thanks for the report, this has been fixed in git master. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8426) unable to get group names of user
by quanah＠symas.com 17 Apr '19

17 Apr '19

--On Monday, May 16, 2016 3:00 PM +0000 pradeepagrawal8184(a)gmail.com wrote: > Full_Name: Pradeep Agrawal > Version: 2.4.40-7 > OS: centos > URL: > Submission from: (NULL) (114.143.121.177) > > > is there any way to get groups of users by providing username. i am using > java code to fetch list of groups of given users but it seems its not > possible as user don't have 'memberof' attribute. > Hello, The ITS system is for reporting bugs with the OpenLDAP software. It is not for general purpose help requests. Please use the openldap-technical email list for usage questions. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9008) module rpath incorrect
by ondra＠openldap.org 17 Apr '19

17 Apr '19

Full_Name: Ondrej Kuznik Version: re24/master OS: Linux URL: https://github.com/mistotebe/openldap/tree/its9008 Submission from: (NULL) (82.10.24.68) Modules that link against libraries not already present in slapd will only try to look in the rpaths encoded in the module, not in slapd. And there is no point encoding $(moduledir) there, since we never install anything of substance there. All the while the libraries we need probably live in $(libdir). The linked patch fixes this and makes it possible for $(moduledir) (the path modules will be installed into) to be set at configure time. IPR notice: The linked files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patches were developed Symas corp. Symas corp. has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Symas corp. to release this work under the following terms. Symas corp. 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.

1 0

Re: (ITS#9007) In writemap mode, a loose page can end up in me_dpages, causing a segfault on mdb_env_close.
by hyc＠symas.com 16 Apr '19

16 Apr '19

kriszyp(a)gmail.com wrote: > Full_Name: Kristopher William Zyp > Version: LMDB 0.9.23 > OS: Windows > URL: fhttps://github.com/kriszyp/node-lmdb/commit/dc290553acb57fa3f2d6d88a0d5e02… > Submission from: (NULL) (71.199.6.148) > > > In writemap mode in LMDB, it seems that a loose page can end up in me_dpages, > causing a segfault on mdb_env_close or on writes after mdb_env_set_mapsize. Thanks for the report, fix applied to mdb.master > > If I understand correctly, in MDB_WRITEMAP mode, dirty pages should never enter > into me_dpages, since dirty pages directly refer to the mapped memory, and > me_dpages are allocated from the heap (for reuse). However, I think a dirty page > that has become a loose page can end up in me_dpages; it seems that when > mdb_freelist_save() is called, it iterates through the loose pages and can end > up calling mdb_dpage_free at > https://github.com/LMDB/lmdb/blob/mdb.RE/0.9/libraries/liblmdb/mdb.c#L3114, > allowing the loose page to end up in me_dpages. This means that me_dpages ends > up with a reference to data in the memory map. And this becomes apparent if you > call mdb_env_close or do a mdb_env_set_mapsize triggering a segfault when it > attempts to free a memory map'ed page or access previously unmapped page. > > Everywhere else in the code, the MDB_WRITEMAP flag prevents any calls to > mdb_dpage_free (or mdb_dlist_free) in writemap mode (which I assume is > intentional), except in mdb_freelist_save. It seems like the mdb_dpage_free call > just needs to be moved up a few lines to the else block of the MDB_TXN_WRITEMAP > conditional, so that it also won't be called in writemap mode. > > I apologize I can't provide a more isolated test case. This combination actually > seems to be pretty rare occurrence, and very difficult to reproduce, I only > occasionally observe it happening with large amounts of operations with frequent > closing/resizing of the env. And I don't understand the internals to be 100% > confident of this, and perhaps I am misunderstanding this code path. But, it > does seems like this fix prevents these crashes for us, and seems like ensuring > there are no mdb_dpage_free calls in writemap mode (only mdb_page_free calls) is > the legitimate intention of the code. > > The attached URL contains the fix as a patch (against the node-lmdb project). > > -- -- 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#9007) In writemap mode, a loose page can end up in me_dpages, causing a segfault on mdb_env_close.
by kriszyp＠gmail.com 16 Apr '19

16 Apr '19

Full_Name: Kristopher William Zyp Version: LMDB 0.9.23 OS: Windows URL: fhttps://github.com/kriszyp/node-lmdb/commit/dc290553acb57fa3f2d6d88a0d5e02… Submission from: (NULL) (71.199.6.148) In writemap mode in LMDB, it seems that a loose page can end up in me_dpages, causing a segfault on mdb_env_close or on writes after mdb_env_set_mapsize. If I understand correctly, in MDB_WRITEMAP mode, dirty pages should never enter into me_dpages, since dirty pages directly refer to the mapped memory, and me_dpages are allocated from the heap (for reuse). However, I think a dirty page that has become a loose page can end up in me_dpages; it seems that when mdb_freelist_save() is called, it iterates through the loose pages and can end up calling mdb_dpage_free at https://github.com/LMDB/lmdb/blob/mdb.RE/0.9/libraries/liblmdb/mdb.c#L3114, allowing the loose page to end up in me_dpages. This means that me_dpages ends up with a reference to data in the memory map. And this becomes apparent if you call mdb_env_close or do a mdb_env_set_mapsize triggering a segfault when it attempts to free a memory map'ed page or access previously unmapped page. Everywhere else in the code, the MDB_WRITEMAP flag prevents any calls to mdb_dpage_free (or mdb_dlist_free) in writemap mode (which I assume is intentional), except in mdb_freelist_save. It seems like the mdb_dpage_free call just needs to be moved up a few lines to the else block of the MDB_TXN_WRITEMAP conditional, so that it also won't be called in writemap mode. I apologize I can't provide a more isolated test case. This combination actually seems to be pretty rare occurrence, and very difficult to reproduce, I only occasionally observe it happening with large amounts of operations with frequent closing/resizing of the env. And I don't understand the internals to be 100% confident of this, and perhaps I am misunderstanding this code path. But, it does seems like this fix prevents these crashes for us, and seems like ensuring there are no mdb_dpage_free calls in writemap mode (only mdb_page_free calls) is the legitimate intention of the code. The attached URL contains the fix as a patch (against the node-lmdb project).

1 0

(ITS#9006) sha2 module is not usable
by aditya1606＠gmail.com 11 Apr '19

11 Apr '19

Full_Name: Aditya Version: 2.4.43 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.228.66.13) I am not able to load the module due to this undefined symbol. $ nm pw-sha2.so | grep -i "lutil_passwd_add" U lutil_passwd_add

1 0

Re: (ITS#9004) LDAP_VENDOR_VERSION shall not be 0
by hyc＠symas.com 10 Apr '19

10 Apr '19

dpa-openldap(a)aegee.org wrote: > Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &amp= ;#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;= &#1074; > Version: git/master > OS: Linux > URL:=20 > Submission from: (NULL) (141.12.129.132) >=20 >=20 > Per https://gitlab.gnome.org/GNOME/evolution-data-server/issues/99: >=20 > =E2=80=A2 Please do not set LDAP_VENDOR_VERSION to 0, when compiling fr= om git/master, > but use reasonable default: a number bigger or equal to 20000. Like 20= 500 for > LDAP 2.5. >=20 >=20 git master is a development branch and not intended for production use. Use a tagged release or the release engineering branch. Closing this ITS. --=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/

1 0

(ITS#9005) LDAP_VENDOR_VERSION shall not be 0
by dpa-openldap＠aegee.org 10 Apr '19

10 Apr '19

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: git/master OS: Linux URL: Submission from: (NULL) (141.12.129.132) Per https://gitlab.gnome.org/GNOME/evolution-data-server/issues/99: Please do not set LDAP_VENDOR_VERSION to 0, when compiling from git/master, but use reasonable default: a number bigger or equal to 20000. Like 20500 for LDAP 2.5.

1 0

(ITS#9004) LDAP_VENDOR_VERSION shall not be 0
by dpa-openldap＠aegee.org 10 Apr '19

10 Apr '19

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: git/master OS: Linux URL: Submission from: (NULL) (141.12.129.132) Per https://gitlab.gnome.org/GNOME/evolution-data-server/issues/99: Please do not set LDAP_VENDOR_VERSION to 0, when compiling from git/master, but use reasonable default: a number bigger or equal to 20000. Like 20500 for LDAP 2.5.

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by henrik.bohnenkamp＠ionos.com 07 Apr '19

07 Apr '19

On Thu, Apr 04, 2019 at 05:32:16PM +0100, Howard Chu wrote: Hi Howard, thanks for your comments. There is now a new version of patches available in my github repository. Apart from addressing your comments, I have rebased the patches against the current master branch (quite a lot activity in the last two months, I have noticed). In particular, the new function mdb_get_aliases now also uses the global size variables for IDL dimensions, rather than the previous CPP constants. As for your comments: > > Hi, thanks for the report and investigation. I've briefly reviewed your > patches. Please squash your #3 into #2, there's no reason to preserve that. done > > We don't use "inline" in this code. If the compiler is smart enough it will > inline automatically anyway. Please drop that from your patch. done > > No need to keep the old mdb_idscope invocation commented out in patch #2. > Just delete it, we have the git history. done > > In patch #1 delete.c your patch line #145 is incorrect. You should be > using is_entry_alias(e) instead of (op->ora_e.) The entry in question is not > part of the op request, only its DN is in the Delete request. Ah, that was a mistake when squashing my commits down to the two patches... patch 1 introduced the faulty line with op->ora_e, patch 2 changed op->ora_e to e. I have cleaned that up. > > Not sure why you dropped nsubs from the diskNode definition. Are you sure you > haven't broken the nsubs processing in this patch? Note that the nsubs declaration was always commented out and had thus only a decorative function. Anyway, I have added this comment back to reduce the foot print of the patches. The current master branch with the two patches builds without problems. I have run the mdb tests in the tests directory... the last test was not applied due to missing software. All other 74 tests passed. (ubuntu 18.4). Best regards Henrik > > > -- Henrik Bohnenkamp

1 0

Re: (ITS#8996) Please supply a pkg-config file for libldap
by hugh.mcmaster＠outlook.com 05 Apr '19

05 Apr '19

In reference to #8996, I have prepared a patchset that adds support for generating pkg-config files at configure-time. There are three patches, one each for libldap, libldap_r and liblber. The attached patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Hugh McMaster <hugh.mcmaster at outlook.com>. I have not assigned rights and/or interest in this work to any party. I, Hugh McMaster, 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. ftp://ftp.openldap.org/incoming/hugh-mcmaster-190405.patch ftp://ftp.openldap.org/incoming/hugh-mcmaster-190405-02.patch ftp://ftp.openldap.org/incoming/hugh-mcmaster-190405-03.patch Please review the above patches and let me know if you require any changes. Thank you Hugh

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by hyc＠symas.com 04 Apr '19

04 Apr '19

henrik.bohnenkamp(a)ionos.com wrote: > On Fri, Jan 25, 2019 at 06:31:41AM -0800, Quanah Gibson-Mount wrote: >> --On Friday, January 25, 2019 1:51 PM +0000 hbohnenkamp(a)united-internet.de >> wrote: >> Hi, thanks for the report and investigation. I've briefly reviewed your patches. Please squash your #3 into #2, there's no reason to preserve that. We don't use "inline" in this code. If the compiler is smart enough it will inline automatically anyway. Please drop that from your patch. No need to keep the old mdb_idscope invocation commented out in patch #2. Just delete it, we have the git history. In patch #1 delete.c your patch line #145 is incorrect. You should be using is_entry_alias(e) instead of (op->ora_e.) The entry in question is not part of the op request, only its DN is in the Delete request. Not sure why you dropped nsubs from the diskNode definition. Are you sure you haven't broken the nsubs processing in this patch? > > Hi, > > I have now done quite a lot of testing in the way described in my > email from January (Followup 3). I used version 2.4.47, not the HEAD > of the openldap git master branch. > > I have found one bug, the one mentioned already in the same email. I > have added a fix for that bug to the patch directory in > https://github.com/hbo/openldap-mdb-deref-problem > > I have come across the regression with the back-hdb backend again, > which I also described in my previous email already. I am now > convinced that this regression is really a problem with the back-hdb > implementation, and I can show it without using my patched > implementation of back-mdb. The demonstration requires a bit more work > to be really presentable and should in any case go into a different > bug report. > > Apart from these two issues I have not seen any regressions, and I am > now quite confident that my patch would work reliable in the > environment of my company... no guarantees for anything else :-) > > I have seen that Quanah has suggested to look at ITS#8875 for the > 2.4.48 release. Whether there will be a fix in 2.4.48 and whether it > will be based on my patch is of course up to the lead developers (the > change in the DB schema is certainly a strong point against), but this > patch can perhaps serve as something to test the actual fix against. > > Best regards > Henrik > > > -- > Henrik Bohnenkamp > > > > -- -- 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#9003) Update slapd-ldap(5) idassert-authzfrom for policy difference
by quanah＠openldap.org 04 Apr '19

04 Apr '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) The slapd-ldap(5) man page has the following statement: idassert-authzFrom <authz-regexp> if defined, selects what local identities are authorized to exploit the identity assertion feature. The string <authz- regexp> follows the rules defined for the authzFrom attribute. See slapd.conf(5), section related to authz-policy, for details on the syntax of this field. However, it deviates from the rules laid out in the authz-policy section in that the special case of "*" has a different meaning for slapd-ldap/slapd-meta. In their case, this *allows* anonymous, while in the authz-policy case, anonymous is denied. This exception to the normal behavior needs to be noted.

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by henrik.bohnenkamp＠ionos.com 02 Apr '19

02 Apr '19

On Fri, Jan 25, 2019 at 06:31:41AM -0800, Quanah Gibson-Mount wrote: > --On Friday, January 25, 2019 1:51 PM +0000 hbohnenkamp(a)united-internet.de > wrote: > Hi, I have now done quite a lot of testing in the way described in my email from January (Followup 3). I used version 2.4.47, not the HEAD of the openldap git master branch. I have found one bug, the one mentioned already in the same email. I have added a fix for that bug to the patch directory in https://github.com/hbo/openldap-mdb-deref-problem I have come across the regression with the back-hdb backend again, which I also described in my previous email already. I am now convinced that this regression is really a problem with the back-hdb implementation, and I can show it without using my patched implementation of back-mdb. The demonstration requires a bit more work to be really presentable and should in any case go into a different bug report. Apart from these two issues I have not seen any regressions, and I am now quite confident that my patch would work reliable in the environment of my company... no guarantees for anything else :-) I have seen that Quanah has suggested to look at ITS#8875 for the 2.4.48 release. Whether there will be a fix in 2.4.48 and whether it will be based on my patch is of course up to the lead developers (the change in the DB schema is certainly a strong point against), but this patch can perhaps serve as something to test the actual fix against. Best regards Henrik -- Henrik Bohnenkamp

1 0

Re: (ITS#9002) Add option to slapcat to honor rtxnsize setting
by hyc＠symas.com 29 Mar '19

29 Mar '19

michael(a)stroeder.com wrote: > On 3/29/19 8:58 PM, quanah(a)openldap.org wrote: >> To work around this, slapcat could be given an option to honor the rtxnsize >> setting in slapd.conf/cn=config. >> [..] >> It should be noted in the man page section for this option that the value of >> such a backup is of dubious quality, since it is no longer an exact "point in >> time" representation of the database but rather a bunch of different "point in >> times" stitched together into a single file. > > Even if slapcat now outputs an exact "point in time" representation of > the database this does not say anything about consistency of related > LDAP entries anyway. > > But I wonder how rtxnsize is supposed to interop with > LDAP transactions in 2.5. There is no interaction. LDAP transactions only affect write ops. -- -- 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#9002) Add option to slapcat to honor rtxnsize setting
by michael＠stroeder.com 29 Mar '19

29 Mar '19

On 3/29/19 8:58 PM, quanah(a)openldap.org wrote: > To work around this, slapcat could be given an option to honor the rtxnsize > setting in slapd.conf/cn=config. > [..] > It should be noted in the man page section for this option that the value of > such a backup is of dubious quality, since it is no longer an exact "point in > time" representation of the database but rather a bunch of different "point in > times" stitched together into a single file. Even if slapcat now outputs an exact "point in time" representation of the database this does not say anything about consistency of related LDAP entries anyway. But I wonder how rtxnsize is supposed to interop with LDAP transactions in 2.5.

1 0

(ITS#9002) Add option to slapcat to honor rtxnsize setting
by quanah＠openldap.org 29 Mar '19

29 Mar '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) There is currently an issue with back-mdb, where if the database is quite large (10GB+) and the environment is experiencing a heavy write load, that if you start a backup (slapcat or mdb_copy), the database will heavily fragment and grow significantly in size due to the read lock from the slapcat/mdb_copy process. To work around this, slapcat could be given an option to honor the rtxnsize setting in slapd.conf/cn=config. This would allow the read lock to be released periodically and thus reduce the amount of fragmentation that occurs during the backup process. There is not (at this time) a solution proposed for mdb_copy. It should be noted in the man page section for this option that the value of such a backup is of dubious quality, since it is no longer an exact "point in time" representation of the database but rather a bunch of different "point in times" stitched together into a single file.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs