- openldap-bugs - openldap.org

Re: ITS#6290 dynamic group documentation
by jonathan＠phillipoux.net 16 Nov '09

16 Nov '09

This is a multi-part message in MIME format. --------------060504090007030105050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 16/11/2009 03:30, hyc(a)symas.com wrote: > Yeah, the example should have used groupOfURLs instead of groupOfNames. Notice > that "member" is not a valid attribute in the groupOfURLs class: it can not be > used to store static members, only dynamic references. Quick patch to fix this attached. Note that the PNG image in admin/allusersgroup-en.png needs to be regenerated from source SVG - the PNG is also attached. -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org -------------------------------------------------------------- --------------060504090007030105050009 Content-Type: text/x-diff; name="admin-guide-its-6290.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="admin-guide-its-6290.patch" Index: images/src/allusersgroup-en.svg =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/images/src/allusersgroup-en.svg,v retrieving revision 1.1 diff -u -p -u -r1.1 allusersgroup-en.svg --- images/src/allusersgroup-en.svg 7 Nov 2007 22:52:55 -0000 1.1 +++ images/src/allusersgroup-en.svg 16 Nov 2009 10:15:30 -0000 @@ -106,7 +106,7 @@ y="78.033184" id="tspan5379">objectClass: <tspan style="font-weight:bold" - id="tspan5396">groupOfNames</tspan></tspan><tspan + id="tspan5396">groupOfURLs</tspan></tspan><tspan sodipodi:role="line" x="116.88309" y="92.036435" Index: admin/overlays.sdf =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/overlays.sdf,v retrieving revision 1.46 diff -u -p -u -r1.46 overlays.sdf --- admin/overlays.sdf 19 Aug 2009 17:23:43 -0000 1.46 +++ admin/overlays.sdf 16 Nov 2009 10:15:31 -0000 @@ -551,18 +551,23 @@ directory. In {{F:slapd.conf}}(5): +> include /path/to/dyngroup.schema +> ... > overlay dynlist -> dynlist-attrset groupOfNames labeledURI member +> dynlist-attrset groupOfURLs labeledURI member + +Note that we must include the {{F:dyngroup.schema}} file that defines the +{{F:groupOfURLs}} objectClass used in this example. Let's apply it to the following entry: > cn=allusers,ou=group,dc=example,dc=com > cn: all -> objectClass: groupOfNames +> objectClass: groupOfURLs > labeledURI: ldap:///ou=people,dc=example,dc=com??one?(objectClass=inetOrgPerson) The behavior is similar to the dynamic list configuration we had before: -whenever an entry with the {{F:groupOfNames}} object class is retrieved, the +whenever an entry with the {{F:groupOfURLs}} object class is retrieved, the search specified in the {{F:labeledURI}} attribute is performed. But this time, only the distinguished names of the results are added, and as values of the {{F:member}} attribute. Index: admin/allusersgroup-en.png =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/allusersgroup-en.png,v retrieving revision 1.1 diff -u -p -u -r1.1 allusersgroup-en.png Binary files /tmp/cvsEkGNLJ and allusersgroup-en.png differ --------------060504090007030105050009 Content-Type: image/png; name="allusersgroup-en.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="allusersgroup-en.png" iVBORw0KGgoAAAANSUhEUgAAAaMAAABsCAYAAADHXN0hAAAABHNCSVQICAgIfAhkiAAAIABJ REFUeJztnXecFEX2wL87s5HdZZe4JIkCKmIigyhggMPjlKAIKEbEAKbzPL3g6ZnwZzgVFRUV 9cSAopJEPZKCZMlIhiUvcQPLApvm98frdnp6e7p7dnd2dqG+n898dru7pqr6dU29rqpX70Wh KE98ka6AQqFQVEWiI12B05CmQE6kK6FQKBRViHeVMip/soDsSFdCoVAoqhD5nkjXQHFakQ60 t/hfUfl5CRgT6UpEgHTKp52eqfIrN5QyqhjWIetJxcioaTFwP+A1pckBahnO3Qgsr6A6KhQK RcRQyqjiuAWIBZoBzwKjgc9MaQqAv1ZwvU4Hqvp0c1Wvv0JRZpQyqjiKgULgKDAN+CMwEOhg SPMf4G6gXpA8BgJDbMpoouWdA2QCHxmuZSCK7hdgG/A5EBPqTQDPAXuA48BvQG8X3ykk8J5e BZ4xHL8AHELW27YBnbTzjZD7ydbq/3fDdzKAx4FlwGqHfMycDywAcpFpmttCqKtb2gNrkecw HXiPwGkcq/qXpV4ZwD+B+cAG4GMg3qZ+lwBrDPVLNV23a0tuCfb8WiC/g0u04wbIc+uhHdu1 sQzgXmATIqeXgbOAn4A8YBaQbErvVi527c1MRcjPLg+7thKqjBSnIT4gxeL8OuAmi/OrgYcN aQYhDe517Zx5mu5t4JMgZXuB9cArQAKiaLoYrmcgIzGv9llCYAN2y0CgJhAFDEc6/mratXSs 14zsOtIuWto62nEjoCHyorQK6cBjkQ5rIyIj/X6+1u4zyiYfMzHADqSj8SAvAzlANxd1dUsM sBsYpR13RToFszIy1r+s9coAvkGerUfL+zmb+u0EHtLKvhzppPT6ObUlNzg9vxGIoqkG/ICs uejYtbEMLX0q0Bw4AiwEWgNJiNJ51JCXk1zSkXbqVF8jFSE/uzyc2kqoMqoMTIx0BU43QlVG s4CnDWkGIY3nGPImE8qaUVek0QWb8snA31hBpgpfMxxP0tJYfWbYlLsV/wgkndCV0YXAQaAX gSO1TsgbqnFdbTQyotPvp6fhWrB8zHRH3sKNswLjgDdc1BXcyekyYK+p3C8pqYyM9S9rvTKA qwzHvZDRoRXdgQNIR6rzraF+Tm3JjQycnh/AVGT0uAaIC1IWBLaxDOBKU72NcniQwI7NSS7p SDt1U1+dipCfXR5ObSVUGVUGJqq56shSB5muMLId+BR4ApgdQl71gV1IpxUMo8n5CQKNJUYS vEPIN6W7B6itldUAedsqLauBfwAvAi2BmUgn0Eirz3pD2lj8U1ogP0infA6ayktDpoCKDed2 Au1c1teNnOoC+0zX9likN9a/rPUC6SCN/6cFSZem5W3cpL3D8L9TW3IjAzfPbzyikO4CTpny t2tjGYb/T1ocm+vmRi5u6qtTEfKzy8NNWwlVRhFHKaPI0RKZ951vce0ZZH47PYT89iGjKS9Q VIr6vIdMN1ixHOgDtAGeR97aNmrXNhP4hmhFPoGNPwWZttJ5V/vUAiYg0w+TgMPAubj3bGGV zwOmNAeQjseD/8fcGH+H5VRXN3I6iHSgRhoRfKRSHvUC2XC9xvD/Aaw5gChMI3WRqUVwbktu ZJCB/fNLQkZ37wNPApORF7PStjE7muIsF6f6GqkI+dnl4dRWqiTKgKHi8CDKvwZwDbLoORnr abjdwAf415N07AwYliCN8XlkgTbUeeqRwEVBPjdraZKREVW6dnwVolSdWI1/2qAx0M9w7Txk ztuDTE8e1/5fhHROTyFz5gCtCL4nJFg+ELjWthiZ339Uu94OGIZ/OsauruBOTouQDu0+7bgL 0sHYUdZ6ATyCrBOkAH9DFLqOWQYeoK923BQxqNFxaktuZWD3/F5D2v6dyNTU29r50rYxO+zk ouNU34qWn10eTm1FobBdM/JpnxxgKfLGHm1KY1wsrYd0qG4NGEB+FDOQzjgT+NBwLQMZien8 A38H4JYoZF56KzAHMbRYh7+TTMd6zagTMtJbjiwmT8Q/h90JeWvNQRaqp+A3QmiIKOws7br+ 1mh1P3b5zECsi3QuQBZ0c5GpkDtN+QSrayh0RKZ8dGurD5B1Oh1z/ctarwykTW1CZPAJ/k4V SsqgPbASsa6chkwNG9e0mhK8Lbkl2PO7FllTq6mlS0La1DCc25hZbp/jNxQBsUb9ynDsJJd0 /O3Urr1FQn52edi1lVBlVBmobGtYVZ5gykgRObxIJx7pOfLJyBpWuLBSbjqVRQaRwE4ubjmT 5VdRKGVUzihlpNDpjN9ApBfyBnt2GMsrj073dETJpWqgrOkUijBxATJVGIuY6I5App4UCoUi 7KiRkUKhUITORGVNp1AoFIqIo5TR6U06KqSDQqGoAihlpFAoFIqIo5SRQqFQKCKOUkYVQ1lC OziFjShNSAeFQqGoVChlFH68wHfAFsTBYV1Kej64CPH03AoJvmf08H0V4j4oGL8iZsRJyA7w L/C721coFArFGYiVaXdZQzuEipuQDgqFQlGZUKbdFUBpQjuE4nZkJBIUbA+icBpTtpAOCoVC UeEoDwzhp6yhHewIh7t9hUKhqHDUyCj8lDW0g50BQzjc7SsUCkWFo5RR+ClGDBDaIJE9DyJT a26xM2BYgoQTWIe42+9HYKRKhUKhUJyBKN90CoVCETrKgEGhUCgUkUcpI4VCoVBEHKWMFAqF QhFxlDJSKBQKRcRRyijyOIVFTicynhMiVe7pRGNgAVCAGLcMimx1FIrKi1JGlZ8ngJ1lzGMP 1oplILAYyANygf8BPcpY1pnCtcB84Biy12s1MJrADcd/R1w9LQIewu8pw0eg/8H3tHOfGM7p 6XzI9oAjwGSgkUUaY14KRZVEeWCo/HwcpnzvAv4PGAXMQDq1K4EbgXlhKjNcxCCjj4rifvz+ A1ciHtO7AK8jTm/v0K410/5O0D6lYRVwGLgUGADEIvvJFAqFIijB9hmdj0zX5CLTX7cZrmUA DwCbEB91HyOeGnTS8Y9qGiGhKLK17/3dkC5YmIq3EL94+7S8hgMJWpphFnXV3+yN5dqFqXgB 2cybhYTA6ORw3ikkRjetjBPIht63Ebm+YUhTqJ0bpdVzh3a+JTAFkc9JZNSn1zUV/0gjUTv3 qnY8xiLvR7W8TwCf4veEXkOTgw940vC9fob8OyLP22f6nEPoIyM93SPa8TabNEY8wEvAfu2e jiIjuTSLtApFpJkY6Qqcblgpoxiks/w70kF0QBSG7qk7AxmJpGrfnY90/jrpiFLwIG/JY5C3 4waIP7pBiN+79cAriKIxuxwyT9NdinRQRqVnRi8XRIHURBTVcETBVNPKSAfqaOkaAQ1tzoMo F2OnayQFGQX4EJl8ifjzC6aMjiPxn/6LuEbSO+c5iAIpRkZMHQhURrpisVNG64G/aH99yKgH ZHpOnzozP+vN2rV/IqOnXdrxj1pZdSmdMooDxmvHk4OkMdNHu7YGeBwZBS8FWlikVSgijVJG 5YyVMuqOjBCM63Pj8HeuGQS6++lD4NtvOqIUOiFv/F7DtdFIZ+wUpsKsjK5FRkZ26OVaoYep uBBxb9SLwICAwc47cSMiwz347/N7giujEYZzN2nn0vHLeqJ2bjyBykhXwnbKqKd23Es7Pqod 36EdH7Oo/zwCFdcs7fhWQ5rSrBnpnzmIQrPLS2eAdm0B8sJyHsqBrqLyojwwVABpSKdRbDi3 k8Dpkj2m/62mUhohb8jrkRHRRmRRPA53YSqMHEFGEnYjIyPBwlSsBv4BvKjl+QXSWQY770Q9 7e9m/B7ON9ikn2v4Xx95bcYv699M18x4g5wHv9GI/rcGIuvD2nEiUN30nfra38MER39GxrL1 lwirda/5iBICGeE1tsnbyExgOvKi8iXSbrYhU4UKRaVDKaPwcwBRJEZZN9bO6xg7y0amazoZ SCd3LtKhnAM0B/oTGKbCCp/p+FfkzX6ARVrz27MepuJGrW5NEYWkp3sXaIcs1ifgX8cKdt6O fdrflvjvpY1N+pOG//cavqvL+lzDtXxDWn30amdS39aUJhM4hSiHE8j9P2BI3xeJ1Avwg02+ unLrqP2NRuRkvGbkXeAKZNoxCVkDdMNJZB2rNjI6n4I8i1tdfl+hUFRhgq0Z7QQeQzrJdsh0 26Xa9QzkzTcFedP+Cen8ddLxrxmtAf6NdO4gnZ9+bT2yLmAVpmI1cL2pXiORDnYoMoWViqwN jTOV2xnpzPVR1FX4Le/OQ97WPcg61mfAWJvzYG/AUB3/mtFiYCr+aTOraTqjmXMyosx8wM/I aKxYS6t3/Fu061OBD/BPf1lN0+1Dps8OWJT/kOG7v2rl6d/70JDOapruVsN3lyJTnj5EwRnD f5in4FoYyuhtSrMVkZf+uQy4Gpk2fBZpe6vwG2YoFJUNtWZUzgSzprsAWIhY0+0C7jRc063p NiKGDZ/gVzYQuHbTEFnAztLSLkfWmEBGLDOQEU8mgZ3iUK2cLALXWQYhYSis9hnp5UYhHfFW RGm+joSsuBJZN1qj1SULefuuY3Me7A0YQAw7NiBv9t8gIwMfsr6jY6WMAFrjtyg8hXT2fQ3X eyHGJCcRhfQpwZXRndo9n0DW5RIJZCB+C8mT2v0+SOAI2EoZAdyLvDzkI0YYP1Nyf5fVepC+ BvazKY35cx0yoluIyL8IWbccj994Q6GoTChlVM6EI4TETuDics6zMpNsOp6NyPXhCio/mKJT KBThY6La9Fq5qY2MKPY4JTyNeBNZR1mDTPX1QkZ6n0ayUgqFQlGVKM+RUQdkCmiMU8LTjEcQ 5VuIKKFp+I0JKgI1MlIoKh41TVfOqEivCoVCETpqn5FCoVAoIo9SRgqFQqGIOEoZhZ/ayPTd xnJOW57fBVkryTUd+7R8Ac7Wjg9bpPEh3gM2EGiKbM7DDjf1N9exvBmE7EVyexxujPItQszt K2KfUFnbkplwP7fKhJKdbLHQt4wcR7yB1Lc5DyhlpCgf/oVsED0H2d9UzzZ15aU/8G0IxxXF v5DNq6mIN3Q7r+cKRaSph/imfATZu9gH8cAS7LwiDFgZMFi9Ka1AvDAUIZtRX0Hc3+hptyCb S48hm2T/ZPhuX2Sz6ynE79t7yN4cq3KCpQW4G2kYRxGvzmUZGelpdC/V7YNc18MqWLnhsaq/ Ux2d5JiOKMfjlJSjuS4xiPVeV5fH/bTy87X6/RfxbA5+WS3TjqO14wxD+V7tvNVHxyw/3bHr m9qx3fO1q5+TfEJtS2acnttVSMDBE1rZH4Qol2B1GarV+3Mt3Wva8SPacbD2Ug//7+5d5M19 OeLFZK5WzlzEP2FVl53d9+3aTCgyMroUG6F9722b86Cs6codt8ror4hLlyuAr7XrNxvS+hC3 PI8hD/k44mj0fGQ6bIn2/b/id0FjLscu7UWIq5wsxPuDXofSKqPzEM8JJ5EfUmKQPEJRRm7q 6EaOjyLTa8fwy9GqLlcjHZTHxfEF2r0dRtwq6a6FvjPJaol2bKWM1hnqaP4kaWl0+V2slblS O34c++frVD8n+YTSlsw4Pbc2SGeXB/wNCUlifDt2kotTXSbgV9jFiFcSvRMM1l7qGcr4APgK /9ToS0gnq8uqKsvO7vtObSYUGen00up+CPlN2J1XyqiccaOMEpE3i52I25qT2vWXDGkP4P8B 6Q1yINKA9AZQiL+z2mtRjl1aPVCbHq20BiU7+gKsldEhQxrjmoYP+UF2tbiu56G/uVlhrr9T Hd3IUXe8CjAJvxyt6vIW8I7LY122/6cdxyAvDUWIDz9dVou161bK6GLEP6HVR1eAZvnqeaZg /3yd6uckn1Dakhmn5/Y303UzTnJxqkuiVm/j70I/H6y96B3tIeR31107Xql9d4h2/Banh+ys vu/UZkKREYjbqWyt7rrDYrvzygNDBBihfSYjQdiuB54ieCdtFYNmAoG+2oot0til1f216V6v T1l87yjyplcPeVvS14GswiMMQUZGo5A30o5Yh0PwIj8KPWCeG4LV0Y0cYxD5+ZDwD8HqAhLj SfcZGOVw7IT+PHTP47Us0vyX4B7Jkwl8MdADGu7B7/BUx+r5XueynnbysSKUdmfXtiB4bCUn uTjVpZohXRJ+57tu2ssRRBZ629W95+vyNq6xV2XZlSWulVsZRQH3If2IMQxMsPNBO8BIcTbi HLMxMnx8wz55lSRW+5uDPMB+FmnqIm8Y6YjiyEOcY25GfkD9kWmmg8gbSpJ23sg0m7R6MLeh iPPT3pRkCvLj/QQZqvfXzlst4M9C5ukvQUZG9+APMGdkDqK02iJTCnb8z6GObuRYG5mT3oEs lupyNNclEZHLbO1aR4fj6Yj39NuRZ9RRq893SEeSgXQkbYDBWCuHwQQ6xDWSZzqeScmXALvn O96hfvo0oJ183JY1GnmrronEsHJ6blO1vEZo97Qb8XbxtHbdSS52dbkf+Bix0Por8Azivb0r 7tpLKFRF2dl936lNh0oq8CQSU+w7F+cB/zxjMTJ8Wow8VK8pTQ6Bb3g3IgtY5clY4OVyzrMi cTNNVwPpvPMR5fKxdv1VQ9otiCLORRqM2YBhKdLZnUDCQ9xmUY5dWpCF0kPIM3+VkgulSci6 VYZ2bS/ybIxvgeZpuK74h/LVLa6XxoAhWB3LKkdjXcbgX/TGxTFIZ7ZSKz8TUdrG38e92vmj iAWceZrODU6m8XbP165+TvIJtS2la+lTtWOnttUbWUM5iUztvm8rBff3/RetHq9o6fT1mZex by/6FJR+v5214++1Yz0C8dtUfdnZfd+uzYQiI5AoAj5kJG8k2PmJIIpmODJKqqlVaAsyD6qz Dhme/Z/hXDiU0de4nwqJJDWRuETdTOetlJGi4gl1r8dGpD27Pa7qlOdemASkg53LmRHWXMku PPyujG4yXWiNzKV30I7XIcPIHPxrB2Zl9AKi0bOQ8MadghR6Pv44MOn43xA+QoaSh7XzrSy+ W5E0Q95o7kUWOScjZo9ZyFvDCkqO4pQyqhyU98bD043ylE8fpF9oWg55VQWU7MJDUAOGTYgC 6o5/r8RGZD3nb8g0npEuyHzleYhCaoT1AnUMMof6HhKNsh0yD78ZuAXpyKdr1yuKGKTeF5k+ Oci85g7tswhRktsRZaSovBxGvWnaUZ7y+R6Zkj1TULILE3YGDIeQeVYjTyHznS+azuchVixt gfkEj7/TGVmLeB5Zo1qGDM+GAL+EUvEykARcjti6X46YF25H5jBXIcpwJTLXr1AoFIoKwE4Z 1aFkh7wdCXL2BH7LIhAF9Q9ESbVErH9GI5YjRtIQRWU0a9yJjJDCRQyytnMF0BNRmEuQ+t+n 1b001iIKhUKhKCeCKaOWyNrOfItrzyD24emm8+9qn1qITf3fkV3ERg4gU3ge/AqpMX5b9fKk CzAMuAExyJiFKMxFBLffVygUCkUE8Bj+RiPTctcgU1WTsbaW2424g3jYcO48xNjBg981hpUT 1sXIlN6j2vV2iMIwm82WluaIDftWZLf8LmTvSzfE2eQ8lCICGaH+gMhpL+L+w8iPiNNTJ+w2 rp5Edm6Xlicoucnw38j64lbkBeM/2vnyKK8slEfZ5vuNQwxntiH3uwpxPVMWDiO/ie1avreW Mb/ywouYPteJdEUUkcXozygHaRQPEDhqWkfgD6EeonB0ZdUJWKN9PwvZMBmsYV0ALESs6XYR aMr9LaUz7W4PfImMsF7UyogEVcWargFwofb/hci+Ar0zvQrxO+UGO2XUkbIt9BYS2AY/QV6Q 9HXMeMSQRt+fEUllVNZ7hZL3+wXSpvUNqm2QF8EBQb7vDXLeyGH8e7y6IM+9fvDkpS6nNNxJ 1d5jqCgbVd43XTNkDSsdWaNKtE0dfsKljAYgLwRrEUMP46jFh4z6vkTWvwYbrvVE1sfWIG/W fSzy7oW8FOhv5V8Q+OLhVPZTyIh3i6lso3Kwq8dVwK/atTVa2ue1vH9CRrMXICNqO9kay/sM MY7ZgOzyNvon+xpYr5U51eG8W4xll+Z5BLvfVAK5Bb8vML2sZ7X63qOduxl5FgsRy9dCQ3qj MgJZE9Z9Cdo9I3M5dvIqbVtNQdaYw6XsFJWbKquMopAfxUFkbSqYC4yKJhzKqBEy2myhHd+B /JCNZeq7v5vhd+BYBzHH1/eFnYVMyRkVdjvEbN1oQHJAS+u27NHa/02QjdH6m7beQdvVo572 nYu1ax788jOOFG5AOj07jArBaAX6ODLdBSXjESU7nAeZzkwP8qlmUXZpn4eb+22JrLXqHbaP wA79LEThNNCO7ye4MuqDTFnXcVE3cznB5FXatqqzlvAaMykqL1VSGcUjb76LkR9nZSIcymgI fpcbIB3RKfxv+z78frdA3qhjkQ7tIPKmrX82IxuadRYha4Q6MVp++jqMm7KN9zsd/6hK76Dt 6nEj4uLfirIoo4eQkcHPyFu+fg9NkFHgG0jnmuxw3i1mZVSa51FaZVTNcH0IshdQJ4WSymgv cq+r8Hswd6qbuZxg8iptW9X5EfdOXhWnF1XOa7cXmUbKQfYIKWMEId/wfzEywvAgb5pX2HzP i2xw1tFd3Mdj7XW7NNjV4yLcrbWsRPaDpSA+u+zohvj36qil/QPwZ+3aTmTtpZdWn+eRkUKw 83mIFWYwY45WlHRqCqV/HjqrEKMg8/12RabRigznrMq3ozclndS6qZuxnGDycoOVbHTiEfc4 CkWl5zlkIbuy7q4P5zSdHoTKaurDSC7yo07TvtfDcK29Ke0fKVnf1YgFotuy9Wm6plhP09nV Iw15W9en6bz410myCZxu+wwxYNAjT8YDD1LSgKEv8mav8yGiUECmr/Qp3ThgP2KBGey8W8wj IyNun4f5fr9E/EPqBgznIQYMxvU8c1mNcT9NZ8SpbuZygsmrtG1V54Ch7oozi0oxTZeBu7eq 1oh7nkhZTLkhXAYMA5F7/w2ZfjIGpbL7gffAv5C/EenMjWQgoxMjTyHejt2W/S+tjG0EOhM9 id/Dt109rkRGAr8hb+c9tPPP4DdpTkCmc57VyklHFulfoqRpdwxiDfg/ZBT9Fn5l1BsZWazW 6vG0w3m3uFFGYC8H8/0mIKbruhm2ecHfqiwQc+3tiFXs08hWC51gysipbuZy7ORV2rZ6If7I uIozjyqljF7H/xZeWakqpt121EOmxcpi1ZSMTOtU1hHs6YxxbWc4fkVc2XkTCXinODMJuzJy syblVhktp/Jb2pwOygikUzjbMZU1bZA1BXOwP0XF8CzyW1mPeMePtPd7N3iRjfCKM5eJEDz0 QyPEw3Y2ojD+bvjic4iPuePIcNwYkTADMaddhvwgQKxvpiGGB5lIuAhj+ru0fPIQbwwxlGQd wUPqVhZOF2WkUCgUFclEkPl33VtCI6AhYuGyColwGYssKm7Ev3g6EFlIjkKmArLwTw9kIBvi 9BjxXkQpvYLMg8cgu78xpP8B8WlXVyvnNkryGZU/wJlSRgqFQhE6E6OQ/QU3Ik5RdXPeTojN f038ZqSjEbNZK4WwFfExtwRRLkOQ6IUg5qjTEIudQovvmtM/jyg2s5PV3oiJ7tVu7y4C+IDU Sa9MyvckxLnx7aZQKBRnJPkez+6hI/sd1g4nRmMd+qERYgm13vDdWPxmmiMRDwi1EQXTAL8J Ksi0n059ZIOclSKySn+cknGUQEZPoxGXKB9ZXK80xKXERZ8s8IXq8yvsjHnj6WmAZ9A1g285 u1mrw45fqEBefnvMhG4duj/XuV23LeZrE74Yf0dUVFTxrTfcOaG88jTy4rjnJl5x6dV/u6Rt +52h1vtMw61MnSjtM63qKPn5iZatIMZjy9APkxAz0HMpaY7ZBhm9dMUfenczwS2n9iHuRbwE btYrDXcj/rsOIT7HFKcJLZqe/UnD+meZ419VujwVCkV48GAd+mER4kTxKfyb21ohG+GSkV3S 6dr5q7B3y7ME2cz2PP59IF1s0tuxB7H0egfZUKeIMCdOnigXLx7X9Rk0+6wGjZ28K0Q8T4VC ER6igfeR3fPFyKjj39r/f0D29uxHFNRmZErvB8T/1Tpk+m0dgdN5ZooR/2dvIiOaQiTExKJS 1nkF4mH4G8Ql0GicXcRElDFvPD0DoEXTlm/u3JN+Q3FxcULjho0/q1+3wdZf1yy7v6CwoE5q So35t99416sx0THFABs2r683d9HsO3OPH7vA5/PFVEtI3NCtQ/d39Kmk0uSps2bDqkum/PjN DYWFBbVSklMXDel/82spySmnXJY7DfA0b9zi7d37dg0AfH+++7HbZ8ya2q2ouCj6T1f3/ymI DKbdeO1Nw5ue1SwT4IPP373L6/WevOX6Oz6GwOmLpSsXtfhl2fyHCwoL6iRWS/wtNiY2MyYm NidUuRvzXLF2eZMFS38adfLkyeZerzenWeMWnw7oe/3/9LQ7dm07d96iOY8XFOSnpSSnLL7l hjtfTohPKASZxmtYr9E3h44c6lxYVFAjMSFxs/G6GbuynOTglhfHPTexft0G049mHbm4sLAw JbFa0uah/YePTU5KzgfYumNz7R9+mnnf8bzc86OiovIbpDWcOmzALV841c8pXyN2ZZhxeqab tm2oO2v+j/ccz8ttCxSnVE9dPPKm+14JRSbB6rN+09r6M2ZPe7VHl55/63hxl207dm2r+dWM L97scGGn53p0vWLtR5Pev+XQ0YNXFBUVJcXExB684JwL373yst4rdHk0bdTs0937dl1bWFhY q06tujMv7XjZlJlzZzxy4mReq2oJib8N6z/8mZo1ap2o6vKzy8OpzYQio2B4EHf11RG3Ktfi X7/Zi1jNpWrX2yNOEH3AKGQfSi/E5cj5+DfX1aOk76t0RCElI+tBtxqumdM/g0zH2bEVMbI4 hijCYVSBDZbpu7cPS4iPTy8uLkpK373jzqUrF/8jLi5+D0Bm1tErZs6Z3h3gaOaRhBlzpr6Q cyy7S/Wk6r/WqVV35vG83LazF/z43P4De5NLk6eR7Tu33Vw9KXmtx+Nm7zjrAAAORUlEQVTJ y8rJvPyr6Z/fFmq5O3Zvvy2xWuLGpMSk3wD2H9x78f4DezuUVUYnTp6I/nnJT/+sn9bgf4/c /djgNq3aTj6adbRHWfOc+8usf9WqUXv5I/c8Nqhr+0uf35q+eeT8JfPO09PsP7iv25Brh/1l yHU335Z3Iq/5zDnTexrzyDmW3eLeW+9/9P47/jziVP6peubroZRVXuTk5rS455b7H3twxCN3 FxUXJXz93aQhAMXFRVHTZk15MrFa4q7Rtz88ZNA1g0cfOJTRa/qsKZe6qV+wfI3YlWElE7tn WlBY4Plu9rSnEuIT9t0z/P6ho29/eOj5rdqGNA1vV582rdvub9GkxYQFy+b/JftYdtyM2VMf ql2zzqweXa9YC1C7Zp2tw/oPv+8v9zw+sHnj5l+uWLf8sexj2br3EA4czuh808BbH+p31XX3 HT566Mrv5kx7rEeXXmNHDL1nqM9XHPP9vBlGZ8NVUn52ebhpM6HKyIqq5ijVSB5wH/AxMup6 EPgngV6DKxVtWrd9o2+vfoteeeeFd/IL8hvVrlXnf7cNHvH++IlvPXAk88jVR7OONAd+mr/0 p86FhYW142Ljdva7uv84gG9nftXw2PFj7Rcs/fmy6/sNmRFqnsZ6tD33wrG9e/Rd+sO87zqu XPfrv45kHukJvB1KuWc3bfnuwGsG/y7rO4fe80Z5yGjZqsWtfb7imBv6DZni8Xh9Pbpesfa3 zetWGNOM+3js47nHj1lulK6WUG3Lfbc++KQ5z2JfccKQ626a5PF4fV3aX7p5/eZ1czdv33R5 9049fgNo07rtl/XTGh4DqFWj9qKs7KMBvunatG47TR9hpqbUWGm+HkpZdoRyb62bnzNDr9M5 Z587beW6X+8HPlr868JWBQX5acMG3PJRTHRMcbPGLY42qn/W9D37dnVbtmpxplP9guVrrItd Gchm2wCZ2D3TJSsWti4sLKwxbMAtH8TFxhUBdOt4mb4e7UomTvUZeM3g79/88LWOH3z2zn8A 3w39hv5bz+OaK//0i/7/dX0GzX75nReGrN+4pmnXDt03AZzb8vzJdWunHa9bO+343IWz1icm Ju284LyL9gCk1a73S2ZOZsDG4qooP7s83LTpUGVkRVVWRjpLkHWvgYhV4PPAOCToXm4E61WC 5o1bbAfwer3HKYBaNWpvBYiOjskFKC4ujgE4npdbC+BU/qkm//1qwmfGPHLzcuuVJk8jjRs0 2QXQqP5Zu1eu+5Xi4qKk43nHY0Ipt3WLc9eUVg525OTm1IiNiT3o8Xh/N5yJj084YEzTv8+g sSdPnbTaGE1cbGyJqbOc3JwaMdExh415VkuodjD7WPbvXiZSklN/n+r1er0nCwrzjdahJFZL Ov77dY83v8CXXz1Y/Z3KsiOUe0upnpql/59avUZWUWFRKkBmdmZtn88XM/b9V8bp130+X0xC QrXtrmQRJF8jdmWY0zo90+yc7JoxMTGH9E6wNDJxU58WTc7+YdX6FU+0bNZqbGK1xN+90n81 /fM/7N6/+5qiosLqUUQVFRYV1jxx6uTvMdJqpNTI1P/3eDz5CXEJ/mOvt8Bn+o1VRfnZ5eGm zYQqIytOB2UEMnX4FeLcsSdwL+IW5XNEMTm+kZqIR5xflivR3uiAB+3xeCwbT2K1pCMAsbFx uy887+K3jdeMDz2UPI3s2rfzrHNbtcnYs393I/mONzexWmJBKOXGx8WXmAO3IyoqqvBUvv8H UVhYmOj1ekvIuHpS9czCwsKAH29+QX5KfFz876boX8/88oHjx3PbWpWTkJCwZdRtD/3TnGdB YUHt4uKiKP0HlXcir05sTGyWVR5lwaksJzmEcm+Hjx6qiwRH5NCRg3W90d4sgOrJ1TO9Xm/O gyMeudvYgQD8vHhuGydZBMs34D5tyrCSid0zTa2eeqSgoKBOQWGBx7y+6VYmTvU5mnkkYf3m tXfVqlHrxx27tg/bf2DvL/XTGh5bsXZ5k+27tt/ap0ffP+tv8q+888J4u/txoirKzy6Pivr9 nC7KSMcHzNE+DYARyObdfYjBw7eIV2InHkOmAccSgfgq3TtevnjL9k1H8/NPnbVl+8be1ZNT tp88eaJmVk7WJZe0bV/m6bC1G1Y/kL5nx4qcY9ntAWrVqDWvrOU6GTDEx8VvX79p7UWtW5z7 45btm+pk52R1qlsnrcS8doeLOm9aumpJ1A/zvuvQu0ffZRu3/paWcyy7Y3xc/O9pr+09YOyJ E3mx5u8CxMXFl4jDpOV56vMpEwfdeO2wr5atWtLiaNaRnp0v6fqk3T255b1Px40qKiqKH3nz qJecynKSQyj3tnn7xoGXtG2/DmDj1g2Da9eoMx+gW4fuG5avXnrsk68/Gta/z/WTkpOS89du WN3weF5uNTeyCJavEbsyOrfrtsVCJkGfaZf23TYtXbU4c+Lkj24deM3gT6Kjo4tXrFl2tj5N 5EYmTvWZ/N0Xd1VLSNwyYti9r42fOG70tz98Peqe4aOfP3EiL8ETFZXfrHGLgwCz5/94cX5B fpnCWFRF+dnlEe7fj05FKqN0xJ3Q8goqbx9imv4M4jniOiSqaD6ilL5F3OyXeJNAIoTORtak HkNGWLZvL+VJzRq1TvTpec1ff14y7/ac3Jx2WTlZl0ZHR2cmVUta36j+WfvLmn+zxi3+m75n x/XFxcUJqdVTfx7Q94YJZS13/8G9FxcVFcVjWp/S6XBhp3cXr1j48KvjX7wmNjbuUHJydcvI rQnxCYWXduj+7OIVC+/fuHXD4Ojo6GPVk1KWGdM0rNcoJMu6hPiEwh5dej31y7KfR700bsyN Hq/3WIsmLd+7rHNPOytQ15zKP1W7bq20ZW7KcpJDKPeWVrveL59M/vA/hUWFNVOSUxYP6HvD pwAej9f3p94Dnvhh3nd3j/v49U8AT2xM7N42rdt+7EYWwfI1YleGlUzsnqnH4/X9odcfn5y9 4Md7xn38+qdollx6Z+pGJnb1mTlneufsnOz2wwYMvxdgYN8b3psw6b2xU374ume/q66dt3Hb hoXvTnzrrdiYmEPVEhJ3xsXGlWnzc1WVX7A8wv370alIC7R0/MpoD6IcKkoxGblIK/taxNPE AkT5LEBCJxQiFn7GzncpEuNnnkPePiB1yvtTik8W+EpYsSkqlpfeHvPhZZ0uf7rjxV22hauM gsICz9j3Xxk38uZRo4zrEOEmXF4jyiPfSMmkMqDk556oKO+6G0b226Udlgg7Ho29257TgVXa 50nEVVF34FLE3LwJYhBhfmvviPjO+wZxdb+1YqqqKC17M/ZULyoqTKmf1jCsbo9iomOKHx75 15HhLKOqoWRSNs5U+XkIDPmg+56zCx8RLOSEPqLQeRWZIjPzlpZuKjJaGu6QbzjZj7g+uh+J NNkU2eibFiR9f8QY4i3EL5+iErJo+YJWEyd/NCGtTr2pygODQlE1iEKUzUIkpHGhdm4Fsl/n CaTTnYN4X9iLhHLogCiORsjU1F7tu420/ECUUa72PbCfputik28kuBfZu2RHEaKkX8Nveaem 6RQKhcIFwabpxuIPH9ERaIZ0tEWIIcCbiCLRwzu0RUJO7CmneuWFKd/SEIVY4VmRh0zxrUVC b8zALzeFQqFQlBKP9tcYwsEYPmKj9nlIO7caf8iJI8AXSEC8shKufEvDXYiRQx4yYhyLrCe1 RdwidUPcFT2BuDEqqyfyCmPMG09PG/PG0zO27thc6aYYX357zITFv/5i6XB3whfj7/hw0ntW ARcVlQC7ZxcKZ+pzVvITPBbnMvCHjzhH+zRH1ktAwk20Q0ZPCfjXk/IRhaVjF/HUykw6WL4V SRwSGt2oeHRXHlVK8VQ1VLgHheLMxkoZ2YWPOA/rkBMgo5srtf8bA/1syj2KKB0du3wrklPI 2pVSPC6pzCEkwsWp/FPeSNdBoTjdsOpI7MJHZALjKRlyAsRR6YdIBNjdSKiJYLyATH+NB/4C rLHJt8qjQkhEJoREqK7tnUIJNEhrOOXQkUNdfb7iuHp16s/KzMk8595b7n9WL+/9z965Owp8 tw8Z+Y65LiqsRElUWInKL79whpXo0fXKocayPFiHfAgWPmIJwUNOLEGm9tojU3rD8FvSgSga 3XruU63cVEQJ2eV72qBCSDhT3iEkQnFt7xRKIPtYdquRN9/3yAN3/vnezu26zj2Wm9Pu4OED iSCjpaNZRy5r07rtbKt7UmElSspEhZWo3PILd1iJSVMn3mws73TzTVepUSEknCnvEBKhuLZ3 DiVw3lQ9oF6zxi2OJlZLXD9/ybzuA68Z/P28hbPbeb3ROZ0u6VpiQ7QKK6HCSlRF+YU7rMSu vTsDXsaUMqpAVAgJZ8o7hEQoru2dQgkYw0wANG7YdFb67h19ge937NrWM6122pxg96TCSgSi wkpUfvmFPayEzxfgvFUpowpEhZCITAgJN5QmlEDPrlcuGvfx6/etWLu8Sc6xnI5XXHr1B1bp VFgJa5mosBKBVDb5VXRYCaWMKiEqhET5hpBwQ2lCCSQnJefXSKnxy0+L5jyakJCwuWXz1r+v c6qwEpEPi6DCSlStsBJKGVVCVAiJ8g0h4YYu7bttKk0ogdYtzp21cPmCq5s0avaq8bwKK1E5 wiKosBJVJ6xERYaQOBNQvunOMLZs31Tn65lfvnvHkJHDateskwcqrIQVZ0pYBCuU/KxxCiGh UChCYMGyn/+UmlJjvq6I4MwNAWCHkknZOBPkp5SRQlEKMrMz48dPfOuTmOiYQ3/o9ccnI10f haKqo6bpyhcfkDp37tzjezYfrRPpyigUCkVlJZXY7H4j++kzChMjWpnTEB/2DmIVCoVCURK1 ZhQGLkKCCioUCoXCHTXVNF35si3SFVAoFIqqyP8DrqC+qm2XwigAAAAASUVORK5CYII= --------------060504090007030105050009--

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 15 Nov '09

15 Nov '09

--vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * hyc(a)symas.com <hyc(a)symas.com> [2009-11-15 17:58:03 +0000]: > alexs(a)ulgsm.ru wrote: > > Full_Name: Aleksey > > Version: 2.4.19 > > OS: Freebsd7.2 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (93.93.136.26) > >=20 > >=20 > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > > Freebsd 7.2 amd64 > > Slapd built with the "-g" flag and install with the make install STRIP= =3D"" > >=20 > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > > In slapd config added using hdb as backend and indexes. > >=20 > > Testing database consist of 1000 users accounts with minimum attributes= =2E=20 > >=20 > > On stress test load slapd Segmentation fault in 10-30 sec. >=20 > Looks like you've had a stack overrun.=20 Is it OS issue? >The "be" parameter should be the same in your frame 0 and frame 1. I don't understand. It's need to make them same? Or what i need to do? :) >=20 > > #gdb /usr/local/libexec/slapd > > (gdb) run -d 0 > > Starting program: /usr/local/libexec/slapd -d 0 > > [New LWP 100311] > > [New Thread 0x801a020b0 (LWP 100311)] > > [New Thread 0x801a02880 (LWP 100073)] > > [New Thread 0x8034040b0 (LWP 100076)] > > [New Thread 0x803404240 (LWP 100077)] > > [New Thread 0x8034043d0 (LWP 100078)] > > [New Thread 0x803404560 (LWP 100116)] > >=20 > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=3DError accessing memory ad= dress > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 > > 511 { > > (gdb) > > (gdb) > > (gdb) where > > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=3DError accessing memory > > address 0x7ffffd9f9f38: dress. > > ) at idl.c:511 > > #1 0x0000000802d50dc5 in hdb_key_read (be=3D0x801a853d0, db=3D0x803519= 800, > > txn=3D0x80352b040, k=3D0x8069005 > > 70, ids=3D0x806a00000, saved_cursor=3D0x0, get_flag=3D0) at key.c:50 > > #2 0x0000000802d5363c in equality_candidates (op=3D0x803521000, rtxn= =3D0x80352b040, > > ava=3D0x7ffffda7a4f0, > > ids=3D0x806c00000, tmp=3D0x806a00000) at filterindex.c:788 > > #3 0x0000000802d51d10 in hdb_filter_candidates (op=3D0x803521000, > > rtxn=3D0x80352b040, f=3D0x7ffffda7a550, > > ids=3D0x806c00000, tmp=3D0x806a00000, stack=3D0x806d00000) at filterin= dex.c:154 > > #4 0x0000000802d5297f in list_candidates (op=3D0x803521000, rtxn=3D0x8= 0352b040, > > flist=3D0x7ffffda7a5 f > > type=3D161, ids=3D0x806b00000, tmp=3D0x806a00000, save=3D0x806c00000) at > > filterindex.c:581 > > #5 0x0000000802d5229c in hdb_filter_candidates (op=3D0x803521000, > > rtxn=3D0x80352b040, f=3D0x7ffffda7a530, > > ids=3D0x806b00000, tmp=3D0x806a00000, stack=3D0x806c00000) at filterin= dex.c:204 > > #6 0x0000000802d5297f in list_candidates (op=3D0x803521000, rtxn=3D0x8= 0352b040, > > flist=3D0x7ffffda7a5 f > > type=3D160, ids=3D0x7ffffdafa760, tmp=3D0x806a00000, save=3D0x806b00000= ) at > > filterindex.c:581 > > #7 0x0000000802d521e4 in hdb_filter_candidates (op=3D0x803521000, > > rtxn=3D0x80352b040, f=3D0x7ffffda7a570, > > ids=3D0x7ffffdafa760, tmp=3D0x806a00000, stack=3D0x806b00000) at filte= rindex.c: > > #8 0x0000000802d4dca9 in search_candidates (op=3D0x803521000, rs=3D0x7= ffffdbfab30, > > e=3D0x7ffffda7a71 tx > > n=3D0x80352b040, ids=3D0x7ffffdafa760, scopes=3D0x7ffffda7a760) at sear= ch.c:1206 > > #9 0x0000000802d4befa in hdb_search (op=3D0x803521000, rs=3D0x7ffffdbf= ab30) at > > search.c:586 > > #10 0x0000000000439bb5 in fe_op_search (op=3D0x803521000, rs=3D0x7ffffd= bfab30) at > > search.c:366 > > #11 0x0000000000439520 in do_search (op=3D0x803521000, rs=3D0x7ffffdbfa= b30) at > > search.c:217 > > #12 0x000000000043613d in connection_operation (ctx=3D0x7ffffdbfac70, > > arg_v=3D0x803521000) at connection > > .c:1123 > > #13 0x00000000004366d9 in connection_read_thread (ctx=3D0x7ffffdbfac70,= argv=3D0x12) > > at connection.c:125 > > 9 > > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > > /usr/local/lib/libldap_r-2.4.so. > > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > > #16 0x0000000000000000 in ?? () > > Error accessing memory address 0x7ffffdbfb000: Bad address. >=20 >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ --=20 Email: alexs(a)ulgsm.ru Email/Jabber: alexs(a)ulgsm.ru --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iQEcBAEBAgAGBQJLAP/dAAoJELAIdrQw5JcdEXgIAJ4KkW6gYy+Nm6XykkqGAyad HG/vIY1KeG9vJyPLzduonCaqhi32ZIuSl3qkGgywy4q/wJV0kW3rRZ2tzQLzMahr gKlVFJvyqtPhocKARppKWFSIXxJT64lvCqEabrfw2JLDhDNJGtIOcdn51TlKvfIy 4paEDvv5c+A3aDD7BFKK0QePq8E38v5evK1a8UG94rbGiKiCjtgYjJVfm03NUjmR FvyBwMV+CgcXGj4fQ+bnvfTTC8jb00oftw/7NS2orZi6EHcGaxvbeuPmrEVIRtL4 Fi82XlKfcEqFq/znja041mrkF7tnPLfysMzXEjqeOgrsedAIWS52M2LHGUYkY0k= =PI7h -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL--

1 0

ITS#6290 dynamic group documentation
by hyc＠symas.com 15 Nov '09

15 Nov '09

Yeah, the example should have used groupOfURLs instead of groupOfNames. Notice that "member" is not a valid attribute in the groupOfURLs class: it can not be used to store static members, only dynamic references. -- -- 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by hyc＠symas.com 15 Nov '09

15 Nov '09

mike(a)flyn.org wrote: > Followup 4 states that slapd did not initially crash when using "threads > 1" and no indexes. In this case, slapd did eventually crash as before. I have removed the two asserts you previously reported; please try the current code in CVS HEAD. -- -- 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 15 Nov '09

15 Nov '09

Followup 4 states that slapd did not initially crash when using "threads 1" and no indexes. In this case, slapd did eventually crash as before.

1 0

Re: (ITS#6304) Slapd freezes during SSL handshake when TLSVerifyClient=allow
by hyc＠symas.com 15 Nov '09

15 Nov '09

Jan Zelený wrote: > Dne čtvrtek 24 září 2009 22:19:40 Howard Chu napsal(a): >> jzeleny(a)redhat.com wrote: >>> Full_Name: Jan Zeleny >>> Version: 2.4.18 >>> OS: Fedora 11 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (62.40.79.66) >>> >> I'm unable to reproduce this using slapd on a debian x86-64 system, whether >> on the local LAN or from 13 hops away. I've also used the tcp-buffer >> option to set a minimum sized socket buffer and still could not duplicate >> the problem. You will need to provide more explicit information on how to >> reproduce this issue. Perhaps providing a set of CA/server certs will also >> be necessary. > I'm not sure I have much more explicit information for you. I'm sending > certificate in attachment. It's a self signed testing certificate I generated on > my system. I'm also sending you slapd.conf with relevant information and CA > bundle file. If you need anything else, just let me know. > > Just for complete information: > I tried slapd on Fedora 12 and RHEL 5.3 (x86_64) and on Ubuntu 9.04 (i386). On > each system I used different self signed certificate. In both cases attached > slapd.conf file was used. To reproduce error, I just started the slapd service > (slapd -h 'ldaps:///' -u ldap) with given config file and connected to it. When > I tried to connect with openssl s_client -connect fedora12-64, I received this > output (and then freeze): > > CONNECTED(00000003) > depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech > s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny(a)redhat.com > verify error:num=18:self signed certificate > verify return:1 > depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech > s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny(a)redhat.com > verify return:1 > > >> Please note that the bug report you reference (509230) gives inconsistent >> information; it says that no hang occurs with -d2, but that hangs occur >> with no diagnostics, even with -d -1. Obviously -d -1 includes -d 2, so: >> does it hang, or not, with -d -1? > > I believe what is stated there is that hangs don't occur with -d2, but they do > with -d1 (not -d -1). I can also confirm this behaviour, that with -d1 hangs > occur, but with -d2 they don't. (or at least I didn't encounter them during my > testing). > > Hopefully I provided some useful information. Thanks, that helped, a fix is now in CVS HEAD. I should point out that the configuration used to reproduce this problem is quite a poor one. As the OpenLDAP Admin Guide clearly states, your server should only be configured with the CA certs for which it will accept client certs. Your ca-bundle.crt file is 670KB and loaded with a lot of CAs that are irrelevant; it's when slapd sends the client its list of acceptable CAs that the connection was getting jammed. -- -- 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#6325) test054: test failed - producer and consumer databases differ
by michael＠stroeder.com 15 Nov '09

15 Nov '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Download testrun/ here: >>> >>> http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz >> It's certainly a mystery. The *.flt shows that an entry is missing on the >> slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log >> shows that the consumer received the entry and ignored it. (See slapd.4.log >> line 3307-3313. Compare with the previously received entry, lines 3161-3169.) >> >> The most puzzling part is that every code path in the consumer that rejects an >> entry logs an error message, and there is no error message in the log file. >> Without any means to reproduce this there's not much we can do. Setting a >> higher debug level might be useful, but any error messages in this path should >> have shown up regardless. > > The same problem is in your ITS#6126 logs. The entry was received on the > consumer but skipped without any error message. > > I see now, the entry was skipped because its CSN was too old. (And that CSN > too old message is only logged with SYNC debug is enabled.) This should be > fixed by the patch for ITS#6346. > > It was also suggested that we should only reject mods if their CSN is actually > older than the target entry's CSN. That's still a possibility if the current > patch is insufficient. These ITS were filed based on failed test runs on my old Pentium III Mobile 1,8 GHz laptop (now broken). I always suspected that it might be something others won't see because their hardware is faster. Maybe it would be good to run the test suite on really slow systems from time to time. Ciao, Michael.

1 0

Re: (ITS#6325) test054: test failed - producer and consumer databases differ
by hyc＠symas.com 15 Nov '09

15 Nov '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Download testrun/ here: >> >> http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz > > It's certainly a mystery. The *.flt shows that an entry is missing on the > slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log > shows that the consumer received the entry and ignored it. (See slapd.4.log > line 3307-3313. Compare with the previously received entry, lines 3161-3169.) > > The most puzzling part is that every code path in the consumer that rejects an > entry logs an error message, and there is no error message in the log file. > Without any means to reproduce this there's not much we can do. Setting a > higher debug level might be useful, but any error messages in this path should > have shown up regardless. The same problem is in your ITS#6126 logs. The entry was received on the consumer but skipped without any error message. I see now, the entry was skipped because its CSN was too old. (And that CSN too old message is only logged with SYNC debug is enabled.) This should be fixed by the patch for ITS#6346. It was also suggested that we should only reject mods if their CSN is actually older than the target entry's CSN. That's still a possibility if the current patch is insufficient. -- -- 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#6200) slapd crashes under load w/ syncrepl
by hyc＠symas.com 15 Nov '09

15 Nov '09

joacim.breiler(a)hgo.se wrote: > Thanks for your fast replies! The 'make install STRIP=""' did the trick. > > I ran the server for about a week with no segfaults, then I decided that > I couldn't wait for it any longer. So I connected to the server using an > LDAP browser, and then after about ten minutes it segfaulted. So to > reproduce I need one connection that is reading/updating/creating > entries. And one connection that does an occasional read, otherwise the > server will keep on running. > > The traceback from gdb gives: This trace looks like the problem fixed in ITS#6335. The fix is in CVS HEAD and RE24 (2.4.20 pre-release). > > 0x00007f96c3fc00ad in syncprov_op_mod (op=0x7f9688000ac0, rs=0x44688c80) > at syncprov.c:1970 > 1970 for ( m2 = mt->mt_mods; m2->mi_next != mi; > (gdb) where > #0 0x00007f96c3fc00ad in syncprov_op_mod (op=0x7f9688000ac0, > rs=0x44688c80) at syncprov.c:1970 > #1 0x00000000004c438a in overlay_op_walk (op=0x7f9688000ac0, > rs=0x44688c80, which=op_modify, oi=0x12293c0, on=0x12295a0) at > backover.c:659 > #2 0x00000000004c4667 in over_op_func (op=0x7f9688000ac0, > rs=0x44688c80, which=op_modify) at backover.c:721 > #3 0x00000000004c47ac in over_op_modify (op=0x7f9688000ac0, > rs=0x44688c80) at backover.c:760 > #4 0x000000000045bb21 in fe_op_modify (op=0x7f9688000ac0, > rs=0x44688c80) at modify.c:301 > #5 0x000000000045b430 in do_modify (op=0x7f9688000ac0, rs=0x44688c80) > at modify.c:175 > #6 0x000000000043c3ec in connection_operation (ctx=0x44688de0, > arg_v=0x7f9688000ac0) at connection.c:1123 > #7 0x000000000043c975 in connection_read_thread (ctx=0x44688de0, > argv=0x17) at connection.c:1259 > #8 0x0000000000525193 in ldap_int_thread_pool_wrapper (xpool=0x1190290) > at tpool.c:685 > #9 0x00007f96c49613ea in start_thread () from /lib/libpthread.so.0 > #10 0x00007f96c44b9cbd in clone () from /lib/libc.so.6 > #11 0x0000000000000000 in ?? () > > /J -- -- 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#6325) test054: test failed - producer and consumer databases differ
by hyc＠symas.com 15 Nov '09

15 Nov '09

michael(a)stroeder.com wrote: > Download testrun/ here: > > http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz It's certainly a mystery. The *.flt shows that an entry is missing on the slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log shows that the consumer received the entry and ignored it. (See slapd.4.log line 3307-3313. Compare with the previously received entry, lines 3161-3169.) The most puzzling part is that every code path in the consumer that rejects an entry logs an error message, and there is no error message in the log file. Without any means to reproduce this there's not much we can do. Setting a higher debug level might be useful, but any error messages in this path should have shown up regardless. -- -- 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: RE : (ITS#6367) syncprov ... changed by peer, ignored
by hyc＠symas.com 15 Nov '09

15 Nov '09

CHIROSSEL Olivier wrote: > sorry for this > > the url is ok now Thanks. This is now fixed in HEAD. > > Cdt, > > Olivier > ________________________________________ > De : Howard Chu [hyc(a)symas.com] > Date d'envoi : vendredi 13 novembre 2009 23:33 > À : CHIROSSEL Olivier > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#6367) syncprov ... changed by peer, ignored > > olivier.chirossel(a)sfr.com wrote: >> Full_Name: olivier chirossel >> Version: 2.4.17 and 2.4.19 >> OS: linux >> URL: http://86.64.145.174:8080/ >> Submission from: (NULL) (62.39.9.251) >> >> >> in refreshend persist mode, the replication is incorrect for an entry which be >> delete/add after master restart and before the reconnection of the slave. > >> 2) master set up >> >> on /etc/openldap tar xvf slapd_master.tar (get on the url ) > > The URL you provided always times out for me, so I've been unable to set up > this test. > -- -- 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#6362) slapd 2.4.19 Segmentation fault under load
by hyc＠symas.com 15 Nov '09

15 Nov '09

alexs(a)ulgsm.ru wrote: > Full_Name: Aleksey > Version: 2.4.19 > OS: Freebsd7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.93.136.26) > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 > Slapd built with the "-g" flag and install with the make install STRIP="" > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > In slapd config added using hdb as backend and indexes. > > Testing database consist of 1000 users accounts with minimum attributes. > > On stress test load slapd Segmentation fault in 10-30 sec. Looks like you've had a stack overrun. The "be" parameter should be the same in your frame 0 and frame 1. > #gdb /usr/local/libexec/slapd > (gdb) run -d 0 > Starting program: /usr/local/libexec/slapd -d 0 > [New LWP 100311] > [New Thread 0x801a020b0 (LWP 100311)] > [New Thread 0x801a02880 (LWP 100073)] > [New Thread 0x8034040b0 (LWP 100076)] > [New Thread 0x803404240 (LWP 100077)] > [New Thread 0x8034043d0 (LWP 100078)] > [New Thread 0x803404560 (LWP 100116)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 > 511 { > (gdb) > (gdb) > (gdb) where > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address 0x7ffffd9f9f38: dress. > ) at idl.c:511 > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > txn=0x80352b040, k=0x8069005 > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > ava=0x7ffffda7a4f0, > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a550, > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > filterindex.c:581 > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a530, > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > filterindex.c:581 > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a570, > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > e=0x7ffffda7a71 tx > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:586 > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:366 > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:217 > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > arg_v=0x803521000) at connection > .c:1123 > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > at connection.c:125 > 9 > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > /usr/local/lib/libldap_r-2.4.so. > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > #16 0x0000000000000000 in ?? () > Error accessing memory address 0x7ffffdbfb000: Bad address. -- -- 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#6381) connection_fake_init() from db_open() is unsafe
by hyc＠OpenLDAP.org 15 Nov '09

15 Nov '09

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Originally the db_open() handlers only ran from slapd's main context, at startup time before threading was active. But with back-config, backends and overlays can be added at runtime and the db_open() handler then runs in a back-config operation thread. If a db_open handler calls connection_fake_init() using its current thread context, it will get the current sl_malloc memory context as well, and reset it to zero. Any sl_mallocs called up to that point will be forgotten and they'll be overwritten by subsequent calls in that thread. We never saw any problems with this prior to ITS#6380, because the prior mallocs tended to be higher up in the sl_malloc heap. So even though the heap was reset, the new mallocs didn't collide with the old ones. This is already fixed in HEAD: back-sql/init.c, back-monitor/init.c, and overlays/{dds.c, pcache.c, syncprov.c}

1 0

(ITS#6380) slap_sl_free is too lazy
by hyc＠OpenLDAP.org 15 Nov '09

15 Nov '09

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc slap_sl_free() would only reclaim memory if you were freeing the last allocated block. If you wanted to free a chain of alloc'd memory you would have to free them in the exact reverse order of allocation. Calling slap_sl_free() out of order would be a no-op. This was OK most of the time because a single operation would seldom live long enough to use much memory. But for long-lived tasks (like syncrepl or syncprov) it would often run out and allocs would fallback to ch_malloc. sl_malloc.c in HEAD has been changed to mark freed blocks no matter what order they're freed in. It still only reclaims from the last block forward, but it's more effective now.

1 0

Re: (ITS#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by hyc＠symas.com 14 Nov '09

14 Nov '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> hyc(a)symas.com wrote: >>> I'm seeing the same problem here. Still haven't identified the cause, looking... >>> >> Fixed. > > HEAD now has a different issue. Is this related to this fix? Now fixed. >>>>>> Starting test003-search for bdb... -- -- 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#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by hyc＠symas.com 14 Nov '09

14 Nov '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> hyc(a)symas.com wrote: >>> I'm seeing the same problem here. Still haven't identified the cause, looking... >>> >> Fixed. > > HEAD now has a different issue. Is this related to this fix? Since test003 doesn't involve sync replication in any way, no. This ITS is fixed, closing. File a separate ITS for different issues... -- -- 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#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by michael＠stroeder.com 14 Nov '09

14 Nov '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I'm seeing the same problem here. Still haven't identified the cause, looking... >> > Fixed. HEAD now has a different issue. Is this related to this fix? Ciao, Michael. >>>>> Starting test003-search for bdb... running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... Testing slapd searching... Testing exact searching... Testing approximate searching... Testing OR searching... *** glibc detected *** /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.libs/lt-slapd: free(): invalid pointer: 0x000000000 097fb28 *** ======= Backtrace: ========= /lib64/libc.so.6[0x2b2f801d5c76] /lib64/libc.so.6(cfree+0x6c)[0x2b2f801da96c] /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber-2-devel.so.0(ber_bvarray_free_x+0x63)[0x2b2f7e30f273] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0(bdb_filter_candidates+0x1752)[0x2b2f82889842] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0[0x2b2f82889f07] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0(bdb_filter_candidates+0x5aa)[0x2b2f8288869a] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0[0x2b2f82889f07] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0(bdb_filter_candidates+0x5aa)[0x2b2f8288869a] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0[0x2b2f82889f07] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0(bdb_filter_candidates+0x79a)[0x2b2f8288888a] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0(bdb_search+0xe96)[0x2b2f82882cf6] /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.libs/lt-slapd(fe_op_search+0x259)[0x436c29] /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.libs/lt-slapd(do_search+0x6ac)[0x43743c] /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.libs/lt-slapd[0x434a01] /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.libs/lt-slapd[0x435285] /usr/src/michael/openldap/HEAD/openldap/libraries/libldap_r/.libs/libldap_r-2-devel.so.0[0x2b2f7e0cb1b8] /lib64/libpthread.so.0[0x2b2f7ecdc65d] /lib64/libc.so.6(clone+0x6d)[0x2b2f8023414d] ======= Memory map: ======== 00400000-00529000 r-xp 00000000 08:05 524931 /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.l ibs/lt-slapd 00728000-00729000 r--p 00128000 08:05 524931 /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.l ibs/lt-slapd 00729000-00730000 rw-p 00129000 08:05 524931 /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.l ibs/lt-slapd 00730000-00aa2000 rw-p 00000000 00:00 0 [heap] 2b2f7de9a000-2b2f7deb8000 r-xp 00000000 08:05 145546 /lib64/ld-2.10.1.so 2b2f7deb8000-2b2f7deba000 rw-p 00000000 00:00 0 2b2f7e0b7000-2b2f7e0b8000 r--p 0001d000 08:05 145546 /lib64/ld-2.10.1.so 2b2f7e0b8000-2b2f7e0b9000 rw-p 0001e000 08:05 145546 /lib64/ld-2.10.1.so 2b2f7e0b9000-2b2f7e102000 r-xp 00000000 08:05 524531 /usr/src/michael/openldap/HEAD/openldap/libraries/liblda p_r/.libs/libldap_r-2-devel.so.0.0.0 2b2f7e102000-2b2f7e301000 ---p 00049000 08:05 524531 /usr/src/michael/openldap/HEAD/openldap/libraries/liblda p_r/.libs/libldap_r-2-devel.so.0.0.0 2b2f7e301000-2b2f7e302000 r--p 00048000 08:05 524531 /usr/src/michael/openldap/HEAD/openldap/libraries/liblda p_r/.libs/libldap_r-2-devel.so.0.0.0 2b2f7e302000-2b2f7e304000 rw-p 00049000 08:05 524531 /usr/src/michael/openldap/HEAD/openldap/libraries/liblda p_r/.libs/libldap_r-2-devel.so.0.0.0 2b2f7e304000-2b2f7e307000 rw-p 00000000 00:00 0 2b2f7e307000-2b2f7e314000 r-xp 00000000 08:05 524374 /usr/src/michael/openldap/HEAD/openldap/libraries/liblbe r/.libs/liblber-2-devel.so.0.0.0 2b2f7e314000-2b2f7e513000 ---p 0000d000 08:05 524374 /usr/src/michael/openldap/HEAD/openldap/libraries/liblbe r/.libs/liblber-2-devel.so.0.0.0 2b2f7e513000-2b2f7e514000 r--p 0000c000 08:05 524374 /usr/src/michael/openldap/HEAD/openldap/libraries/liblbe r/.libs/liblber-2-devel.so.0.0.0 2b2f7e514000-2b2f7e515000 rw-p 0000d000 08:05 524374 /usr/src/michael/openldap/HEAD/openldap/libraries/liblbe r/.libs/liblber-2-devel.so.0.0.0 2b2f7e531000-2b2f7e532000 rw-p 00000000 00:00 0 2b2f7e532000-2b2f7e535000 r-xp 00000000 08:05 166857 /lib64/libuuid.so.1.3.0 2b2f7e535000-2b2f7e735000 ---p 00003000 08:05 166857 /lib64/libuuid.so.1.3.0 2b2f7e735000-2b2f7e736000 r--p 00003000 08:05 166857 /lib64/libuuid.so.1.3.0 2b2f7e736000-2b2f7e737000 rw-p 00004000 08:05 166857 /lib64/libuuid.so.1.3.0 2b2f7e737000-2b2f7e866000 r-xp 00000000 08:05 198841 /usr/lib64/libdb-4.5.so 2b2f7e866000-2b2f7ea65000 ---p 0012f000 08:05 198841 /usr/lib64/libdb-4.5.so 2b2f7ea65000-2b2f7ea68000 r--p 0012e000 08:05 198841 /usr/lib64/libdb-4.5.so 2b2f7ea68000-2b2f7ea6b000 rw-p 00131000 08:05 198841 /usr/lib64/libdb-4.5.so 2b2f7ea6b000-2b2f7eacd000 r-xp 00000000 08:05 235428 /usr/lib64/libodbc.so.1.0.0 2b2f7eacd000-2b2f7eccc000 ---p 00062000 08:05 235428 /usr/lib64/libodbc.so.1.0.0 2b2f7eccc000-2b2f7eccd000 r--p 00061000 08:05 235428 /usr/lib64/libodbc.so.1.0.0 2b2f7eccd000-2b2f7ecd4000 rw-p 00062000 08:05 235428 /usr/lib64/libodbc.so.1.0.0 2b2f7ecd4000-2b2f7ecd6000 rw-p 00000000 00:00 0 2b2f7ecd6000-2b2f7ecec000 r-xp 00000000 08:05 156951 /lib64/libpthread-2.10.1.so 2b2f7ecec000-2b2f7eeec000 ---p 00016000 08:05 156951 /lib64/libpthread-2.10.1.so 2b2f7eeec000-2b2f7eeed000 r--p 00016000 08:05 156951 /lib64/libpthread-2.10.1.so 2b2f7eeed000-2b2f7eeee000 rw-p 00017000 08:05 156951 /lib64/libpthread-2.10.1.so 2b2f7eeee000-2b2f7eef2000 rw-p 00000000 00:00 0 2b2f7eef2000-2b2f7ef0a000 r-xp 00000000 08:05 173123 /usr/lib64/libslp.so.1.0.0 2b2f7ef0a000-2b2f7f109000 ---p 00018000 08:05 173123 /usr/lib64/libslp.so.1.0.0 2b2f7f109000-2b2f7f10a000 r--p 00017000 08:05 173123 /usr/lib64/libslp.so.1.0.0 2b2f7f10a000-2b2f7f10b000 rw-p 00018000 08:05 173123 /usr/lib64/libslp.so.1.0.0 2b2f7f10b000-2b2f7f124000 r-xp 00000000 08:05 185973 /usr/lib64/libsasl2.so.2.0.23 2b2f7f124000-2b2f7f323000 ---p 00019000 08:05 185973 /usr/lib64/libsasl2.so.2.0.23 2b2f7f323000-2b2f7f324000 r--p 00018000 08:05 185973 /usr/lib64/libsasl2.so.2.0.23 2b2f7f324000-2b2f7f325000 rw-p 00019000 08:05 185973 /usr/lib64/libsasl2.so.2.0.23./scripts/test003-search: l ine 93: 9220 Aborted (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 ldapsearch failed (255)! ./scripts/test003-search: line 96: kill: (9220) - No such process >>>>> ./scripts/test003-search failed for bdb (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests'

1 0

RE : (ITS#6367) syncprov ... changed by peer, ignored
by olivier.chirossel＠sfr.com 14 Nov '09

14 Nov '09

sorry for this the url is ok now Cdt, Olivier ________________________________________ De : Howard Chu [hyc(a)symas.com] Date d'envoi : vendredi 13 novembre 2009 23:33 =C0 : CHIROSSEL Olivier Cc : openldap-its(a)openldap.org Objet : Re: (ITS#6367) syncprov ... changed by peer, ignored olivier.chirossel(a)sfr.com wrote: > Full_Name: olivier chirossel > Version: 2.4.17 and 2.4.19 > OS: linux > URL: http://86.64.145.174:8080/ > Submission from: (NULL) (62.39.9.251) > > > in refreshend persist mode, the replication is incorrect for an entry whi= ch be > delete/add after master restart and before the reconnection of the slave. > 2) master set up > > on /etc/openldap tar xvf slapd_master.tar (get on the url ) The URL you provided always times out for me, so I've been unable to set up this test. -- -- 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#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by hyc＠symas.com 14 Nov '09

14 Nov '09

hyc(a)symas.com wrote: > I'm seeing the same problem here. Still haven't identified the cause, looking... > Fixed. -- -- 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#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by hyc＠symas.com 14 Nov '09

14 Nov '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD synced now > OS: openSUSE Linux 11.2 (x86_64) > URL: > Submission from: (NULL) (84.163.61.118) > > > Stopping central master and site2 servers to test start with emtpy db... > Starting site2 master slapd on TCP/IP port 9013... > Using ldapsearch to check that site2 master slapd is running... > Starting site2 search slapd on TCP/IP port 9016... > Using ldapsearch to check that site2 search slapd is running... > Starting central master slapd on TCP/IP port 9011... > Using ldapsearch to check that central master slapd is running... > Using ldapsearch to check that site2 master received base... > Using ldapsearch to check that site2 search received base... > Waiting 1 seconds for syncrepl to receive changes... > Checking contextCSN after site2 servers repopulated... > Found 3 errors >>>>>> ./scripts/test058-syncrepl-asymmetric failed for bdb (exit 3) > make[2]: *** [bdb-mod] Error 3 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > I'm seeing the same problem here. Still haven't identified the cause, looking... -- -- 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#6378) Slapadd core dump
by michael＠stroeder.com 14 Nov '09

14 Nov '09

acirulli(a)gmail.com wrote: > Full_Name: Andrea Cirulli > Version: 2.4.16 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.77.56.182) > > > Problem with slapadd 2.4.16 using an ldif provided by slapcat 2.3.39 > > SLAPADD goes always in core dump on entry of ldif such the following: > > registeredAddress:: MTEzLjIxMS4yMjUuMTgxIAA= > > The base 64 value once converted is "113.211.225.181" + " " + '\0' Not sure whether slapcat 2.3.39 falsely added the NULL-byte at the end or whether it's part of your data. Could you please cross-check that with ldapsearch reading that particular entry? Nevertheless slapadd should not crash. Rather an error should be reported. But please try to reproduce the issue with a recent release (at least 2.4.19, preferrably CVS branch OPENLDAP_REL_ENG_2_4). Another option would be to provide sanitized test data to let others try to reproduce it. Ciao, Michael.

1 0

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 14 Nov '09

14 Nov '09

> Please provide stack traces for each of these assertions. In this case it > sounds like connection_closing() got called multiple times for the same > connection, after it had already been fully closed. A trace would help > confirm > that. This is a little odd: (gdb) run -d 255 Starting program: /usr/sbin/slapd -d 255 must compile with LDAP_DEBUG for debugging *** "CRASH" *** Program exited normally. (gdb) ba No stack. I have been running a script, while ldapsearch -x; do sleep 10; done, that eventually crashes slapd. But gdb provides little feedback, as noted above. >> One things to note is that, in addition to being on MIPS32, my platform >> has only 32MB of memory. I also have a swap file that is 64MB. > > In such an environment you won't have enough memory for more than 1 or 2 > server threads. Have you already configured this? I have just reconfigured slapd to use one thread and removed all indexes from the configuration. So far, I have not seen a crash. I am no using two clients to query slapd and have removed that sleep statements so that the server is continuously queried. I've been running this for about one hour and will report back if there are any negative results.

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by masarati＠aero.polimi.it 14 Nov '09

14 Nov '09

> Howard Chu wrote: >> Peter Mogensen wrote: >>> This is mirrormode. >>> There's no "provider" as such. However, there's one server which is >>> used >>> for application access and to minimize disk load on that server, the >>> plan was to take most backups from the other. >>> I can't see any difference between what you call "initializing" and >>> normal running state, except that the difference between server-1 and >>> server-2 is (somewhat) larger. >> >> If the problem is as Ando suggests, then it's because in the syncrepl >> Refresh >> phase it's receiving entries out-of-order from the provider. Ando is >> suggesting that the problem is caused when a child entry is replicated >> before >> its parent. Once the Refresh phase ends and it transitions to the >> Persist >> phase, all entries' parents will exist and so this particular condition >> will >> no longer occur. >> >> Of course, no one is saying for certain that this is the explanation, >> yet. > > It sounds reasonable to me :) > But unless you are not in any way allowed to - ever - make writes to > more than one server in a mirromode setup, this could (as I hear it) > potentially happen at any time. > The only reason I have to only make writes to one server is that I > currently (this will change) have an application which is dependant on > making writes and immediately reading back the entry. > > As I hear what you're saying is that any write to a server in a > mirrormode setup could invalidate a slapcat running on the other. > This would mean that you can never write to more that one server at all > and that's the only server you can slapcat while running. > That takes a lot of the "mirror" out of "mirrormode". Doesn't it? Based on my *very incomplete and possibly wrong* analysis, the problem would be automatically cured by using back-bdb. Also, fixing back-hdb *if it's broken at all* should be possible. p.

1 0

(ITS#6378) Slapadd core dump
by acirulli＠gmail.com 14 Nov '09

14 Nov '09

Full_Name: Andrea Cirulli Version: 2.4.16 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.77.56.182) Problem with slapadd 2.4.16 using an ldif provided by slapcat 2.3.39 SLAPADD goes always in core dump on entry of ldif such the following: registeredAddress:: MTEzLjIxMS4yMjUuMTgxIAA= The base 64 value once converted is "113.211.225.181" + " " + '\0' The output of the slapadd in verbose mode is: Assertion failed: p == &normalized->bv_val[normalized->bv_len], file schema_init.c, line 2225 Abort (core dumped) 

1 0

Re: (ITS#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by michael＠stroeder.com 14 Nov '09

14 Nov '09

See testrun/ http://www.stroeder.com/temp/openldap/openldap-its-6377-testrun.tar.gz

1 0

(ITS#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by michael＠stroeder.com 14 Nov '09

14 Nov '09

Full_Name: Michael Ströder Version: HEAD synced now OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.61.118) Stopping central master and site2 servers to test start with emtpy db... Starting site2 master slapd on TCP/IP port 9013... Using ldapsearch to check that site2 master slapd is running... Starting site2 search slapd on TCP/IP port 9016... Using ldapsearch to check that site2 search slapd is running... Starting central master slapd on TCP/IP port 9011... Using ldapsearch to check that central master slapd is running... Using ldapsearch to check that site2 master received base... Using ldapsearch to check that site2 search received base... Waiting 1 seconds for syncrepl to receive changes... Checking contextCSN after site2 servers repopulated... Found 3 errors >>>>> ./scripts/test058-syncrepl-asymmetric failed for bdb (exit 3) make[2]: *** [bdb-mod] Error 3 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 14 Nov '09

14 Nov '09

Howard Chu wrote: > Peter Mogensen wrote: >> This is mirrormode. >> There's no "provider" as such. However, there's one server which is used >> for application access and to minimize disk load on that server, the >> plan was to take most backups from the other. >> I can't see any difference between what you call "initializing" and >> normal running state, except that the difference between server-1 and >> server-2 is (somewhat) larger. > > If the problem is as Ando suggests, then it's because in the syncrepl Refresh > phase it's receiving entries out-of-order from the provider. Ando is > suggesting that the problem is caused when a child entry is replicated before > its parent. Once the Refresh phase ends and it transitions to the Persist > phase, all entries' parents will exist and so this particular condition will > no longer occur. > > Of course, no one is saying for certain that this is the explanation, yet. It sounds reasonable to me :) But unless you are not in any way allowed to - ever - make writes to more than one server in a mirromode setup, this could (as I hear it) potentially happen at any time. The only reason I have to only make writes to one server is that I currently (this will change) have an application which is dependant on making writes and immediately reading back the entry. As I hear what you're saying is that any write to a server in a mirrormode setup could invalidate a slapcat running on the other. This would mean that you can never write to more that one server at all and that's the only server you can slapcat while running. That takes a lot of the "mirror" out of "mirrormode". Doesn't it? >> If I can't trust slapcat during this >> phase, how can I trust slapcat for backups? > > Does slapcat behave this way on the active server? I've taking that test setup down now to test other stuff, so I can't say 100%. /Peter

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by hyc＠symas.com 14 Nov '09

14 Nov '09

Peter Mogensen wrote: > Howard Chu wrote: >> apm(a)mutex.dk wrote: >>> Pierangelo Masarati wrote: >>>> You appear to be using back-hdb. >>> Yes. >>> >>>> My guess is that if this can fail, e.g. because entries are being >>>> sync'ed out of order, the DN does not get fixed. If this is the case (I >>>> couldn't inspect code deep enough to make sure), I'd expect that the DN >>>> get fixed anyway, though, because missing entries should exist as "glue" >>>> objects. >>> yes. But if you plan to use slapcat as a backup mechanism, then it's >>> still a problem. >> >> Sounds like a low priority issue at best. Taking backups of a replica while it >> is initializing is pointless, just take a backup of the provider instead. > > This is mirrormode. > There's no "provider" as such. However, there's one server which is used > for application access and to minimize disk load on that server, the > plan was to take most backups from the other. > I can't see any difference between what you call "initializing" and > normal running state, except that the difference between server-1 and > server-2 is (somewhat) larger. If the problem is as Ando suggests, then it's because in the syncrepl Refresh phase it's receiving entries out-of-order from the provider. Ando is suggesting that the problem is caused when a child entry is replicated before its parent. Once the Refresh phase ends and it transitions to the Persist phase, all entries' parents will exist and so this particular condition will no longer occur. Of course, no one is saying for certain that this is the explanation, yet. > If I can't trust slapcat during this > phase, how can I trust slapcat for backups? Does slapcat behave this way on the active server? -- -- 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#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 13 Nov '09

13 Nov '09

Howard Chu wrote: > apm(a)mutex.dk wrote: >> Pierangelo Masarati wrote: >>> You appear to be using back-hdb. >> Yes. >> >>> My guess is that if this can fail, e.g. because entries are being >>> sync'ed out of order, the DN does not get fixed. If this is the case (I >>> couldn't inspect code deep enough to make sure), I'd expect that the DN >>> get fixed anyway, though, because missing entries should exist as "glue" >>> objects. >> yes. But if you plan to use slapcat as a backup mechanism, then it's >> still a problem. > > Sounds like a low priority issue at best. Taking backups of a replica while it > is initializing is pointless, just take a backup of the provider instead. This is mirrormode. There's no "provider" as such. However, there's one server which is used for application access and to minimize disk load on that server, the plan was to take most backups from the other. I can't see any difference between what you call "initializing" and normal running state, except that the difference between server-1 and server-2 is (somewhat) larger. If I can't trust slapcat during this phase, how can I trust slapcat for backups? /Peter

1 0

(ITS#6376) memleak in 2.3
by mbackes＠symas.com 13 Nov '09

13 Nov '09

Full_Name: Matthew Backes Version: 2.3 only OS: any URL: Submission from: (NULL) (76.88.99.93) In 2.3, if you have a lot of fast writes such that syncprov_sendresp's op tmp memory is exhausted and it has resorted to malloc()s AND controls are asserted, the rs.sr_ctrls free at the end of the function leaks. To duplicate: Set up a master and a replica. Do mods like crazy with some control asserted, e.g. manageDSAIT. 2.4/head handle this differently so it isn't a problem there. Patch versus OPENLDAP_REL_ENG_2_3: RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/syncprov.c,v retrieving revision 1.56.2.51 diff -u -u -r1.56.2.51 syncprov.c --- syncprov.c 9 Jul 2008 20:53:13 -0000 1.56.2.51 +++ syncprov.c 14 Nov 2009 04:14:26 -0000 @@ -803,6 +803,7 @@ } /* In case someone else freed it already? */ if ( rs.sr_ctrls ) { + op->o_tmpfree( rs.sr_ctrls[0]->ldctl_value.bv_val, op->o_tmpmemctx ); op->o_tmpfree( rs.sr_ctrls[0], op->o_tmpmemctx ); rs.sr_ctrls = NULL; } -- Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: ITS#6375
by jose.oliveira＠mailondemand.com.pt 13 Nov '09

13 Nov '09

This is a multi-part message in MIME format. --------------020401060209020404040703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi,<br> <br> I am sorry for the mistake and inconvenience.<br> Thanks for pointing out right direction.<br> <br> Best regards,<br> <br> <b style=""><span style="font-size: 8pt; font-family: "Verdana","sans-serif";"><font style="color: black;" size="+1">José Vicente Fonseca de Oliveira<br> <img style="width: 125px; height: 108px;" alt="logo mailondemand" src="cid:part1.09010807.09040809@mailondemand.com.pt"><br> </font></span></b><span style="font-family: sans-serif; color: black;"></span><a href="mailto:jose.oliveira@mailondemand.com.pt" target="_blank"><span style="color: rgb(51, 51, 255);"><span style="font-family: sans-serif;">jose.oliveira(a)mailondemand.com.pt</span></span></a><br style="font-family: sans-serif; color: black;"> <a href="http://www.mailondemand.com.pt" target="_blank"><span style="color: rgb(51, 51, 255);"><span style="font-family: sans-serif;">http://www.mailondemand.com.pt</span></span></a><br style="font-family: sans-serif; color: black;"> <br style="font-family: sans-serif; color: black;"> <span style="font-family: sans-serif; color: black;">Av. Miguel Bombarda nº133, 7ºD</span><br style="font-family: sans-serif; color: black;"> <span style="font-family: sans-serif; color: black;">1050-164 Lisboa</span><br style="font-family: sans-serif; color: black;"> <br style="font-family: sans-serif; color: black;"> <span style="font-family: sans-serif; color: black;">Tel: + 351 925440544</span><br style="font-family: sans-serif; color: black;"> <span style="font-family: sans-serif; color: black;"></span><span style="font-family: sans-serif;"><span style="color: black;">Skype + jvf_oliveira</span></span><br> <br> Pierangelo Masarati wrote: <blockquote cite="mid:4AFD95FF.8070209@aero.polimi.it" type="cite">The ITS is to track software bugs.  Please direct software usage questions to <a class="moz-txt-link-rfc2396E" href="mailto:openldap-solftware@openldap.org"><openldap-solftware(a)openldap.org></a> and software interoperation questions to <a class="moz-txt-link-rfc2396E" href="mailto:openldap-technical@openldap.org"><openldap-technical(a)openldap.org></a>. <br> <br> This ITS will be closed. <br> <br> p. <br> <br> _________________________ <br> This email was transferred using an evaluation version <br> of AXIGEN Mail Server. <br> <br> <br> </blockquote> <br> <br> <div class="moz-signature">-- <br> <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"> <title>JO_Letitwork</title> <b style=""><span style="font-size: 8pt; font-family: "Verdana","sans-serif";"></span></b><span style="font-family: sans-serif;"><span style="color: black;"></span></span><b style=""><span style="font-size: 7pt; font-family: "Verdana","sans-serif"; color: rgb(51, 153, 102);"></span></b><b style=""><span style="font-size: 7pt; font-family: "Verdana","sans-serif"; color: rgb(51, 153, 102);" lang="EN-GB"><br> </span></b></div> </body> </html> <br><br>_________________________<br>This email was transferred using an evaluation version<br>of AXIGEN Mail Server.<br><br> --------------020401060209020404040703 Content-Type: image/jpeg; name="modlogo_small.jpg" Content-Transfer-Encoding: base64 Content-ID: <part1.09010807.09040809(a)mailondemand.com.pt> Content-Disposition: inline; filename="modlogo_small.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8S EhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEU Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAAR CABsAH0DASIAAhEBAxEB/8QAHAAAAAcBAQAAAAAAAAAAAAAAAAECAwQFBgcI/8QANxAAAQMD AwIDBgUDBAMAAAAAAQIDBAAFEQYSIRMxByJRFDJBYXGBI0KRobFSctEVM0PBFjRj/8QAFAEB AAAAAAAAAAAAAAAAAAAAAP/EABQRAQAAAAAAAAAAAAAAAAAAAAD/2gAMAwEAAhEDEQA/APZd ChQoBQos/Ki3UCqFNGQ1uKd6cjuM0sLSRkEGgVQot1FuGaBVCi3fKjBzQChQoUAoj3zR0KAg aOiPHNGDQCklXf5UqknuaCI/LUlvdHZLxzykKwRVLOmz1FSSh1tBOQNhyPuKsXsoeUUfA+Ye opaFhaeDgenpQZpTylKJWrzH1V/mnG3XRyhxz7Z/6rRqQ0oAKSk/Uc0yu3wlqyqOjJ+IGKCo TPlo49oV+v8AkVIRdpYI8yVj5p/xUpVojf8AG68j5b8j96Ycsqtx2voV/e3/AIoHU3p1PvsJ P0JH8in2r4yfeZWPoQarlWqWn3Etq/scI/Y005DmI9+M6oeuAqgvkXaGrupSfqmnm50VZwl5 B+9ZUjYcLBb/ALkKTS0HdwCFfRYV/NBrA6k9lJP3pQVmsXOnIhIUOOpgZyMYHrwavNJOqfsz T6lFRcJOSfnQXVFg0dCgFFjnvR0KCrleSQv9qZPHmT3/AJp25cSftUfefWgfbdCxkdx3HpTu 7jNRFA53oICv5pbLoWnnj1FBJCsjmnAeKjbh8KWFHsDQSEq+dGD8QTUZbqGk7nFgAdyTTXXe e/2ElCf61D+BQS33W205dIAPrUN1lMn3YzTaMZ3qTyfoKdYYSlW9eVr/AKlc0uY504j6z2Q2 on9KDkd5uBU44hBIAJH7mup6Oa6Om4CTnJaBP35riLznVd79zx9zXerS30bZGZ+KGkj9qCbQ oUKDO6p1tpbTExqHfbyxCkvR1yGmVJUpbjaFJSpSUpBKsFQyBzjJ7AkR7Z4g6Nud2YtVs1DC mS5DPWYQ0oqS6naFeVeNqiEqBKQcgHJFV9xs053xvtOpVRErtcXTkyGqQVIyh9yTGUlITndy htzkDHGCeQDz7SujtQWvSvhbAftiI79hny3rkhLzR6CXGJSQrKVYXlbqPdyfNk9jgNdfvEDq 3Z6NYNPzryiM6Y70lEhiOx1U+82hTq09RQwc7QQCCM8Go7niBDVpOTeo0Uofiy4sWRDnPBhT Snnm20kqAUCCHApJTlK+ACM5HFLlCjt3kQLzD07NkQrPKtJh3uYmN7I8t9biZ7O9KgsOJKcq RhQKQMjBxorBpK+XbwYjIhm2zphj2GCy3AmJcbW1b5TJddLitqSSEOqwOMJABUTQdh0lqQX6 4akiGH7ObJeF2zd1N3W2sMu9TGBt/wB7G3n3c55wE3DXGkrfqAWOZfobNyK0NlpW7CFr9xCl 42oUrIwlRBORiq3w/tNxtV31rInx+i3c9RuToZ3pV1GTFjNhXBO3zNrGDg8dsEVi77pfVy7f q3SMTTzUuLqK6Klt3tU1pLcZDnT3dRsnqlxvYdm1KgcJ5FB0O7+IuibPdJNqumo4cSbFcbak tOBX4ClpSpG8gYQCFpwokDnGc1orjLTFhuynHW2GWUlx111QSlCAMlRJ4AA5zXLL5o69SbZ4 xstW1Lr2pYiWrSVOtgylJtaGBklXkw6FDz7fXtzWp1vp6fqLwln6YZcaanybWlhPWVlHUCU+ VRGfKSnaSM8E96CNpzxF07ftcw9P2SS1c0yLXIuLkvepBaDbjKEp6akjKVB0kLBx5eM5yNBp /W2k79dja7NfIsyYEqWltG4dRKThSmyQA4ASMlBIFc8cs+r9Ua7RdZ+lHNMw/wDxWdaVPLnx 33EvvOMFOA0o+QBCik9+DkJyAS8K9I3a33fTov1i1GhyxMltubIv7D8FKun0yWWknqYUM8KS nHzxQbWD4reHk1tLkTVlvdQtj2hsgL/FRlI8mU+dWVJBSnKgSBinNR6406jw9c1JDuCZ8KYh TEIxUla5Lp3J6aE99wKVZBxt2qzjBrC6F0Lf7ZZvBiNOs7bTmmESv9WT1mlezKXDdQkjCjvJ dUnlG7nk8DNU2qrFetM6Tud0ucZyNETqW9v72lJdMePNWroSsIJwBkZHdIcJIGDQZ+26s2XS Gi72WVbozshLXtC32XUoO5I/ECFko5IBJGBkZxXoG7eI2h7HOetd11DEizIgbElpSVEshaQU qWQCEpI/McD51420rpw3K+afs9vZ0tDcetki1SZEW4BxcjqJQDI2pRlSsJWoZ5yeSBivSj2m ru8fFFSLehZv8BqPblF1vMgpiKbKTk+UbzjzYHOe3NB0TUWttKaemxIV5vkSHIloLrSFEn8M EAuKwDsbyR51YT86Lwz1MdZ6AseqzB9g/wBVhok+zdXqdLcM7d2Bn64Fc8tdk1fp3US7lE0u 3qFF401b7W8lyay37A/HS6FJc3nzMK62SW96spPlORWx8D7Jc9N+EOlrDeo3stxgW1piSz1E r2LSORuSSk/UEig0cg5SaqZ5wDjvVxIAKTVZKa3ZyKDB6otMW6Ae3Q48nZ7nWaC9v0yOKz64 06CoKhSXmMDACVHH6dq6LNiBWeKqZlvBHYUGaias1BCwmQGpaB/WMH9RV3A1/BXhM6K9HV8S BuFQ5NrB7Jqsk2gEny0HQbdf7RPA9mnsLUfylWD+hq0QoiuMP2jBKgnB+XFORJd9t3/qT5CQ PyqVuH6Gg7MlfPejJwdzf3Fcyha6vDGBNiMygO5RlBP/AFWgt+u7NIUEyA9DX/8AROR+ooNg leeQeKzviY9s0m8M4K1oT+9WMS4QpWFw5TT2e4SofxWb8V5ATp9htIV+LIAGB6A0HO9MoiwL 63Ihw4zasnqltsJJ+pA5rsFonIkISoHFcx09bHdyVrB3HGeK3tmjrbSO9Bsoi8gYqe2Vbe9U 9vztHNW7OdnagQ63x2qI80DxirMjNNONjvQUz0cEcioL0UHvV+40DTDkfPwFBm3oXHaojsAH 4VqnIwNMKij0oMg9bQfy/tUR21A/l/atouIk00qCPSgw7tnTn3f2plVhSr/jz9q3nsA9KUiA PSgwcXTQDgUjc2fVPBrRMWcOMIalLXICFbkhw5wa0TMNKfhzUhEYA9qCni2uO37rYFWkaClP apTbAB7CpTLWKBMeOE9hUwBIGKShO0c0a/hmgXREZo6FAkoBpBbBp2kUDSmvjikKaHfFScmj wKCF0BntRFgH4VO2ihtFBA9nHpSkx0/Gpu0UNooIyY4+ApYZA+FOng4FDJ9aBAbA+FObR8BS aWKBOPnSXCvjakH6mnD2pIoP/9k= --------------020401060209020404040703--

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 13 Nov '09

13 Nov '09

pitpalme(a)gmail.com wrote: > masarati(a)aero.polimi.it wrote: > >> pitpalme(a)gmail.com wrote: >> >>> I do see attributes reflecting state after "modify" (which changes >>> "sn" attribute). >>> Where exactly should I expect to see a note about "glue state"? >>> Is output from "-d Any" helpful to figure what's going on (or wrong)? >> >> My understanding of your previous message was that you got a positive >> result from delete, but an "Already exists" from a subsequent add. > > That=92s korrekt. > >> I inferred that you checked about the existence of the object and =20 >> you got >> a negative result. > > In my current test scenario I do not check. > I assume a non-error on =84delete=93 in fact =84deletes=93, so I just = > check if =20 > response > code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91). > >> Apparently, my guess was wrong. In that case, you probably hit >> ITS#6097 <http://www.openldap.org/its?findid=3D6097>. > > *hmmm* Good idea, thanks. > But after reading ITS description I don=92t think it=92s what troubles = > me. > We don=92t actually neither have =84multi master mode=93, but =84mirror = > mode=93 =20 > and writes are done only on exactly one server, so there should not be =20= > > a problem with second server producing a concurrent write/modify. > I=92d expect the delete to be correctly propagated, but I can=92t check = > it =20 > is is, simply because I have to little knowledge to read debug log =20 > correctly. > =97 Paste the debug log somewhere we can see it then. Might as well use debug level -1 while executing this sequence. And provide the debug output from both servers. -- -- 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by hyc＠symas.com 13 Nov '09

13 Nov '09

mike(a)flyn.org wrote: > Yes, I have just been able to recreate this in 2.4.19. The line in > daemon.c at which the assertion occurs in this version is 994. > > I have also seen: > > ldap_write: want=22 error=Broken pipe > ... > slapd: connection.c:786: connection_closing: Assertion 'c->c_struct_state > == SLAP_C_USED' failed Please provide stack traces for each of these assertions. In this case it sounds like connection_closing() got called multiple times for the same connection, after it had already been fully closed. A trace would help confirm that. > One things to note is that, in addition to being on MIPS32, my platform > has only 32MB of memory. I also have a swap file that is 64MB. In such an environment you won't have enough memory for more than 1 or 2 server threads. Have you already configured this? -- -- 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#6367) syncprov ... changed by peer, ignored
by hyc＠symas.com 13 Nov '09

13 Nov '09

olivier.chirossel(a)sfr.com wrote: > Full_Name: olivier chirossel > Version: 2.4.17 and 2.4.19 > OS: linux > URL: http://86.64.145.174:8080/ > Submission from: (NULL) (62.39.9.251) > > > in refreshend persist mode, the replication is incorrect for an entry which be > delete/add after master restart and before the reconnection of the slave. > 2) master set up > > on /etc/openldap tar xvf slapd_master.tar (get on the url ) The URL you provided always times out for me, so I've been unable to set up this test. -- -- 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#6365) Bad slapcat output when slapd running
by hyc＠symas.com 13 Nov '09

13 Nov '09

apm(a)mutex.dk wrote: > Pierangelo Masarati wrote: >> You appear to be using back-hdb. > > Yes. > >> My guess is that if this can fail, e.g. because entries are being >> sync'ed out of order, the DN does not get fixed. If this is the case (I >> couldn't inspect code deep enough to make sure), I'd expect that the DN >> get fixed anyway, though, because missing entries should exist as "glue" >> objects. > > yes. But if you plan to use slapcat as a backup mechanism, then it's > still a problem. Sounds like a low priority issue at best. Taking backups of a replica while it is initializing is pointless, just take a backup of the provider instead. -- -- 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#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 13 Nov '09

13 Nov '09

Pierangelo Masarati wrote: > You appear to be using back-hdb. Yes. > My guess is that if this can fail, e.g. because entries are being > sync'ed out of order, the DN does not get fixed. If this is the case (I > couldn't inspect code deep enough to make sure), I'd expect that the DN > get fixed anyway, though, because missing entries should exist as "glue" > objects. yes. But if you plan to use slapcat as a backup mechanism, then it's still a problem. /Peter

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by masarati＠aero.polimi.it 13 Nov '09

13 Nov '09

apm(a)mutex.dk wrote: > Full_Name: Peter Mogensen > Version: 2.4.19 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.166.36.16) > > > Using openldap 2.4.17 and 2.4.19 linked with libdb4.6 and libdb4.8 in a > mirrormode setup: > > * Load the database with slapadd on server-1, start server-1 > The LDIF being loaded is generated with slapcat from a slapd 2.3.30-5+etch2 > Running on Debian Etch. I have no reason to suspect that it is not loaded > correctly into server1 > > * Start server-2 and monitor the progress of replication with slapcat, for > example: > > # for ((I=1;I<=20;I++)); do slapcat > out-$I; done > > * Look at the output: > > # for ((I=1;I<=20;I++)); do wc -l out-$I; done > > I would expect the generated files to be strictly increasing in size. > However, some times there's a file which is smaller than the previous. > In it I see LDIF entries like this: > > dn: > objectClass: top > objectClass: NamedObject > objectClass: simpleSecurityObject > uid: rieke > userPassword:: e1NBU0x..... > structuralObjectClass: NamedObject > entryUUID: e46b680e-e5f5-102b-93c9-79162adc1d46 > creatorsName: dc=admin,dc=example,dc=com > createTimestamp: 20070823185333Z > entryCSN: 20070823185333.000000Z#000002#000#000000 > modifiersName: dc=admin,dc=example,dc=com > modifyTimestamp: 20070823185333Z > > ... with an empty DN line. You appear to be using back-hdb. I note that in bdb_tool_entry_get() there is code specific to back-hdb that tries to lookup the parent of the current entry and, if found, "fixes" its DN. My guess is that if this can fail, e.g. because entries are being sync'ed out of order, the DN does not get fixed. If this is the case (I couldn't inspect code deep enough to make sure), I'd expect that the DN get fixed anyway, though, because missing entries should exist as "glue" objects. I apologize for the rather incomplete analysis, I can't dig further right now. I hope this provides some hint to others, unless completely wrong. p.

1 0

ITS#6375
by masarati＠aero.polimi.it 13 Nov '09

13 Nov '09

The ITS is to track software bugs. Please direct software usage questions to <openldap-solftware(a)openldap.org> and software interoperation questions to <openldap-technical(a)openldap.org>. This ITS will be closed. p.

1 0

(ITS#6375) Master Replica Synchronization
by jose.oliveira＠mailondemand.com.pt 13 Nov '09

13 Nov '09

Full_Name: Jose Vicente Fonseca de Oliveira Version: 2.4.11-1 OS: Debian 5.03 URL: ftp://mailondemand.com.pt Submission from: (NULL) (81.193.248.175) Dear Team, We have a PineApp antispam appliance that can authenticate users with our LDAP master server but cannot authenticate users with our LDAP replica server. For us everything seems OK but PineApp appliance just can't authenticate with our replica. PineApp refuses to give us further help saying that something is wrong in LDAP replication. Please, could you help us with that issue: the replica has the same information that master server has? We thank OpenLDAP Team in advance. Best regards, Jose Oliveira

1 0

Re: (ITS#6374) LDAP
by michael＠stroeder.com 12 Nov '09

12 Nov '09

atzig(a)mail2tim.com wrote: > Full_Name: Tim > Version: ? > OS: Win2003 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.62.17.129) > > > "Error 10: Referral" > > Unable to perform LDAP search - Error 10: Referral > This error means that the user's record in Active Directory was located on some > other server. > A "referral" in LDAP is simply a pointer or redirection to some other location > (or server). The "Error 10: Referral" error is usually caused by a misconfigured > LDAPBaseDN setting > > > LDAP was working correctly...started to receive this error after upgrading from > win2003 AD to Win2008. Could you please elaborate on what's the issue is with OpenLDAP client libs and/or tools? Ciao, Michael.

1 0

(ITS#6374) LDAP
by atzig＠mail2tim.com 12 Nov '09

12 Nov '09

Full_Name: Tim Version: ? OS: Win2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.62.17.129) "Error 10: Referral" Unable to perform LDAP search - Error 10: Referral This error means that the user's record in Active Directory was located on some other server. A "referral" in LDAP is simply a pointer or redirection to some other location (or server). The "Error 10: Referral" error is usually caused by a misconfigured LDAPBaseDN setting LDAP was working correctly...started to receive this error after upgrading from win2003 AD to Win2008.

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com 12 Nov '09

12 Nov '09

--001636988beae98b80047830ba81 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable pitpalme(a)gmail.com wrote: > masarati(a)aero.polimi.it wrote: > > pitpalme(a)gmail.com wrote: >> >> I do see attributes reflecting state after "modify" (which changes >>> "sn" attribute). >>> Where exactly should I expect to see a note about "glue state"? >>> Is output from "-d Any" helpful to figure what's going on (or wrong)? >>> >> >> My understanding of your previous message was that you got a positive >> result from delete, but an "Already exists" from a subsequent add. >> > > That=92s korrekt. > > > I inferred that you checked about the existence of the object and you go= t >> a negative result. >> > > In my current test scenario I do not check. > I assume a non-error on =84delete=93 in fact =84deletes=93, so I just che= ck if > response > code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91). > > > Apparently, my guess was wrong. In that case, you probably hit >> ITS#6097 <http://www.openldap.org/its?findid=3D6097>. >> > > *hmmm* Good idea, thanks. > But after reading ITS description I don=92t think it=92s what troubles m= e. > We don=92t actually neither have =84multi master mode=93, but =84mirror m= ode=93 and > writes are done only on exactly one server, so there should not be a prob= lem > with second server producing a concurrent write/modify. > I=92d expect the delete to be correctly propagated, but I can=92t check i= t is > is, simply because I have to little knowledge to read debug log correctly= . Follow up: I modified my test Perl script to do a 'ldapSearch' after deleting and it returns zero as number of found entries. Sadly I have no idea, how to emulate '-MM' when using 'Net::LDAP' and it's search function, so I can't check for 'glue' entries this way. --=20 Regards, Peter --001636988beae98b80047830ba81 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><span dir=3D"ltr"><a href=3D"mailto:pitpalme@gma= il.com">pitpalme(a)gmail.com</a></span>=A0wrote:<br><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex;"><div class=3D"im"> <a href=3D"mailto:masarati@aero.polimi.it" target=3D"_blank">masarati(a)aero.= polimi.it</a> wrote:<br> <br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <a href=3D"mailto:pitpalme@gmail.com" target=3D"_blank">pitpalme(a)gmail.com<= /a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I do see attributes reflecting state after "modify" (which change= s<br> "sn" attribute).<br> Where exactly should I expect to see a note about "glue state"?<b= r> Is output from "-d Any" helpful to figure what's going on (or= wrong)?<br> </blockquote> <br> My understanding of your previous message was that you got a positive<br> result from delete, but an "Already exists" from a subsequent add= .<br> </blockquote> <br></div> That=92s korrekt.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I inferred that you checked about the existence of the object and you got<b= r> a negative result.<br> </blockquote> <br></div> In my current test scenario I do not check.<br> I assume a non-error on =84delete=93 in fact =84deletes=93, so I just check= if response<br> code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91= ).<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Apparently, my guess was wrong. =A0In that case, you probably hit<br> ITS#6097 <<a href=3D"http://www.openldap.org/its?findid=3D6097" target= =3D"_blank">http://www.openldap.org/its?findid=3D6097</a>>.<br> </blockquote> <br></div> *hmmm* Good idea, thanks.<br> But after reading ITS description I don=92t think it=92s =A0what troubles m= e.<br> We don=92t actually neither have =84multi master mode=93, but =84mirror mod= e=93 and writes are done only on exactly one server, so there should not be= a problem with second server producing a concurrent write/modify.<br> I=92d expect the delete to be correctly propagated, but I can=92t check it = is is, simply because I have to little knowledge to read debug log correctl= y.</blockquote></div><div><br></div>Follow up:<div><br></div><div>I modifie= d my test Perl script to do a 'ldapSearch' after deleting and it re= turns zero as number of found entries.</div> <div>Sadly I have no idea, how to emulate '-MM' when using 'Net= ::LDAP' and it's search function, so I can't check for 'glu= e' entries this way.</div><div>-- <br>Regards, <div>Peter</div></div> --001636988beae98b80047830ba81--

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com 12 Nov '09

12 Nov '09

masarati(a)aero.polimi.it wrote: > pitpalme(a)gmail.com wrote: > >> I do see attributes reflecting state after "modify" (which changes >> "sn" attribute). >> Where exactly should I expect to see a note about "glue state"? >> Is output from "-d Any" helpful to figure what's going on (or wrong)? > > My understanding of your previous message was that you got a positive > result from delete, but an "Already exists" from a subsequent add. That=92s korrekt. > I inferred that you checked about the existence of the object and =20 > you got > a negative result. In my current test scenario I do not check. I assume a non-error on =84delete=93 in fact =84deletes=93, so I just = check if =20 response code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91). > Apparently, my guess was wrong. In that case, you probably hit > ITS#6097 <http://www.openldap.org/its?findid=3D6097>. *hmmm* Good idea, thanks. But after reading ITS description I don=92t think it=92s what troubles = me. We don=92t actually neither have =84multi master mode=93, but =84mirror = mode=93 =20 and writes are done only on exactly one server, so there should not be =20= a problem with second server producing a concurrent write/modify. I=92d expect the delete to be correctly propagated, but I can=92t check = it =20 is is, simply because I have to little knowledge to read debug log =20 correctly. =97 Regards, Peter

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by masarati＠aero.polimi.it 12 Nov '09

12 Nov '09

pitpalme(a)gmail.com wrote: > I do see attributes reflecting state after "modify" (which changes > "sn" attribute). > Where exactly should I expect to see a note about "glue state"? > Is output from "-d Any" helpful to figure what's going on (or wrong)? My understanding of your previous message was that you got a positive result from delete, but an "Already exists" from a subsequent add. I inferred that you checked about the existence of the object and you got a negative result. Apparently, my guess was wrong. In that case, you probably hit ITS#6097 <http://www.openldap.org/its?findid=6097>. p.

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com 11 Nov '09

11 Nov '09

masarati(a)aero.polimi.it wrote: > pitpalme+openldap(a)gmail.com wrote: >> [...] >> When adding, modifying and deleting an entry it can happend I do >> get a positive >> return from delete, but a subsequent "add" fails with "code=68: >> Already >> exists". > > Can you check whether the entry actually exist, although in "glue" > state? You can do this by searching (e.g. with ldapsearch) as the > rootdn, to bypass access checking, and using the manageDSAit control > (-MM). I modified my test perl script to exit if adding the entry failed, albeit a preceding delete should have removed it. Then I manually ran ldapsearch -D "rootdn" ... -b "TestBaseDN" -MM "cn=TestEntry" I got ==== 8>< ========================== [...] # with manageDSAit critical control [...] dn: cn=TestEntry,TestBaseDN objectClass: inetOrgPerson description: oldValue [...] # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ==== 8>< ========================== I do see attributes reflecting state after "modify" (which changes "sn" attribute). Where exactly should I expect to see a note about "glue state"? Is output from "-d Any" helpful to figure what's going on (or wrong)? -- Regards, Peter

1 0

Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 11 Nov '09

11 Nov '09

On Nov 11, 2009, at 9:45 AM, Quanah Gibson-Mount wrote: > --On Wednesday, November 11, 2009 9:36 AM -0800 Bryan Duncan = <bduncan(a)apple.com> wrote: >=20 >>=20 >> On Nov 11, 2009, at 9:04 AM, Quanah Gibson-Mount wrote: >>=20 >>> --On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan >>> <bduncan(a)apple.com> wrote: >>>=20 >>>=20 >>>> It was tested on OS X 10.6. Should work on all BSDs; nothing >>>> OSX-specific about the kqueue usage in the patch. As far as kqueue >>>> support in OS X 10.5, from what I see, most everything is there. >>>> Certainly all of the kqueue features in this patch are supported in = OS X >>>> 10.5. >>>=20 >>> Hi Bryan, >>>=20 >>> The URL to the patch you submitted with this ITS doesn't work. Can = you >>> please put the patch somewhere accessible and let us know where it = is? >>>=20 >>> Thanks, >>> Quanah >>=20 >> Hi Quanah, >>=20 >> My apologies for the bad URL. >>=20 >> The new URL is: >> http://public.me.com/bryan.duncan/bryan-duncan.kqueue.090922.patch If = you >> use a web browser to get it, there are extra steps: select the file >> "bryan-duncan.kqueue.090922.patch" and click download. ftp & curl = can >> pull it down directly with no extra steps. >=20 > Hi Bryan, >=20 > Thanks for the quick response. Hopefully we can get this incorporated = for OpenLDAP 2.5 series, and I'm interested in playing with it against = 2.4 to see how things change when used with Mac. >=20 > Thanks! >=20 > --Quanah Awesome! I look forward to seeing it OpenLDAP. If there's anything I = can do to help, please let me know. Thanks.=20 -- Bryan

1 0

Re: (ITS#6300) Add kqueue support to slapd
by quanah＠zimbra.com 11 Nov '09

11 Nov '09

--On Wednesday, November 11, 2009 9:36 AM -0800 Bryan Duncan <bduncan(a)apple.com> wrote: > > On Nov 11, 2009, at 9:04 AM, Quanah Gibson-Mount wrote: > >> --On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan >> <bduncan(a)apple.com> wrote: >> >> >>> It was tested on OS X 10.6. Should work on all BSDs; nothing >>> OSX-specific about the kqueue usage in the patch. As far as kqueue >>> support in OS X 10.5, from what I see, most everything is there. >>> Certainly all of the kqueue features in this patch are supported in OS X >>> 10.5. >> >> Hi Bryan, >> >> The URL to the patch you submitted with this ITS doesn't work. Can you >> please put the patch somewhere accessible and let us know where it is? >> >> Thanks, >> Quanah > > Hi Quanah, > > My apologies for the bad URL. > > The new URL is: > http://public.me.com/bryan.duncan/bryan-duncan.kqueue.090922.patch If you > use a web browser to get it, there are extra steps: select the file > "bryan-duncan.kqueue.090922.patch" and click download. ftp & curl can > pull it down directly with no extra steps. Hi Bryan, Thanks for the quick response. Hopefully we can get this incorporated for OpenLDAP 2.5 series, and I'm interested in playing with it against 2.4 to see how things change when used with Mac. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 11 Nov '09

11 Nov '09

On Nov 11, 2009, at 9:04 AM, Quanah Gibson-Mount wrote: > --On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan = <bduncan(a)apple.com> wrote: >=20 >=20 >> It was tested on OS X 10.6. Should work on all BSDs; nothing >> OSX-specific about the kqueue usage in the patch. As far as kqueue >> support in OS X 10.5, from what I see, most everything is there. >> Certainly all of the kqueue features in this patch are supported in = OS X >> 10.5. >=20 > Hi Bryan, >=20 > The URL to the patch you submitted with this ITS doesn't work. Can = you please put the patch somewhere accessible and let us know where it = is? >=20 > Thanks, > Quanah Hi Quanah, My apologies for the bad URL. The new URL is: = http://public.me.com/bryan.duncan/bryan-duncan.kqueue.090922.patch If you use a web browser to get it, there are extra steps: select the = file "bryan-duncan.kqueue.090922.patch" and click download. ftp & curl = can pull it down directly with no extra steps. -- Bryan=

1 0

Re: (ITS#6300) Add kqueue support to slapd
by quanah＠zimbra.com 11 Nov '09

11 Nov '09

--On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan <bduncan(a)apple.com> wrote: > It was tested on OS X 10.6. Should work on all BSDs; nothing > OSX-specific about the kqueue usage in the patch. As far as kqueue > support in OS X 10.5, from what I see, most everything is there. > Certainly all of the kqueue features in this patch are supported in OS X > 10.5. Hi Bryan, The URL to the patch you submitted with this ITS doesn't work. Can you please put the patch somewhere accessible and let us know where it is? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 10 Nov '09

10 Nov '09

--IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * mbackes(a)symas.com <mbackes(a)symas.com> [2009-11-10 22:55:10 +0000]: > Hello, Aleksey. >=20 > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls = =20 > > Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with =20 > > the make install STRIP=3D"" >=20 > Okay. >=20 > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. >=20 > > libdb-4.6.so.0 =3D> /usr/local/lib/libdb-4.6.so.0 (0x800a97000) >=20 > At the same time? Your ldd list below shows only berkeley db 4.6. =20 > These don't mix... Not same time. I tried with both backends. Results are same. >=20 > > In slapd config added using hdb as backend and indexes. Testing =20 > > database consist of 1000 users accounts with minimum attributes. On = =20 > > stress test load slapd Segmentation fault in 10-30 sec. >=20 > What sort of operations? Reading (Binds and searches).=20 Test script is loop of id command checking ldap via nss_ldap. >=20 > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=3DError accessing memory = =20 > > address > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 >=20 > Does it always fail at the same location? How reproducible is this? Often it is fail in "hdb_idl_fetch_key (be=3DError accessing memory address= ". 100% Reproducible on different hardware. On our normal work, slapd fails every 2-3 hours, on stress test slapd fail in 10-30 sec. Problem on freebsd7.x,8 and openldap2.3.43,2.4.18,2.4.19=20 I tryed on debian lenny and openldap2.4.11 and netbsd5.0.1 and openldap2.4.16 it rock stable. I think problem some where in freebsd and bdb backends.=20 Because freebsd7.1 openldap2.3.43 with depricated ldbm don`t fail on reading.=20 Ask if need any information.=20 Also I can give a shell access to testing server. =20 >=20 > Matthew Backes > Symas Corporation > mbackes(a)symas.com --=20 Email: alexs(a)ulgsm.ru Email/Jabber: alexs(a)ulgsm.ru --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iQEcBAEBAgAGBQJK+lahAAoJELAIdrQw5JcdnyYIAJrpD8OhUgzabzlAfcSmOZhH XUM+vzujX4N/czArACk/dXibX3D2AqQxv1CeUs0pI7Bo+iHLG0gsP6UD8k1fvDEg NecNe1zigD7JEGJDetHTMSXHjYkOvSJsqdBcWjNPuJZn62mg5hVs0S3XdGtqMRxw 4Ck+MwyWiAVQmCDYaXSCEEl6IyGehtD6f5liyNVakHIHG7bZ5MFSm0yP2oMtgxw2 W5vY7nUYK7w3l8ZXqx5pyjQBVBHoUCLFaqHXdXTcBHe3WJ2TQMx6utyvWi3uuqaR HFmg2NMvJSVnTnQsscxZgd2qILAmAx0SE2wd4D312ywsYZvFSGkzjX50JNpklT0= =s9Mn -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6--

1 0

ITS#5944 configure options --program-prefix and --program-suffix
by hyc＠symas.com 10 Nov '09

10 Nov '09

The OpenLDAP configure script and Makefiles don't do anything with these options. Sounds like you're looking at a RedHat-specific issue. This ITS will be closed. -- -- 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#6373) syncrepl subentry support
by hyc＠OpenLDAP.org 10 Nov '09

10 Nov '09

Full_Name: Howard Chu Version: 2.4/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc As discussed in this email thread http://www.openldap.org/lists/openldap-software/200910/msg00059.html in some situations it's necessary to store the syncrepl contextCSNs in a subentry of the database, instead of the context entry. Syncrepl in 2.2 used to do this but most of that code was removed in 2.3. It needs to be resurrected and usable as an option.

1 0

Re: (ITS#6312)
by hyc＠symas.com 10 Nov '09

10 Nov '09

neustradamus(a)hotmail.com wrote: > --_add76be3-02e1-47b1-b978-259bce59b479_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > You must change in configure and \include\PORTABLE.H : > > #define vsnprintf _vsnprintf > > with > > #if _MSC_VER < 1500 // 1500 =3D=3D VC++ 9.0 > #define vsnprintf _vsnprintf > #endif > > or > > #if _MSC_VER < 1500 > #define vsnprintf _vsnprintf > #endif You reported this issue against 2.2.16, which is several years obsolete. (Current version is 2.4.19.) The configure script has checked for vsnprintf and _vsnprintf for many years; it will not setup this #define if it doesn't need to. Closing this ITS. -- -- 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#6309) missing SEARCH information
by hyc＠symas.com 10 Nov '09

10 Nov '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.18 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I see the following logged at level 256: > > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 fd=117 ACCEPT from > IP=171.67.219.70:51122 (IP=0.0.0.0:389) > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=0 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=0 RESULT tag=97 err=14 > text=SASL(0): successful result: > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=1 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=1 RESULT tag=97 err=14 > text=SASL(0): successful result: > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND > authcid="service/vacation(a)stanford.edu" authzid="service/vacation(a)stanford.edu" > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND > dn="cn=vacation,cn=service,cn=applications,dc=stanford,dc=edu" mech=GSSAPI > sasl_ssf=56 ssf=56 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 RESULT tag=97 err=0 text= > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=3 do_search: invalid dn > (basedn) > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=3 SEARCH RESULT tag=101 err=34 > nentries=0 text=invalid DN > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 fd=117 closed (connection lost) > > > Since the actual search is not logged, there is no way to determine what the > invalid DN being used is in this case. This seems faulty. I'd expect to see > some additional logging like: The invalid DN *was* logged, it was "basedn". Sounds like you have a really badly configured client out there somewhere. Closing this ITS... -- -- 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#6372) slapd lockup on shutdown
by quanah＠zimbra.com 10 Nov '09

10 Nov '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Had an idle slapd lock up during shutdown. Backtrace as follows: Thread 10 (process 627): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=2) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c70b04d in __write_nocancel () from /lib64/tls/libpthread.so.0 #4 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #5 <signal handler called> #6 0x0000003c0c706ffb in pthread_join () from /lib64/tls/libpthread.so.0 #7 0x0000002a956b2408 in ldap_pvt_thread_join (thread=1082132832, thread_return=0x0) at thr_posix.c:197 #8 0x0000000000431c8c in slapd_daemon () at daemon.c:2835 #9 0x00000000004146d8 in main (argc=10, argv=0x7fbfffae38) at main.c:950 Thread 9 (process 637): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 8 (process 636): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #4 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #5 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #6 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #7 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 7 (process 635): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 6 (process 634): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 5 (process 633): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 4 (process 632): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 3 (process 631): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 2 (process 630): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 1 (process 629): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c70b04d in __write_nocancel () from /lib64/tls/libpthread.so.0 #4 0x000000000042d17d in slapd_clr_write (s=4113, wake=1) at daemon.c:951 #5 0x0000000000433ae8 in connection_wake_writers (c=0x1451ec0) at connection.c:778 #6 0x0000000000433c40 in connection_closing (c=0x1451ec0, why=0x4e3ee2 "slapd shutdown") at connection.c:806 #7 0x00000000004322bb in connections_shutdown () at connection.c:209 #8 0x0000000000431b31 in slapd_daemon_task (ptr=0x0) at daemon.c:2761 #9 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #10 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by mbackes＠symas.com 10 Nov '09

10 Nov '09

Hello, Aleksey. > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with > the make install STRIP="" Okay. > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) At the same time? Your ldd list below shows only berkeley db 4.6. These don't mix... > In slapd config added using hdb as backend and indexes. Testing > database consist of 1000 users accounts with minimum attributes. On > stress test load slapd Segmentation fault in 10-30 sec. What sort of operations? > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 Does it always fail at the same location? How reproducible is this? Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

(ITS#6371) problem with ber_flatten2
by dave.daugherty＠centrify.com 10 Nov '09

10 Nov '09

Full_Name: Dave Daugherty Version: 2.2.6 and 2.4.17 OS: RedHat EL3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.170.119.248) We use ber_flatten2 in an unusual way, but I think this issue is generic int ber_flatten2( BerElement *ber, struct berval *bv, int alloc ) { /* copy the berval */ ber_len_t len = ber_pvt_ber_write( ber ); if ( alloc ) { bv->bv_val = (char *) ber_memalloc_x( len + 1, ber->ber_memctx ); if ( bv->bv_val == NULL ) { return -1; } AC_MEMCPY( bv->bv_val, ber->ber_buf, len ); } else { bv->bv_val = ber->ber_buf; } bv->bv_val[len] = '\0'; <- ???? bv->bv_len = len; The problem I have is a crash, because of the bv->bv_val[len] = \0 when alloc is set to zero, AND the buffer that was passed in was generated by ber_realloc, which did not leave an extra byte at the end, resulting in a write beyond the allocated memory block. The questions I have are: 1) Is the zero terminator really necessary? 2) If so, seems like it should only be done if we actually allocated a new buffer (which does leave one byte at the end).

1 0

Re: (ITS#6370) Error converting syncprov-checkpoint option to olcSpCheckpoint attribute
by masarati＠aero.polimi.it 10 Nov '09

10 Nov '09

Fixed in HEAD, servers/slapd/overlays/syncprov.c 1.289 -> 1.290 Please test. The fix should apply smoothly to recent 2.4 releases. Thanks for reporting, p.

1 0

(ITS#6370) Error converting syncprov-checkpoint option to olcSpCheckpoint attribute
by kblaney＠nortel.com 10 Nov '09

10 Nov '09

Full_Name: Kyle Blaney Version: 2.4.15 OS: Redhat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.11.182.187) In OpenLDAP 2.4.19, values change when converting from the syncprov-checkpoint option in file-based configuration to the olcSpCheckpoint attribute in online configuration. To reproduce: 1. Configure OpenLDAP using file-based slapd.conf configuration that contains the following line: syncprov-checkpoint 100 10 2. Make slapd.d directory. 3. Convert file-based configuration to online configuration using the following command: slapd -f slapd.conf -F slapd.d File-based configuration is converted to the cn=config database, but after conversion the value of the olcSpCheckpoint attribute in the "olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config entry" is "100 600" when it should be the same as in file-based configuration ("100 10").

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by masarati＠aero.polimi.it 10 Nov '09

10 Nov '09

pitpalme+openldap(a)gmail.com wrote: > Full_Name: Peter Palmreuther > Version: 2.4.19 > OS: FreeBSD 7.2 / Solaris 8 > URL: > Submission from: (NULL) (87.123.91.4) > > > I've set up OpenLDAP to run in "MirrorMode": > > # [...] > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > # [...] > syncrepl rid=001 > provider=ldap://localhost:11389 > type=refreshAndPersist > searchbase="o=esolution,dc=deutscherv,dc=de" > schemachecking=on > bindmethod=simple > binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" > credentials="M1rr0rM3" > retry="60 +" > > serverID 1 > mirrormode on > # [...] > > The second server is set up identically, except "serverID" is 2 and "provider" > is set to URL of first server. The fact addresses are "localhost" is because I > replicated my main setup on my private server (FreeBSD) to better inspect and > debug the problem. > > When adding, modifying and deleting an entry it can happend I do get a positive > return from delete, but a subsequent "add" fails with "code=68: Already > exists". Can you check whether the entry actually exist, although in "glue" state? You can do this by searching (e.g. with ldapsearch) as the rootdn, to bypass access checking, and using the manageDSAit control (-MM). p.

1 0

(ITS#6247)
by daniel＠pluta.biz 10 Nov '09

10 Nov '09

Hi, I've uploaded a cleaned up version. It's nearly a complete rewrite of the original contribution. In addition to the previous version which (intentionally) just supported the constant MRA "NOW" the updated version also supports now[+/-]offset calculation and matching. The offset's syntax is "NYears#Nmonths#Ndays#NHours#NMinutes#NSeconds" where '#' separates the different time unit fields and N is the amount of time (offset) for a distinct time unit. N can be a negative or positive value (all none-digits and blanks are ignored, multiple signs are simply aggregated to a single (the first from the left) sign). Thanks to previous normalization before the actual matching the "timedrift effect" (see followup #4 above) isn't present any more, too. The two matching rule's (nowOrEarlier/nowOrLaterMatch) are compatible with any generalizedTime-syntax based attribute. Additionally the module introduces two specialized syntaxes exclusively dedicated to this modules matching rules (intentionally not supporting any kind of generalizedTime[Ordering]Match-ing extensible match). Please have a look at the README, the sample schema definition, and/or the source for further details. The current version can be found here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-091110-1.tgz Any kind of feedback is very welcome. Thanks a lot! Daniel

1 0

(ITS#6369) Get rid of cacertdir_rehash
by FullName＠in-valid.com 10 Nov '09

10 Nov '09

Full_Name: Full Name Version: 2.3.43 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:708:10:10:21c:25ff:fe98:3f0e) It is inconvenient to have to use cacertdir_rehash command to hash the certs. IMO it does not service any purpose. It would be nice if cert could be just dropped to a dir and then openldap sees it.

1 0

(ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 09 Nov '09

09 Nov '09

Full_Name: Peter Palmreuther Version: 2.4.19 OS: FreeBSD 7.2 / Solaris 8 URL: Submission from: (NULL) (87.123.91.4) I've set up OpenLDAP to run in "MirrorMode": # [...] overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # [...] syncrepl rid=001 provider=ldap://localhost:11389 type=refreshAndPersist searchbase="o=esolution,dc=deutscherv,dc=de" schemachecking=on bindmethod=simple binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" credentials="M1rr0rM3" retry="60 +" serverID 1 mirrormode on # [...] The second server is set up identically, except "serverID" is 2 and "provider" is set to URL of first server. The fact addresses are "localhost" is because I replicated my main setup on my private server (FreeBSD) to better inspect and debug the problem. When adding, modifying and deleting an entry it can happend I do get a positive return from delete, but a subsequent "add" fails with "code=68: Already exists". This does not happen all the time, but often enough to name it "reproducible". This seems not to happen if there's a "sleep" between modify and delete. It also seems not to happen if secondary server is down.

1 0

Bug in deleting entry in MirrorMode?
by Peter Palmreuther 09 Nov '09

09 Nov '09

Hello, I'm writing to this list to clarify if I discovered a bug or just did not configure OpenLDAP properly. I've set up OpenLDAP to run in "MirrorMode": # [...] overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # [...] syncrepl rid=001 provider=ldap://localhost:11389 type=refreshAndPersist searchbase="o=esolution,dc=deutscherv,dc=de" schemachecking=on bindmethod=simple binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" credentials="M1rr0rM3" retry="60 +" serverID 1 mirrormode on # [...] The second server is set up identically, except "serverID" is 2 and "provider" is set to URL of first server. The fact addresses are "localhost" is because I replicated my main setup on my private server to better inspect and debug the problem. When adding, modifying and deleting an entry it can happend I do get a positive return from delete, but a subsequent "add" fails with "code=68: Already exists". This does not happen all the time, but often enough to name it "reproducible". This seems not to happen if there's a "sleep" between modify and delete. It also seems not to happen if secondary server is down. So either I've got a configuration problem or there's a problem with synchronization. Anybody here to help, tracking down this problem? Thanks a lot, and -- Regards, Peter

2 1

(ITS#6367) syncprov ... changed by peer, ignored
by olivier.chirossel＠sfr.com 09 Nov '09

09 Nov '09

Full_Name: olivier chirossel Version: 2.4.17 and 2.4.19 OS: linux URL: http://86.64.145.174:8080/ Submission from: (NULL) (62.39.9.251) in refreshend persist mode, the replication is incorrect for an entry which be delete/add after master restart and before the reconnection of the slave. steps to reproduce : 0) two linux server (one for the master, one for the slave) on the master ip : 10.143.73.9 on the slave ip : 10.143.73.71 1) kernel configuration on the slave by default tcp_keepalive_time 7200 on linux and tcp_keepalive_probes 9 put in /etc/sysctl.conf net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_probes = 2 and sysctl -p 2) master set up on /etc/openldap tar xvf slapd_master.tar (get on the url ) and slapd -F /etc/openldap/slapd.d and ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f first.ldif (get on url) 2) slave set up on /etc/openldap tar xvf slapd_slave.tar (get on the url ) and slapd -F /etc/openldap/slapd.d 2) on the master : add the entry ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f test1init.ldif (get on url) 3) on the master : restart the master and delete/add (with new value) kill `pidof slapd` slapd -F /etc/openldap/slapd.d ldapdelete -h 10.153.73.9 -D "cn=admin, cn=config" -w secret msisdn=6666666660,suffix=0,dc=sfr.com ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f testcreate.ldif (get on url) verify the entry ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b " suffix=0,dc=sfr.com" 4) on the slave : see the slave reconnect netstat -an | grep 389 for see the connection between the slave and the master ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b " suffix=0,dc=sfr.com" see the logs 5) on the slave after reconnection to the master ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b " suffix=0,dc=sfr.com" ( "no entry for dn msisdn=6666666660,suffix=0,dc=sfr.com" ) 6) on the master after reconnection from the slave to the master in the logs syncprov ... changed by peer, ignored

1 0

Re: (ITS#6366) application GUI crashes when openning file by a user created by LDAP
by michael＠stroeder.com 06 Nov '09

06 Nov '09

fuzq(a)anl.gov wrote: > Full_Name: Albert Fu > Version: 2.3.27-8.el5_2.4.i386 > OS: Scientific Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (164.54.208.62) > > > I have a Linux application software with a text editor developed with QT > and C++. Every time when openning a file by a user created by LDAP, the > software crashes with "floating point exception". However, this doesn't > happen to users added to the system by command 'useradd' or 'Users and > Groups' tool of the system. I really doubt that this has something to do with OpenLDAP itself. Regarding the LDAP side you should try to track down whether the user data returned via nss_ldap or similar is complete and correct. Anyway the software should not crash if the user name for a numeric user id cannot be found. Ciao, Michael.

1 0

Re: (ITS#6366) application GUI crashes when openning file by a user created by LDAP
by quanah＠zimbra.com 06 Nov '09

06 Nov '09

--On Friday, November 06, 2009 5:07 PM +0000 fuzq(a)anl.gov wrote: > Full_Name: Albert Fu > Version: 2.3.27-8.el5_2.4.i386 > OS: Scientific Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (164.54.208.62) > > > I have a Linux application software with a text editor developed with QT > and C++. Every time when openning a file by a user created by LDAP, the > software crashes with "floating point exception". However, this doesn't > happen to users added to the system by command 'useradd' or 'Users and > Groups' tool of the system. Aside from the fact that 2.3 is historic, how is it OpenLDAP's bug that an application you wrote crashes? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6366) application GUI crashes when openning file by a user created by LDAP
by fuzq＠anl.gov 06 Nov '09

06 Nov '09

Full_Name: Albert Fu Version: 2.3.27-8.el5_2.4.i386 OS: Scientific Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (164.54.208.62) I have a Linux application software with a text editor developed with QT and C++. Every time when openning a file by a user created by LDAP, the software crashes with "floating point exception". However, this doesn't happen to users added to the system by command 'useradd' or 'Users and Groups' tool of the system. Thanks,

1 0

(ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 06 Nov '09

06 Nov '09

Full_Name: Peter Mogensen Version: 2.4.19 OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.166.36.16) Using openldap 2.4.17 and 2.4.19 linked with libdb4.6 and libdb4.8 in a mirrormode setup: * Load the database with slapadd on server-1, start server-1 The LDIF being loaded is generated with slapcat from a slapd 2.3.30-5+etch2 Running on Debian Etch. I have no reason to suspect that it is not loaded correctly into server1 * Start server-2 and monitor the progress of replication with slapcat, for example: # for ((I=1;I<=20;I++)); do slapcat > out-$I; done * Look at the output: # for ((I=1;I<=20;I++)); do wc -l out-$I; done I would expect the generated files to be strictly increasing in size. However, some times there's a file which is smaller than the previous. In it I see LDIF entries like this: dn: objectClass: top objectClass: NamedObject objectClass: simpleSecurityObject uid: rieke userPassword:: e1NBU0x..... structuralObjectClass: NamedObject entryUUID: e46b680e-e5f5-102b-93c9-79162adc1d46 creatorsName: dc=admin,dc=example,dc=com createTimestamp: 20070823185333Z entryCSN: 20070823185333.000000Z#000002#000#000000 modifiersName: dc=admin,dc=example,dc=com modifyTimestamp: 20070823185333Z ... with an empty DN line. My config is as follows. It has been converted to LDIF and the server is running with a cn=config database: ============================================ #gentlehup on pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none tool-threads 4 # Modules modulepath /usr/lib/ldap moduleload back_hdb moduleload syncprov # Schemas include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema # Limits disallow bind_anon #idletimeout 120 sizelimit 2000 # TLS/Auth TLSCACertificateFile /etc/ldap/ssl/ca.crt TLSCertificateFile /etc/ldap/ssl/server.crt TLSCertificateKeyFile /etc/ldap/ssl/server.nopass.key TLSCipherSuite "NULL-SHA" # Allow root to configure slapd via ldapi:/// TLSVerifyClient demand authz-regexp "gidNumber=0\\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=config" authz-regexp "email=root(a)example.com,cn=config,ou=dev,o=example.com,st=Denmark,c=DK" "cn=config" ##### Mirror mode #### serverID 2 database config limits dn.exact="cn=config" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited syncrepl rid=1 provider=ldaps://server1.example.com:636/ searchbase="cn=config" type=refreshAndPersist retry="60 +" scope=sub schemachecking=on bindmethod=sasl binddn="cn=config" saslmech="EXTERNAL" tls_cert=/etc/ldap/ssl/config.crt tls_key=/etc/ldap/ssl/config.nopass.key tls_cacert=/etc/ldap/ssl/ca.crt tls_cipher_suite="NULL-SHA" syncrepl rid=2 provider=ldaps://server2.example.com:636/ searchbase="cn=config" type=refreshAndPersist retry="60 +" scope=sub schemachecking=on bindmethod=sasl binddn="cn=config" saslmech="EXTERNAL" tls_cert=/etc/ldap/ssl/config.crt tls_key=/etc/ldap/ssl/config.nopass.key tls_cacert=/etc/ldap/ssl/ca.crt tls_cipher_suite="NULL-SHA" overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE mirrormode on ================================================= The database which I slapcat and which is being replicated has been loaded with " ldapadd -YEXTERNAL -H ldapi:/// -f ..." from this LDIF: dn: olcDatabase={1}hdb,cn=config objectClass: olcHdbConfig objectClass: olcDatabaseConfig olcDatabase: hdb olcSuffix: cn=data,dc=example,dc=com olcRootDN: cn=config olcDbDirectory: /var/lib/ldap/cn=data,dc=example,dc=com olcDbMode: 0660 olcDbConfig: set_cachesize 2 0 0 olcDbConfig: set_lg_bsize 2097512 olcDbConfig: set_lg_dir /var/lib/ldap/cn=data,dc=example,dc=com-log olcDbConfig: set_flags DB_LOG_AUTOREMOVE olcDbConfig: set_lk_max_objects 5000 olcDbConfig: set_lk_max_locks 5000 olcDbConfig: set_lk_max_lockers 5000 olcDbCheckpoint: 1024 10 olcDbCachefree: 16 olcDbCachesize: 100000 olcDbIDLcacheSize: 300000 olcDbLinearIndex: TRUE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn eq,sub olcDbIndex: uid eq olcDbIndex: ou eq olcDbIndex: o eq olcDbIndex: givenName eq,sub olcDbIndex: sn eq,sub olcDbIndex: mail eq,sub olcDbIndex: member eq olcDbIndex: reader eq olcDbIndex: writer eq olcDbIndex: admin eq olcAccess: to dn.base="cn=data,dc=example,dc=com" attrs=userPassword by * auth olcAccess: to dn.base="cn=data,dc=example,dc=com" by dn.base="cn=data,dc=example,dc=com" search olcAccess: to dn.children="cn=data,dc=example,dc=com" by dn.base="cn=data,dc=example,dc=com" write olcSyncRepl: rid=3 provider=ldaps://server1.example.com:636/ searchbase="cn=data,dc=example,dc=com" type=refreshAndPersist retry="60 +" scope=sub schemachecking=on bindmethod=sasl binddn="cn=config" saslmech="EXTERNAL" tls_cert=/etc/ldap/ssl/config.crt tls_key=/etc/ldap/ssl/config.nopass.key tls_cacert=/etc/ldap/ssl/ca.crt tls_cipher_suite="NULL-SHA" olcSyncRepl: rid=4 provider=ldaps://server2.example.com:636/ searchbase="cn=data,dc=example,dc=com" type=refreshAndPersist retry="60 +" scope=sub schemachecking=on bindmethod=sasl binddn="cn=config" saslmech="EXTERNAL" tls_cert=/etc/ldap/ssl/config.crt tls_key=/etc/ldap/ssl/config.nopass.key tls_cacert=/etc/ldap/ssl/ca.crt tls_cipher_suite="NULL-SHA" olcMirrorMode: TRUE olcLimits: dn.base="cn=config" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 600 olcSpSessionlog: 100 olcSpReloadHint: TRUE dn: olcOverlay=refint,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: refint olcRefintAttribute: member

1 0

Re: (ITS#6364) refint needs to have rootdn set
by michael＠stroeder.com 06 Nov '09

06 Nov '09

quanah(a)OpenLDAP.org wrote: > The refint overlay doesn't necessarily work correctly without a rootdn being set > on the database it is applying to. This requirement should be documented in the > man page. I'd argue that slapd should not even start if such a strong requirement of an overlay is not met by configuration. Ciao, Michael.

1 0

(ITS#6364) refint needs to have rootdn set
by quanah＠OpenLDAP.org 05 Nov '09

05 Nov '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The refint overlay doesn't necessarily work correctly without a rootdn being set on the database it is applying to. This requirement should be documented in the man page. See: http://www.openldap.org/lists/openldap-software/200911/msg00039.html for more info

1 0

(ITS#6363) back-config fails on some modify operations
by rhafer＠suse.de 05 Nov '09

05 Nov '09

Full_Name: Ralf Haferkamp Version: RE24, Head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.200.105) Example: I have the following entry in cn=config: dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by self none olcRootDN: cn=config olcRootPW: secret olcSecurity: simple_bind=128 Doing this modification: dn: olcDatabase={0}config,cn=config replace: olcAccess olcAccess: to * by * none - delete: olcSecurity olcSecurity: simple_bind=128 fails with: modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcAccess> unknown factor slapd logs: Nov 5 14:41:42 devel slapd[29934]: olcAccess: value #0: <olcAccess> unknown factor p��Ŷ Nov 5 14:41:42 devel slapd[29934]: conn=10 op=1 RESULT tag=103 err=80 text=<olcAccess> unknown factor The problem seems to be that ca->argv[] isn't correctly initialized in config_modify_internal. I am working on a fix currently.

1 0

(ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 04 Nov '09

04 Nov '09

Full_Name: Aleksey Version: 2.4.19 OS: Freebsd7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.93.136.26) Openldap 2.4.19 installed from freebsd ports. All configs in defauls Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with the make install STRIP="" Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. In slapd config added using hdb as backend and indexes. Testing database consist of 1000 users accounts with minimum attributes. On stress test load slapd Segmentation fault in 10-30 sec. #ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) libc.so.7 => /lib/libc.so.7 (0x8015f5000) #gdb /usr/local/libexec/slapd (gdb) run -d 0 Starting program: /usr/local/libexec/slapd -d 0 [New LWP 100311] [New Thread 0x801a020b0 (LWP 100311)] [New Thread 0x801a02880 (LWP 100073)] [New Thread 0x8034040b0 (LWP 100076)] [New Thread 0x803404240 (LWP 100077)] [New Thread 0x8034043d0 (LWP 100078)] [New Thread 0x803404560 (LWP 100116)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x803404560 (LWP 100116)] 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address 0x7ffffd9f9f38: Bad s. ) at idl.c:511 511 { (gdb) (gdb) (gdb) where #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address 0x7ffffd9f9f38: dress. ) at idl.c:511 #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, txn=0x80352b040, k=0x8069005 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, ava=0x7ffffda7a4f0, ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a550, ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, flist=0x7ffffda7a5 f type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at filterindex.c:581 #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a530, ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, flist=0x7ffffda7a5 f type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at filterindex.c:581 #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a570, ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, e=0x7ffffda7a71 tx n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:586 #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:366 #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:217 #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, arg_v=0x803521000) at connection .c:1123 #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) at connection.c:125 9 #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.4.so. #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 #16 0x0000000000000000 in ?? () Error accessing memory address 0x7ffffdbfb000: Bad address.

1 0

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 04 Nov '09

04 Nov '09

Yes, I have just been able to recreate this in 2.4.19. The line in daemon.c at which the assertion occurs in this version is 994. I have also seen: ldap_write: want=22 error=Broken pipe ... slapd: connection.c:786: connection_closing: Assertion 'c->c_struct_state == SLAP_C_USED' failed One things to note is that, in addition to being on MIPS32, my platform has only 32MB of memory. I also have a swap file that is 64MB.

1 0

slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 04 Nov '09

04 Nov '09

Good day. Openldap 2.4.19 installed from freebsd ports. All configs in defauls Freebsd 7.2 amd64 All configs in defauls, added anly indexes and back_end are hdb. Testing database is 1000 users accounts with minimal attributes from standart schemas. Under testing load slapd crash after 10sec of work. ]>ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) libc.so.7 => /lib/libc.so.7 (0x8015f5000) gdb /usr/local/libexec/slapd (gdb) run -d 0 Starting program: /usr/local/libexec/slapd -d 0 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debug symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols d)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no gging symbols found)...[New LWP 100584] (no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8019020b0 (LWP 100584)] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debug symbols found)...[New Thread 0x801902560 (LWP 100085)] [New Thread 0x8022040b0 (LWP 100113)] [New Thread 0x802204240 (LWP 100128)] [New Thread 0x8022043d0 (LWP 100162)] [New Thread 0x802204560 (LWP 100209)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x802204560 (LWP 100209)] 0x0000000801d96b6e in hdb_idl_fetch_key () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 (gdb) (gdb) (gdb) where #0 0x0000000801d96b6e in hdb_idl_fetch_key () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #1 0x0000000801d8e449 in hdb_key_read () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #2 0x0000000801d909f4 in hdb_filter_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #3 0x0000000801d91376 in list_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #4 0x0000000801d8fa1c in hdb_filter_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #5 0x0000000801d91376 in list_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #6 0x0000000801d8fd4a in hdb_filter_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #7 0x0000000801d8ab36 in hdb_search () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #8 0x000000000042cda8 in fe_op_search () #9 0x000000000042d519 in do_search () #10 0x000000000042a9ef in connection_closing () #11 0x000000000042b48a in connections_shutdown () #12 0x000000080074b352 in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.4.so.7 #13 0x00000008014e54d1 in pthread_getprio () from /lib/libthr.so.3 #14 0x0000000000000000 in ?? () Error accessing memory address 0x7ffffdbfb000: Bad address. (gdb) I glad to give a more debug, if any body say how to do it. -- Email: alexs(a)ulgsm.ru Email/Jabber: alexs(a)ulgsm.ru

3 5

Re: (ITS#6353) berval->string conversions ignore \0
by h.b.furuseth＠usit.uio.no 04 Nov '09

04 Nov '09

I wrote: > Conversion from a binary blob (struct berval*, BerElement read) > to a char* string typically just grabs bv.bv_val even when the > value may contain embedded '\0's. > > In these cases, correct operation may require that the conversion > fails if bv_len != (bv_val ? strlen(bv_val) : 0). Or if bv_val is > not \0-terminated, to check if memchr(bv_val, '\0', bv_len) == NULL. > > Examples: liblber/decode.c: > ber_get_stringa, ber_get_stringb, ber_get_bitstringa, ber_scanf "aAv" decode.c now rejects embedded NUL bytes in cases where we do not save the length anywhere. However it accepts terminating NUL bytes, which AD can send at least in diagonsticMessage: http://www.openldap.org/lists/openldap-devel/200911/msg00001.html -- Hallvard

1 0

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by hyc＠symas.com 03 Nov '09

03 Nov '09

mike(a)flyn.org wrote: > Full_Name: W. Michael Petullo > Version: 2.4.16 > OS: OpenWRT/Linux/glibc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.6.126.162) > > > I am running slapd on OpenWRT/MIPS32/Linux/glibc. I have found that after a > period of running, slapd terminates with: Please try to reproduce this with a current release (2.4.19). > > slapd: daemon.c:983: slapd_set_read: Assertion > ((((&slap_daemon.sd_actives)->__fds_bits)[(((s)) / (8 * sizeof (__fd_mask)))] & > ((__fd_mask) 1 << (((s)) % (8 * sizeof (___fd_mask))))) != 0) failed. > > $ ldd /usr/sbin/slapd > libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x2aad8000) > liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x2ab20000) > libuuid.so.1 => /usr/lib/libuuid.so.1 (0x2ab3c000) > libdb-4.7.so => /usr/lib/libdb-4.7.so (0x2ab50000) > libresolv.so.2 => /lib/libresolv.so.2 (0x2ac92000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aca6000) > libc.so.6 => /lib/libc.so.6 (0x2ad3e000) > libpthread.so.0 => /lib/libpthread.so.0 (0x2ae98000) > /lib/ld.so.1 (0x2aaa8000) > > $ slapd -V > @(#) $OpenLDAP: slapd 2.4.16 (Nov 3 2009 08:04:35) $ > -- -- 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 03 Nov '09

03 Nov '09

Full_Name: W. Michael Petullo Version: 2.4.16 OS: OpenWRT/Linux/glibc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.6.126.162) I am running slapd on OpenWRT/MIPS32/Linux/glibc. I have found that after a period of running, slapd terminates with: slapd: daemon.c:983: slapd_set_read: Assertion ((((&slap_daemon.sd_actives)->__fds_bits)[(((s)) / (8 * sizeof (__fd_mask)))] & ((__fd_mask) 1 << (((s)) % (8 * sizeof (___fd_mask))))) != 0) failed. $ ldd /usr/sbin/slapd libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x2aad8000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x2ab20000) libuuid.so.1 => /usr/lib/libuuid.so.1 (0x2ab3c000) libdb-4.7.so => /usr/lib/libdb-4.7.so (0x2ab50000) libresolv.so.2 => /lib/libresolv.so.2 (0x2ac92000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aca6000) libc.so.6 => /lib/libc.so.6 (0x2ad3e000) libpthread.so.0 => /lib/libpthread.so.0 (0x2ae98000) /lib/ld.so.1 (0x2aaa8000) $ slapd -V @(#) $OpenLDAP: slapd 2.4.16 (Nov 3 2009 08:04:35) $

1 0

(ITS#6360) slapd memory usage grows to consume all available memory
by whm＠stanford.edu 03 Nov '09

03 Nov '09

Full_Name: Bill MacAllister Version: 2.4.19+ OS: Debian 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) We are using OpenLDAP 2.4.19 with a patch for ITS6334. We are using libhoard for memory management. The backend database is bdb 4.8. We are seeing slapd memory usage grow until all of the memory on the system is consumed. Our database has a bit over 500,000 dns. The cache values we are using are: cachesize 200000 dncachesize 0 idlcachesize 200000 On a test server with 16 bg of memory, 14.7 consumed by slapd we see: ldapsearch -b cn=monitor + | grep -i cache olmBDBEntryCache: 115 olmBDBDNCache: 519795 olmBDBIDLCache: 60510 I have tried running slapd under valgrind and when the server is shutdown valgrind does not report any memory leaks. It appears that slapd allocates the memory, remembers it has allocated it, and does not use it.

1 0

Re: (ITS#6357) Problem configuring openldap
by quanah＠zimbra.com 02 Nov '09

02 Nov '09

--On Friday, October 30, 2009 11:34 PM +0000 pierre42d(a)9online.fr wrote: I suggest you read the README file shipped with the OpenLDAP release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5810) $BACKEND selections in make test
by h.b.furuseth＠usit.uio.no 02 Nov '09

02 Nov '09

Maybe it's about time to close this one... Could someone test if NDB likes this acfilter.sh instead of the current one? In the tests where NDB works, anyway. I don't know which ones. The current acfilter depends on awk being GNU awk, which can be wrong even on Linux. Ubuntu has awk = mawk. This variant uses perl instead. back-ldif passes most tests with this acfilter and a few additions of BACKEND2SORT="ldif=e". #! /bin/sh # $OpenLDAP: pkg/ldap/tests/scripts/acfilter.sh,v 1.15 2009/01/21 23:40:44 kurt Exp $ ## This work is part of OpenLDAP Software <http://www.openldap.org/>. ## ## Copyright 1998-2009 The OpenLDAP Foundation. ## All rights reserved. ## ## Redistribution and use in source and binary forms, with or without ## modification, are permitted only as authorized by the OpenLDAP ## Public License. ## ## A copy of this license is available in the file LICENSE in the ## top-level directory of the distribution or, alternatively, at ## <http://www.OpenLDAP.org/license.html>. # Strip LDIF comments, or strip everything when $BACKEND=null. # Optionally sort attrs/entries according to $BACKEND2SORT: # BACKEND2SORT="<backend>=[a][e],<backend>=[a][e],..." says whether # to sort attributes in an entry, and whether to sort entries. # 2+ empty input lines separate each list of entries to be sorted. # This feature needs Perl, otherwise any sorting is just by lines. # Defaults, used when $BACKEND2SORT does not mention $BACKEND acfilter_b2s="ndb=a" case ,$BACKEND2SORT in *,$BACKEND=*) acfilter_b2s=$BACKEND2SORT ;; esac case $BACKEND,$acfilter_b2s in null,*) : ;; *,$BACKEND=[ae]*) if (perl -e 0) 2>/dev/null; then perl -we ' ($end, $sort, @e, @out) = ("", $ARGV[0] =~ /,\Q$ARGV[1]\E=(\w*)/); sub lsort { shift(@_) =~ /[$sort]/o ? sort(@_) : @_; } foreach (<STDIN>, "", "") { if (/^ /s) { $e[-1] .= $_; next; } if (/./m) { push @e, $_ unless /^\#/s; next; } if (!@out) { print $end; $end = ""; } if (@e) { push @out, join "", shift(@e), &lsort("a", splice @e); } else { print join("\n", &lsort("e", splice @out)), $end; } $end = $_; }' ",$acfilter_b2s" "$BACKEND" else grep -v '^#' | sort ; fi ;; *) grep -v '^#' ;; esac

1 0

Re: (ITS#6337) Combining back-relay/slapo-rwm and back-hdb/slapo-accesslog seg faults
by h.b.furuseth＠usit.uio.no 02 Nov '09

02 Nov '09

Committed a new fix for Bind and Extended operations in HEAD. This one has no impact on cases which already worked before this ITS: It just searches for the callback and removes it. Possibly something like the previous fix would actually make back-relay better behaved, but such behavior change and my chatter in previous message should go in a separate ITS if someone investigates it. -- Hallvard

1 0

(ITS#6359) Problem compiling openldap
by pierre42d＠9online.fr 30 Oct '09

30 Oct '09

Full_Name: Pierre Version: 2.4.19 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.89.161.74) # make Making all in /tmp/openldap-2.4.19 Entering subdirectory include make[1]: Entering directory `/tmp/openldap-2.4.19/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/openldap-2.4.19/include' Entering subdirectory libraries make[1]: Entering directory `/tmp/openldap-2.4.19/libraries' Making all in /tmp/openldap-2.4.19/libraries Entering subdirectory liblutil make[2]: Entering directory `/tmp/openldap-2.4.19/libraries/liblutil' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.19/libraries/liblutil' Entering subdirectory liblber make[2]: Entering directory `/tmp/openldap-2.4.19/libraries/liblber' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.19/libraries/liblber' Entering subdirectory liblunicode make[2]: Entering directory `/tmp/openldap-2.4.19/libraries/liblunicode' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.19/libraries/liblunicode' Entering subdirectory libldap make[2]: Entering directory `/tmp/openldap-2.4.19/libraries/libldap' /bin/sh ../../libtool --mode=link gcc -s -O3 -march=i686 -L/usr/local/BerkeleyDB.4.6/lib -o apitest apitest.o libldap.la ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl2 -lgnutls -lcrypt -lresolv gcc -s -O3 -march=i686 -o .libs/apitest apitest.o -L/usr/local/BerkeleyDB.4.6/lib ./.libs/libldap.so /tmp/openldap-2.4.19/libraries/liblber/.libs/liblber.so -L/usr/local/lib ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/local/lib/libsasl2.so -ldl /usr/local/lib/libgnutls.so /usr/local/lib/libtasn1.so /usr/local/lib/libgcrypt.so -lnsl -lcap /usr/local/lib/libgpg-error.so -lz -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_x509_crt_list_import' ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' ./.libs/libldap.so: undefined reference to `gnutls_cipher_suite_info' collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/tmp/openldap-2.4.19/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/tmp/openldap-2.4.19/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#6358) Problem compiling openldap
by pierre42d＠9online.fr 30 Oct '09

30 Oct '09

Problem linked to the use of the --enable-lmpasswd option

1 0

(ITS#6358) Problem compiling openldap
by pierre42d＠9online.fr 30 Oct '09

30 Oct '09

Full_Name: Pierre Version: 2.4.19 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.89.161.74) # make Making all in /tmp/openldap-2.4.19 Entering subdirectory include make[1]: Entering directory `/tmp/openldap-2.4.19/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/openldap-2.4.19/include' Entering subdirectory libraries make[1]: Entering directory `/tmp/openldap-2.4.19/libraries' Making all in /tmp/openldap-2.4.19/libraries Entering subdirectory liblutil make[2]: Entering directory `/tmp/openldap-2.4.19/libraries/liblutil' gcc -s -O3 -march=i686 -I../../include -I../../include -I/usr/local/BerkeleyDB.4.6/include -I/usr/local/BerkeleyDB.4.6/include -c -o passwd.o passwd.c passwd.c:820: error: parse error before "des_key" passwd.c: In function `lmPasswd_to_key': passwd.c:822: error: `lmPasswd' undeclared (first use in this function) passwd.c:822: error: (Each undeclared identifier is reported only once passwd.c:822: error: for each function it appears in.) passwd.c:835: error: `key' undeclared (first use in this function) passwd.c: In function `chk_lanman': passwd.c:846: error: `des_key' undeclared (first use in this function) passwd.c:846: error: parse error before "key" passwd.c:847: error: `des_context' undeclared (first use in this function) passwd.c:848: error: `des_data_block' undeclared (first use in this function) passwd.c:866: error: `key' undeclared (first use in this function) passwd.c:867: error: `schedule' undeclared (first use in this function) passwd.c:868: error: `StdText' undeclared (first use in this function) passwd.c:868: error: `PasswordHash1' undeclared (first use in this function) passwd.c:868: error: `DES_ENCRYPT' undeclared (first use in this function) passwd.c:876: error: `PasswordHash2' undeclared (first use in this function) passwd.c: In function `hash_lanman': passwd.c:1142: error: `des_key' undeclared (first use in this function) passwd.c:1142: error: parse error before "key" passwd.c:1143: error: `des_context' undeclared (first use in this function) passwd.c:1144: error: `des_data_block' undeclared (first use in this function) passwd.c:1162: error: `key' undeclared (first use in this function) passwd.c:1163: error: `schedule' undeclared (first use in this function) passwd.c:1164: error: `StdText' undeclared (first use in this function) passwd.c:1164: error: `PasswordHash1' undeclared (first use in this function) passwd.c:1164: error: `DES_ENCRYPT' undeclared (first use in this function) passwd.c:1168: error: `PasswordHash2' undeclared (first use in this function) make[2]: *** [passwd.o] Error 1 make[2]: Leaving directory `/tmp/openldap-2.4.19/libraries/liblutil' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/tmp/openldap-2.4.19/libraries' make: *** [all-common] Error 1

1 0

(ITS#6357) Problem configuring openldap
by pierre42d＠9online.fr 30 Oct '09

30 Oct '09

Full_Name: Pierre Version: 2.4.19 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.89.161.74) [...] checking number of arguments of ctime_r... 2 checking number of arguments of gethostbyname_r... 6 checking number of arguments of gethostbyaddr_r... 8 checking db.h usability... no checking db.h presence... no checking for db.h... no configure: error: BDB/HDB: BerkeleyDB not available But I have Berkeley DB installed in its default location...

1 0

Re: ITS#3526 chaining enhancements
by masarati＠aero.polimi.it 30 Oct '09

30 Oct '09

> Looks to me like the mentioned features have been implemented and this ITS > should be closed. OK? Yes, everything seems to be implemented. Note that chained operations only work for a single hop, since back-ldap does not allow to add proxied authz control when already set. Thanks, p.

1 0

Re: (ITS#6324) slapd -d ? emits incorrect value for LDAP_DEBUG_ANY on x86_64
by h.b.furuseth＠usit.uio.no 30 Oct '09

30 Oct '09

That fix caused a lot of overflow warnings about LDAP_DEBUG_ANY. I've updated ldap/include/ldap_log.h, ldap/servers/slapd/bconfig.c with an alternate fix. (The main.c fix stays.) While I was at it, I handled output of ANY as -1 specially, since that is a common input value but other negative numbers are not. -- Hallvard

1 0

(ITS#6356) slapd.conf tcp-buffer gets uninitialized value
by h.b.furuseth＠usit.uio.no 30 Oct '09

30 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard config_tcp_buffer() passes 'idx' uninitialized to tcp_buffer_add_one(). Introduced in rev 1.384 for ITS#6234 (TCP buffer configuration) when !defined(LDAP_TCP_BUFFER_X_ORDERED), then rev 1.388 removed the #ifdef LDAP_TCP_BUFFER_X_ORDERED which could set the value. (Not sure if this needed an ITS -- the code is in 2.4.18/19, but inside #ifdef LDAP_TCP_BUFFER which is #defined if LDAP_DEVEL.)

1 0

(ITS#6355) Uninitialiezed rsa_callback with OpenSSL
by h.b.furuseth＠usit.uio.no 30 Oct '09

30 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD, 2.4.19 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard libldap/tls_o.c:lso_tmp_rsa_cb() returns an uninitialized value if BN_set_word() fails. Introduced in rev 1.13; openldap 2.4.19. Fixing to return NULL.

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by quanah＠zimbra.com 30 Oct '09

30 Oct '09

--On Friday, October 30, 2009 9:44 AM +0100 Pierangelo Masarati <masarati(a)aero.polimi.it> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.19 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> Executing ldapsearch -V to get the version information correctly prints >> it, but then proceeds to execute a search. > > Perhaps it's not clearly documented (no "-V" in man page, unclear message > in help) but you need to use -VV to exit after printing version. That's... bizarre. Even slapd doesn't behave that way. Nor any other program comes immediately to mind. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by masarati＠aero.polimi.it 30 Oct '09

30 Oct '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.19 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > Executing ldapsearch -V to get the version information correctly prints it, but > then proceeds to execute a search. Perhaps it's not clearly documented (no "-V" in man page, unclear message in help) but you need to use -VV to exit after printing version. p.

1 0

Re: ITS#3526 chaining enhancements
by masarati＠aero.polimi.it 30 Oct '09

30 Oct '09

hyc(a)symas.com wrote: > Looks to me like the mentioned features have been implemented and this ITS > should be closed. OK? Not sure, need to check. p.

1 0

ITS#3526 chaining enhancements
by hyc＠symas.com 29 Oct '09

29 Oct '09

Looks to me like the mentioned features have been implemented and this ITS should be closed. OK? -- -- 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#6346) syncrepl problems with 2.4.19
by hyc＠symas.com 29 Oct '09

29 Oct '09

openldap(a)science-computing.de wrote: > Full_Name: Christoph Herrmann > Version: 2.4.19 > OS: SLES11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.17.244.2) > > > > we did some stress tests to an openldap-2.4.19 test infrastructure. > we are running the tests in a single master environment with 5 slave servers, > all with openldap-2.4.19. All machines are running ntpd and are in sync: Thanks for this report, very helpful. A proposed fix for this is now in CVS HEAD overlays/syncprov.c. Please test and let us know your results, thanks. -- -- 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#6340) What should I do it well?
by quanah＠zimbra.com 28 Oct '09

28 Oct '09

Hello, kbind is obsolete, and has been for quite some time. You should be using SASL/GSSAPI instead. In any case, this question is not a bug report, so it does not belong in the ITS system. I would suggest you use the openldap-technical list if you have further questions about developing applications with the OpenLDAP libraries. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6352) Not all certificates are read if the TLS_CACERTDIR contains broken links
by quanah＠zimbra.com 28 Oct '09

28 Oct '09

--On Tuesday, October 27, 2009 8:30 AM +0000 steffen.gruner(a)basf.com wrote: > Full_Name: Steffen Gruner > Version: 2.3.43 The 2.3 release series is no longer supported. I suggest upgrading to the latest stable release (2.4.19) and trying there. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6352) Not all certificates are read if the TLS_CACERTDIR contains broken links
by hyc＠symas.com 28 Oct '09

28 Oct '09

steffen.gruner(a)basf.com wrote: > Full_Name: Steffen Gruner > Version: 2.3.43 > OS: Gentoo Linux > URL: > Submission from: (NULL) (84.171.177.13) > > > If in the TLS_CACERTDIR (/etc/ssl/certs/ on by box) contains broken symbolic > links the ldapsearch command stops on the first broken link and doesn't use all > the other certificates. This functionality is provided by the OpenSSL library; you should file this bug report with them. In the meantime, now you know yet another reason why we recommend using TLS_CACERT instead of TLS_CACERTDIR. -- -- 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#6354) Regex-based authzTo example in docs, section 15.3.3.1, is incorrect.
by tim＠stoo.org 28 Oct '09

28 Oct '09

Full_Name: Tim Stewart Version: 2.4.x OS: N/A URL: Submission from: (NULL) (65.200.62.8) The OpenLDAP documentation at: http://www.openldap.org/doc/admin24/sasl.html#SASL%20Authentication describes an example of using a regular expression to describe a set of distinguished names as opposed to using an ldap:// URL. The example is authzTo: dn.regex=^uid=[^,]*,dc=example,dc=com$ which will produce a syntax error. Instead, the example should read like authzTo: dn.regex:^uid=[^,]*,dc=example,dc=com$ (the first `=' is replaced with `:') which is accepted by the server.

1 0

(ITS#6353) berval->string conversions ignore \0
by h.b.furuseth＠usit.uio.no 28 Oct '09

28 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Conversion from a binary blob (struct berval*, BerElement read) to a char* string typically just grabs bv.bv_val even when the value may contain embedded '\0's. In these cases, correct operation may require that the conversion fails if bv_len != (bv_val ? strlen(bv_val) : 0). Or if bv_val is not \0-terminated, to check if memchr(bv_val, '\0', bv_len) == NULL. Examples: liblber/decode.c: ber_get_stringa, ber_get_stringb, ber_get_bitstringa, ber_scanf "aAv" Similarly, a lot of code requires a berval to be \0-terminated, but some also - sometimes unwarranted - also that the first \0 it encounters when walking the value is the terminating \0. For example, libldap/getdn.c has some exported functions that look for \0 without checking bv_len, some which checks bv_len but not a terminating \0, and some which does both. I really don't know which of these functions can expect there is no embedded \0. I think we need to introduce 'typedef struct berval BerString', used to document that bv_len == (bv_val ? strlen(bv_val) : 0) for the particular berval in question (e.g. in a function prototype). And maybe a typedef BerData for the opposite.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs