openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#7958) LMDB: LIFO-reclaiming, write-performance improvement & bugfixes
by leo＠yuriev.ru 12 Jan '15

12 Jan '15

For informaion only - Nowadays 'lifo' and 'coalesce' features implemented in ReOpenLDAP fork. 1) lmdb: MDB_LIFORECLAIM & MDB_COALESCE modes. https://github.com/ReOpen/ReOpenLDAP/commit/829c2063b602238b5c93ea36a981de3= d0d7994bc 2) lmdb-backend: support config for 'lifo' and 'coalesce' envflags. https://github.com/ReOpen/ReOpenLDAP/commit/08b4a41b5b837548444ef0fef761494= 0c41d882a With the couple of issues: 1) lmdb in 'writemap' mode may inconsistent even with checkpoints https://github.com/ReOpen/ReOpenLDAP/issues/1 2) lifo feature should be synchonized with checkpoints https://github.com/ReOpen/ReOpenLDAP/issues/2 However currently it gives a reasonable boost (5-10 times) of write-performance in our use case. Leonid. 2014-10-20 0:27 GMT+03:00 =D0=9B=D0=B5=D0=BE=D0=BD=D0=B8=D0=B4 =D0=AE=D1=80= =D1=8C=D0=B5=D0=B2 <leo(a)yuriev.ru>: >>>> We are using the combination: >>>> envflags writemap nosync lifo >>>> checkpoint 0 1 >>>> >>>> If the checkpoint is set in seconds, it gives us the assurance >>>> consistent state database on disk. >>>> However, without this patch meta-pages can be written by the kernel >>>> before the data. >>>> >>>> In fact, for a full guarantee in case of death slapd process, >>>> meta-page should be written explicitly. >> >> >> No, the DB can never go inconsistent due to a process crashing - the pag= es >> in OS cache are always correct. It can only go inconsistent if the OS >> crashes and a proper sync has not occurred. > > Yes, Howard, you are right. > But apparently I need to be more precise. > Talking about "death" of slapd, I meant all the reasons, including power = off. > > For example, a power-off case: > - The main power is turned off and the system switches to the UPS. > - Given the notice, OS starts an emergency stop processes. > - For some reason (does not have enough time to stop) slapd receives SIGK= ILL. > - OS tries to write mmap-region of the DB-file and begins with the > lower address. > - let the meta-pages has written completely, but for the rest of the > data is not enough battery power. > - Now DB is completely destroyed on the disk. > > To avoid this, the meta-pages should not be included in the rw-mapped > region, and should be written explicity after a data pages. > > >>>>>> commit 8ddd63161aeb2689822d1a8d27385d62e4e341ae >>>>>> Author: Leo Yuriev <leo(a)yuriev.ru> >>>>>> Date: 2014-09-19 22:47:19 +0400 >>>>>> >>>>>> BUGFIX - lmdb: properly sync meta-pages in mdb_sync_env(). >>>>>> >>>>>> Meta-pages may be updated during data-syncing in mdb_sync_env= (), >>>>>> in this case database would be inconsistent. >>>>>> >>>>>> Check-and-retry if lead txn-id changed during flushing data i= n >>>>>> mdb_sync_env(). >> >> Fundamentally, you are trying to make an inherently unsafe configuration >> "safer", but it's impossible. Assume you have mlock'd the meta pages int= o >> memory, so the OS never flushes them itself any more, and you're running >> with NOSYNC. That means, within 3 transactions, the data pages on disk w= ill >> be out of sync with the meta pages on disk. If the OS crashes at that po= int, >> the entire DB will be lost. > > Not a problem. > I had explained above - we should write meta-pages explicitly after > the data sync. > But also we should not perform reclaiming ahead of the last checkpoint. > >> The only way to make this mode of operation somewhat safe is to defer >> reclaiming pages for even longer. E.g., instead of halting at current_tx= nid >> - 3, halt at current_txnid - 22, in which case the data pointed to by th= e >> on-disk meta pages cannot get obsolete until 20 transactions have occurr= ed. >> >> Note that in combination with your LIFO patch, it's pretty much guarante= ed >> that the on-disk meta pages will be useless after only 2 un-sync'd >> transactions. > > Yes, Howard, you are right. > But I think there is confusion in the discussion because of mixing of > LIFO-feature and changes for checkpoints consistency in a NOSYNC and > WRITEMAP+NOSYNC modes. > For a "NOSYNC + checkpoints" topic I will submit a separate ITS (like > a 'volaile' related 7969,7970,7971). > My opinion - it is a flaw, and no reason to don't fix it. > > Continuing the conversation about checkpoints in a LIFO context. > I saw the problem, that you specified, and thinking over its solution, > but have not yet found "golden ratio". > And since we are having a serious problem with syncrepl, then I put > off this task with an excuse "LIFO-patch not does worse than it was." > > In general, we should do not reclaim anything ahead of the txn, that > is synced to the disk (let this be named a R-rule). > To do so we need a second field like mti_txnid, but which will be > update only at the end of mdb_env_write_meta(). > Finally we should start search in mdb_find_oldest() from value of this > new field instead of the current txn number. > This seems to will be work fine. > > However, I stopped on a reasoning - about the purpose of the > checkpoints, about design LMDB as a product, about the expectations of > the user and the necessary configuration parameters: > - checkpoints are needed ONLY in nosync modes; > - if the user does NOT activate the checkpoints, he do not care about > consistency; > - but if it is turned on, we MUST provide consistency on the checkpoints; > - otherwise a checkpoints feature is thoughtless and should be REMOVED. > Therefore implementation of checkpoints & reclaiming should be updated > to conform to the "R-rule", that noted above. > > From this point of view a LIFO-feature also should be refined, but > nevertheless can be very useful. > - SYNC mode =3D takes a benefit from storage with write-back cache > (assume powered by battery). > - ASYNC/NOSYNC without checkpoint =3D significant reduction of > committed/dirty pages and thereby much less write-iops. > - ASYNC/NOSYNC with checkpoint =3D seems to same as a SYNC case. > > Total of all the above - I think first we need to fix a reclaiming or > delete the checkpoints, and then I will complete LIFO. > >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > Thank for conversation. > Leonid.

1 0

Re: (ITS#8022) Backend Meta does not work with ssl-backends
by hyc＠symas.com 12 Jan '15

12 Jan '15

Dirk Kastens wrote: > Hi, > >> Then you should have simply followed up to #7983. > > The case has been closed. > >> Does ldapsearch work against the target servers using the certificate >> configurations you listed? > Yes. I can directly query the target servers from the redhat server > using ldapsearch and ssl. How about running ldapsearch with -d7, and also the corresponding search against back-meta using slapd -d7. Upload the output somewhere that we can review. -- -- 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#8018) a lot of warnings building with -Wall
by leo＠yuriev.ru 12 Jan '15

12 Jan '15

--f46d04426a60f30297050c76e815 Content-Type: text/plain; charset=UTF-8 2015-01-12 17:19 GMT+03:00 Hallvard Breien Furuseth < h.b.furuseth(a)usit.uio.no>: > On 01/06/2015 04:31 PM, hyc(a)symas.com wrote: > >> Leonid Yuriev wrote: >> >>> Yes of course, all warnings could be hushed by compiler options, but >>> this also hides the real mistakes. >>> So, I prefer fix the warnings, instead of disable gcc/clang features. >>> >>> Please review attached patchset and merge. >>> >> >> Your patch assumes CPP features that are not guaranteed to be present. >> Rejecting this patchset. >> > > The Debug() change is going to give merge conflicts all over > the place when your <https://github.com/ReOpen/ReOpenLDAP> and > OpenLDAP pull updates from each other. > > https://github.com/ReOpen/ReOpenLDAP should not be used for merge, but only for cherry-picking. It has stripped history and merged with OpenLDAP/mdb.master, because mdb.RE/0.9 don't includes a few critical fixes (ITS 7969,7970,7971) for our case. I think that is the reason for patch conflicts. Patchset got RE25 should remain among my sent emails. Presumably I can send it for you again, if you are interested. > How about defining Debug1(), Debug2(), etc for 1,2... arguments? > That's still annoying, but it keeps the code C90-compatible and > keeps -Wformat quiet. There's already similar code for Log<N>() > in include/ldap_log.h, but it was never used much or even merged > into RE24. (Because it got scheduled for RE25 which was going to > start Real Soon Now, IIRC:-) > > -- > Hallvard > IMHO the Log<N> recipe is onerously for support. On other hand, nowadays all non-obsolete compilers support most of C99 features. Baseline features, such as "variadic macro", supported long ago (Microsoft was the most conservative to 2012). Maybe it is time to enable C99 in RE25? Leonid. --f46d04426a60f30297050c76e815 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><br></div></div><div class=3D"gmail_extra"><div = class=3D"gmail_quote">2015-01-12 17:19 GMT+03:00 Hallvard Breien Furuseth <= span dir=3D"ltr"><<a href=3D"mailto:h.b.furuseth@usit.uio.no" target=3D"= _blank">h.b.furuseth(a)usit.uio.no</a>></span>:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l= eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span = class=3D"">On 01/06/2015 04:31 PM, <a href=3D"mailto:hyc@symas.com" target= =3D"_blank">hyc(a)symas.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Leonid Yuriev wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Yes of course, all warnings could be hushed by compiler options, but<br> this also hides the real mistakes.<br> So, I prefer fix the warnings, instead of disable gcc/clang features.<br> <br> Please review attached patchset and merge.<br> </blockquote> <br> Your patch assumes CPP features that are not guaranteed to be present.<br> Rejecting this patchset.<br> </blockquote> <br></span> The Debug() change is going to give merge conflicts all over<br> the place when your <<a href=3D"https://github.com/ReOpen/ReOpenLDAP" ta= rget=3D"_blank">https://github.com/ReOpen/<u></u>ReOpenLDAP</a>> and<br> OpenLDAP pull updates from each other.<br> <br></blockquote><div><a href=3D"https://github.com/ReOpen/ReOpenLDAP">http= s://github.com/ReOpen/ReOpenLDAP</a> should not be used for merge, but only= for cherry-picking.</div><div>It has stripped history and merged with Open= LDAP/mdb.master, because mdb.RE/0.9 don't includes a few critical fixes= (ITS 7969,7970,7971) for our case.</div><div>I think that is the reason fo= r patch conflicts.</div><div>Patchset got RE25 should remain among my sent = emails. Presumably I can send it for you again, if you are interested.</div= ><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor= der-left-style:solid;padding-left:1ex"> How about defining Debug1(), Debug2(), etc for 1,2... arguments?<br> That's still annoying, but it keeps the code C90-compatible and<br> keeps -Wformat quiet.=C2=A0 There's already similar code for Log<N&g= t;()<br> in include/ldap_log.h, but it was never used much or even merged<br> into RE24.=C2=A0 (Because it got scheduled for RE25 which was going to<br> start Real Soon Now, IIRC:-)<span class=3D""><font color=3D"#888888"><br> <br> -- <br> Hallvard<br> </font></span></blockquote></div><br></div><div class=3D"gmail_extra"><div = class=3D"gmail_extra"><div class=3D"gmail_extra">IMHO the Log<N> reci= pe is onerously for support.</div><div class=3D"gmail_extra">On other hand,= nowadays all non-obsolete compilers support most of C99 features.</div><di= v class=3D"gmail_extra">Baseline features, such as "variadic macro&quo= t;, supported long ago (Microsoft was the most conservative to 2012).</div>= <div class=3D"gmail_extra">Maybe it is time to enable C99 in RE25?<br></div= ><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Leonid.</d= iv></div></div></div> --f46d04426a60f30297050c76e815--

1 0

Re: (ITS#8022) Backend Meta does not work with ssl-backends
by dirk.kastens＠uni-osnabrueck.de 12 Jan '15

12 Jan '15

This is a cryptographically signed message in MIME format. --------------ms020609010007010102020405 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, > Then you should have simply followed up to #7983. The case has been closed. > Does ldapsearch work against the target servers using the certificate > configurations you listed? Yes. I can directly query the target servers from the redhat server=20 using ldapsearch and ssl. --------------ms020609010007010102020405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJDCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFcDCCBFigAwIBAgIHF6QkfFey qDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MB4XDTE0MDUyNzE0NTMzM1oXDTE5MDcwOTIzNTkwMFowgZExCzAJBgNVBAYTAkRFMSAwHgYD VQQKExdVbml2ZXJzaXRhZXQgT3NuYWJydWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEj MCEGA1UEAxMaVW5pLU9zbmFicnVlY2sgUlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNh QHVuaS1vc25hYnJ1ZWNrLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApLZx V6i214uWBb3c16AMckkujPKMXxl9Z4XsEIhrA47tG5YL9upeUrj+duDcrbEQvphvSXJFveVk LK1JMANHJuu/Wa32Bc8IRljYBqhaKMTGRO1q5L6jkMBDwBwenozhlGAaqG+8Cy+qcFoUaoWB RCH2++t5FtXyS1/1GKhWu7yQxCblFul7VXvnLKyaNlOaTalREXb9pQk2N31+rrOgwkbogxc2 z30gQAJXeJ2Ra0SlReqINMmcDd4lfluXjBpFmiJa4xHhQIVJpW2vF8dbqmeKqxIoYziBh78N GaqMSC8IbDPbCM3qaDaGUWKccgb/SKZvrNTLU+jcW66yGi1YPwIDAQABo4ICATCCAf0wEgYD VR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAowCDAGBgRVHSAAMB0G A1UdDgQWBBSqH9h3FW6Z5F+Q1uxjJk4Z6mcUUDAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp 9/EKcD7eZDAfBgNVHREEGDAWgRRjYUB1bmktb3NuYWJydWVjay5kZTCBiAYDVR0fBIGAMH4w PaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9j YWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRw Oi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEApVPS1rUMH9oWu02nJHDV C7jF74wUYbzFaX1ULtkEGXK0MV2HyR8kZ3t19qcmEzgo/eaYv5+OE/nMnNHWUH/ybTN3bQFF K4+L+42SwRkSnyXVQsb38NsUknpDAlUeR9+jv5rkhIF5u+sRIXSB1lzoohtVUkYsC50UO1L4 bWchK7DE++22NDiTgtoFWwC1nn2wt8FYTB4IIbCOogEI6fFXIHZkG6BlLiYmPFmbNfPwNJpv 25g87P0SXpQR1uxSv4giL6o6XWCDJpnCEA4+029ZYLZG0e1bSzk4wI+ho08oxNs8B7NPlH2p jOpq40pZwvVw5rp2nu3W5CaDxgHdxXBX5DCCBYcwggRvoAMCAQICBxWm3SXtmbEwDQYJKoZI hvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRhZXQgT3NuYWJy dWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEjMCEGA1UEAxMaVW5pLU9zbmFicnVlY2sg UlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNhQHVuaS1vc25hYnJ1ZWNrLmRlMB4XDTEz MDUwNjA3NDUyNVoXDTE2MDUwNTA3NDUyNVowXjELMAkGA1UEBhMCREUxIDAeBgNVBAoTF1Vu aXZlcnNpdGFldCBPc25hYnJ1ZWNrMRYwFAYDVQQLEw1SZWNoZW56ZW50cnVtMRUwEwYDVQQD EwxEaXJrIEthc3RlbnMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZObhf0kwV d2daq89+nHsASWUXo8iLb+T9y2N5cmwkVMwAjgtTqjJu+P8jQOxxKaK35pWS5CB1HGiNqLms NOdMVqf1PXdnDANE//wGsMTKwKVjhYlj7PoPSuwAZ4NT8eTf/UR3ViPA64r9qCB8pYBO3L1w n6oMiXdWD8Vd7OVEVzGeMoVYstRyv+wzUAPJotGCd5smxEq+LMTv1HQ6xtZW2le5bMub4uk4 UdACPgCDBGP07sQvM8krM5fNOIbzNRyqD7eERnSMGkounpRkHSwoWUkt1njYUrxk1q4qMDBz xEIx4MPGPw57HN0VQ9z/3eUBjmZi+oqlxkDlHwzcvsH3AgMBAAGjggIUMIICEDAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAgEEAwAwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ4 FSGPMJNnhKKMKGStCzA58jMkmjAfBgNVHSMEGDAWgBSqH9h3FW6Z5F+Q1uxjJk4Z6mcUUDAp BgNVHREEIjAggR5kaXJrLmthc3RlbnNAdW5pLW9zbmFicnVlY2suZGUwgY8GA1UdHwSBhzCB hDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktb3NuYWJydWVjay1jYS9wdWIv Y3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS91bmktb3NuYWJy dWVjay1jYS9wdWIvY3JsL2NhY3JsLmNybDCBqAYIKwYBBQUHAQEEgZswgZgwSgYIKwYBBQUH MAKGPmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLW9zbmFicnVlY2stY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MEoGCCsGAQUFBzAChj5odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1v c25hYnJ1ZWNrLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEA pJjFnuZVVSPNqukqAI+ZWWClujzCsBdN1Zq95kik17FqjsB8TSqelmmohw1qBQXq3EnDFmWy R6FuNqYOPjborAEkhwRPmUXDDLvCU02TvwtxFuNJZc0ALz41oR8s8l5PBYoNlpPsYz+tsbKX +15XnsH1ftR/wzqaWPMLfWhG0OnLObeEMb+y5EQPO5kKzf+EdM/JmITWnip03FAtcr9JWq3N p6APfIDoWJ4uM5CyOvnEox41V+2a6PuOKY/bPE9seCOBbduWb15pXYZB7EHWM5Hkp5bLsl7s YtnFH++SCDLyutyLq4LCw1ryt7rLzkUEQ/YZOAqkfifDY6OdW3cRqzGCA/gwggP0AgEBMIGd MIGRMQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IE9zbmFicnVlY2sxFjAU BgNVBAsTDVJlY2hlbnplbnRydW0xIzAhBgNVBAMTGlVuaS1Pc25hYnJ1ZWNrIFJaLUNBIEct MDAyMSMwIQYJKoZIhvcNAQkBFhRjYUB1bmktb3NuYWJydWVjay5kZQIHFabdJe2ZsTAJBgUr DgMCGgUAoIICLzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x NTAxMTIxNTMyNDVaMCMGCSqGSIb3DQEJBDEWBBS6OOuWq562k3pz6MZsbg4R/6KqLjBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGu BgkrBgEEAYI3EAQxgaAwgZ0wgZExCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRh ZXQgT3NuYWJydWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEjMCEGA1UEAxMaVW5pLU9z bmFicnVlY2sgUlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNhQHVuaS1vc25hYnJ1ZWNr LmRlAgcVpt0l7ZmxMIGwBgsqhkiG9w0BCRACCzGBoKCBnTCBkTELMAkGA1UEBhMCREUxIDAe BgNVBAoTF1VuaXZlcnNpdGFldCBPc25hYnJ1ZWNrMRYwFAYDVQQLEw1SZWNoZW56ZW50cnVt MSMwIQYDVQQDExpVbmktT3NuYWJydWVjayBSWi1DQSBHLTAwMjEjMCEGCSqGSIb3DQEJARYU Y2FAdW5pLW9zbmFicnVlY2suZGUCBxWm3SXtmbEwDQYJKoZIhvcNAQEBBQAEggEABJqxTgyv 1x/zocqOjXizXSpa0Lpa++ONFhItrhQUGdAIYaw600kwwl686ds4CLDRBOqlmqrQg4YOb8QR eSqVyK4OR6VZ65MBJ5mHVDKepgUBoZM7gh9LX4DUW4xVdvvsjBvUhhtq/JXC/2VfBBoNhSMH 8fJgisL5+k7YRgG3sgCJm0mQq2er9qRWHSlNssbUUb5SGbfvOTFvcVxDCBbEL1JYgT0dPd4U V/1WppJBkex2+7Wf2EA3kBDdFTmq5yg4C1mYgLb0647A1wVYzxufidcRCFiYjcroEVXu3pdC N+JJII0RN0nVqsZiOzU3K271xH136pFF5UkUKsvdCtNapAAAAAAAAA== --------------ms020609010007010102020405--

1 0

Re: (ITS#8022) Backend Meta does not work with ssl-backends
by hyc＠symas.com 12 Jan '15

12 Jan '15

dirk.kastens(a)uni-osnabrueck.de wrote: > Full_Name: Dirk Kastens > Version: 2.4.40 > OS: RedHat SL 7.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:638:508:3d0:579:e63b:2c0e:3a09) > > > This is a duplicate of #7983 Then you should have simply followed up to #7983. Does ldapsearch work against the target servers using the certificate configurations you listed? Without a reproducible test case you'll get the same response as #7983 - no evidence of an OpenLDAP software bug, take this to the -technical list for help fixing your configuration. Or take this to RedHat support for help using their build of TLS software. > I'm running an openldap server with a meta backend that combines the > trees of three different ldap servers. Two of them are connected via > starttls and one via ssl over port 636. This perfectly works with > openldap-2.4.23. > Now I have upgraded the server to RedHat SL 7.0 with openldap-2.4.39. > The ssl server cannot be reached by the meta backend any more. I > manually compiled openldap 2.4.40, but the effect is the same. I tried > openssl and moznss, but this makes no difference. I only see the trees > of the tls connected servers. > The tls servers also speak ssl, so I simply changed the uri from "ldap:" > to "ldaps:". The effect is, that the servers also became unreachable. > > Here is my configuration: > ------------------------------- > database meta > suffix "ou=new,dc=xyz,dc=de" > > uri "ldap://ldap.xyz.de/ou=a,ou=new,dc=xyz,dc=de" > suffixmassage "ou=a,ou=new,dc=xyz,dc=de" "ou=people,dc=xyz,dc=de" > idassert-bind bindmethod=simple binddn="cn=proxy,dc=xyz,dc=de" > credentials="secret" mode=self > tls_cert=/etc/openldap/certs/client.pem > tls_key=/etc/openldap/certs/client.key > tls_cacert=/etc/openldap/cacerts/cacerts.pem > tls_cacertdir=/etc/openldap/cacerts > tls_rcecert=never > idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" > > uri "ldaps://ldap.abc.de:636/ou=b,ou=new,dc=xyz,dc=de" > suffixmassage "ou=b,ou=new,dc=xyz,dc=de" "ou=people,dc=abc,dc=de" > idassert-bind bindmethod=simple binddn="cn=proxy,dc=abc,dc=de" > credentials="secret" mode=self starttls=no > tls_cert=/etc/openldap/certs/client.pem > tls_key=/etc/openldap/certs/client.key > tls_cacert=/etc/openldap/cacerts/cacerts.pem > tls_cacertdir=/etc/openldap/cacerts > tls_reqcert=never > idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" > ------------------------------- > > When I search the meta directory, I only see the ou=a branch. > slapd logs the following: > > conn=1000 op=1 SRCH base="ou=new,dc=xyz,dc=de" scop3D3D1 deref=3 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=objectclass > conn=1000 op=1: meta_back_getconn[0] > conn=1000 op=1: meta_back_getconn[1] > conn=1000 op=1 meta_back_getconn: candidates=2 conn=ROOTDN-TLS inserted > conn=1000 op=1 >E%E> meta_back_search_start[0] > conn=1000 op=1 >>> meta_search_dobind_init[0] > conn=1000 op=1 <<< meta_search_dobind_init[0]=2 > conn=1000 op=1 <<< meta_back_search_start[0]=2 > conn=1000 op=1 >>> meta_back_search_start[1] > conn=1000 op=1 >>> meta_search_dobind_init[1] > conn=1000 op=1 <<< meta_search_dobind_init[1]=4 > conn=1000 op=1 <<< meta_back_search_start[1]=4 > conn=1000 op=1 meta_back_search: ncandidates=2 cnd="**" > conn=1000 op=1 >>> meta_back_search_start[0] > conn=1000 op=1 >>> meta_search_dobind_init[5D5D > conn=1000 op=1 <<< meta_search_dobind_init[0]=1 > ... > conn=1000 op=1 <<< meta_back_search_start[0]=1 > conn=1000 op=1 >>> meta_search_dobind_init[1] > conn=1000 op=1 <<< meta_search_dobind_init[1]=0 > ------------------------------- > > It seems to find both servers, but it only connects to the first one. > With ldapsearch I only see the branch "ou=a,ou=new,dc=xyz,dc=de". > slapd hangs and can only be terminated by "kill -4". When the first server is > specified with ldaps, none of the servers are reachable. > > > -- -- 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#8022) Backend Meta does not work with ssl-backends
by dirk.kastens＠uni-osnabrueck.de 12 Jan '15

12 Jan '15

Full_Name: Dirk Kastens Version: 2.4.40 OS: RedHat SL 7.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:508:3d0:579:e63b:2c0e:3a09) This is a duplicate of #7983 I'm running an openldap server with a meta backend that combines the trees of three different ldap servers. Two of them are connected via starttls and one via ssl over port 636. This perfectly works with openldap-2.4.23. Now I have upgraded the server to RedHat SL 7.0 with openldap-2.4.39. The ssl server cannot be reached by the meta backend any more. I manually compiled openldap 2.4.40, but the effect is the same. I tried openssl and moznss, but this makes no difference. I only see the trees of the tls connected servers. The tls servers also speak ssl, so I simply changed the uri from "ldap:" to "ldaps:". The effect is, that the servers also became unreachable. Here is my configuration: ------------------------------- database meta suffix "ou=new,dc=xyz,dc=de" uri "ldap://ldap.xyz.de/ou=a,ou=new,dc=xyz,dc=de" suffixmassage "ou=a,ou=new,dc=xyz,dc=de" "ou=people,dc=xyz,dc=de" idassert-bind bindmethod=simple binddn="cn=proxy,dc=xyz,dc=de" credentials="secret" mode=self tls_cert=/etc/openldap/certs/client.pem tls_key=/etc/openldap/certs/client.key tls_cacert=/etc/openldap/cacerts/cacerts.pem tls_cacertdir=/etc/openldap/cacerts tls_rcecert=never idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" uri "ldaps://ldap.abc.de:636/ou=b,ou=new,dc=xyz,dc=de" suffixmassage "ou=b,ou=new,dc=xyz,dc=de" "ou=people,dc=abc,dc=de" idassert-bind bindmethod=simple binddn="cn=proxy,dc=abc,dc=de" credentials="secret" mode=self starttls=no tls_cert=/etc/openldap/certs/client.pem tls_key=/etc/openldap/certs/client.key tls_cacert=/etc/openldap/cacerts/cacerts.pem tls_cacertdir=/etc/openldap/cacerts tls_reqcert=never idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" ------------------------------- When I search the meta directory, I only see the ou=a branch. slapd logs the following: conn=1000 op=1 SRCH base="ou=new,dc=xyz,dc=de" scop3D3D1 deref=3 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=objectclass conn=1000 op=1: meta_back_getconn[0] conn=1000 op=1: meta_back_getconn[1] conn=1000 op=1 meta_back_getconn: candidates=2 conn=ROOTDN-TLS inserted conn=1000 op=1 >E%E> meta_back_search_start[0] conn=1000 op=1 >>> meta_search_dobind_init[0] conn=1000 op=1 <<< meta_search_dobind_init[0]=2 conn=1000 op=1 <<< meta_back_search_start[0]=2 conn=1000 op=1 >>> meta_back_search_start[1] conn=1000 op=1 >>> meta_search_dobind_init[1] conn=1000 op=1 <<< meta_search_dobind_init[1]=4 conn=1000 op=1 <<< meta_back_search_start[1]=4 conn=1000 op=1 meta_back_search: ncandidates=2 cnd="**" conn=1000 op=1 >>> meta_back_search_start[0] conn=1000 op=1 >>> meta_search_dobind_init[5D5D conn=1000 op=1 <<< meta_search_dobind_init[0]=1 ... conn=1000 op=1 <<< meta_back_search_start[0]=1 conn=1000 op=1 >>> meta_search_dobind_init[1] conn=1000 op=1 <<< meta_search_dobind_init[1]=0 ------------------------------- It seems to find both servers, but it only connects to the first one. With ldapsearch I only see the branch "ou=a,ou=new,dc=xyz,dc=de". slapd hangs and can only be terminated by "kill -4". When the first server is specified with ldaps, none of the servers are reachable.

1 0

Re: (ITS#8018) a lot of warnings building with -Wall
by h.b.furuseth＠usit.uio.no 12 Jan '15

12 Jan '15

On 01/06/2015 04:31 PM, hyc(a)symas.com wrote: > Leonid Yuriev wrote: >> Yes of course, all warnings could be hushed by compiler options, but >> this also hides the real mistakes. >> So, I prefer fix the warnings, instead of disable gcc/clang features. >> >> Please review attached patchset and merge. > > Your patch assumes CPP features that are not guaranteed to be present. > Rejecting this patchset. The Debug() change is going to give merge conflicts all over the place when your <https://github.com/ReOpen/ReOpenLDAP> and OpenLDAP pull updates from each other. How about defining Debug1(), Debug2(), etc for 1,2... arguments? That's still annoying, but it keeps the code C90-compatible and keeps -Wformat quiet. There's already similar code for Log<N>() in include/ldap_log.h, but it was never used much or even merged into RE24. (Because it got scheduled for RE25 which was going to start Real Soon Now, IIRC:-) -- Hallvard

1 0

Re: (ITS#8021) Wrong mdb_env_sync() with at least MDB_RDONLY
by h.b.furuseth＠usit.uio.no 08 Jan '15

08 Jan '15

On 08/01/15 20:52, h.b.furuseth(a)usit.uio.no wrote: > Users are likely doing the same thing anyway: Using MDB_RDONLY > instead of MDB_RDONLY|MDB_WRITEMAP on WRITEMAP-written DBs. Er, I mean if any users are doing this. But users do come up with things that the developers never thought of.

1 0

Re: (ITS#8021) Wrong mdb_env_sync() with at least MDB_RDONLY
by h.b.furuseth＠usit.uio.no 08 Jan '15

08 Jan '15

On 08/01/15 20:59, Howard Chu wrote: > mdb_env_sync() shouldn't even be doing any work at all if the env was > opened RDONLY. We should return nop in that case. RDONLY means RDONLY! Currently it syncs changes written by another process.

1 0

Re: (ITS#8021) Wrong mdb_env_sync() with at least MDB_RDONLY
by hyc＠symas.com 08 Jan '15

08 Jan '15

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: lmdb 0.9.14 > OS: > URL: > Submission from: (NULL) (81.191.45.22) > Submitted by: hallvard > > > mdb_env_sync() works with MDB_RDONLY at least on Unix, but > it syncs MDB_WRITEMAP changes incorrectly: fdatasync instead > of msync because mdb_env_open() cleared MDB_WRITEMAP. > > Users are likely doing the same thing anyway: Using MDB_RDONLY > instead of MDB_RDONLY|MDB_WRITEMAP on WRITEMAP-written DBs. mdb_env_sync() shouldn't even be doing any work at all if the env was opened RDONLY. We should return nop in that case. RDONLY means RDONLY! No writes, no calls that will alter the storage layer. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs