Hi: I work on a commercial server application, a gateway, which uses pam_ldap to authenticate users in some situations. As a server application, it can easily exceed the 1024 default file descriptor limit of select(2), which has bitten us recently. Since the server application ships in an appliance, we can provide a patch in the form of an OpenLDAP RPM that's been recompiled with -DOPENLDAP_FD_SETSIZE. That fixes the immediate problem for us, but would you be willing to accept a patch to libldap that gave developers a programmatic way to use poll or epoll instead of having to recompile?

That's good news. We're currently using OpenLDAP 2.2.13, which is the version included in RedHat EL 4.6. (RedHat is apparently quite conservative in the versions of the packages they include in their distribution.) The next release of our product will run on RedHat EL 5.x, which comes with OpenLDAP 2.3.27, so we should be okay in the long run.

The motivation for my question about the patch was, of course, simply that we would like not to have to recompile OpenLDAP for every *future* version of our product. Naturally, in the short term we would recompile and rebuild the RPM and send it to our customers. In any case, it's great to hear that the newer versions of libldap use poll already, so we just have to recompile and rebuild the RPM for our current release. Thanks for your help! Regards, Nick

On Thu, Aug 28, 2008 at 7:45 AM, Pierangelo Masarati <ando(a)sys-net.it&gt;wrote: > Nicholas Dronen wrote: > > That's good news. We're currently using OpenLDAP 2.2.13, which is the >> version included in RedHat EL 4.6. (RedHat is apparently quite >> conservative >> in the versions of the packages they include in their distribution.) The >> next release of our product will run on RedHat EL 5.x, which comes with >> OpenLDAP 2.3.27, so we should be okay in the long run. >> > Sort of: 2.3 is now at 2.3.43, with a quite long list of bugfixes (~500? > not to mention new useful features). Hi, Pierangelo: Unfortunately, we're more or less at the mercy of Red Hat when it comes to the versions of packages that are included in their distribution. We use a commercial version, not Fedora, for support reasons. In this particular case, the fact that we were exceeding the default limit of 1024 file descriptors for select(2) resulted in pam_authenticate blocking for up to four minutes, which is a huge problem in a production system, enough to justify including a rebuilt RPM. Generally, JPam's use of libldap is pretty simple -- just enough to bind and authenticate a user -- so as long as that basic functionality works as desired, we should be okay with 2.3.27. :-) If we're not, then we'll have to include our own RPM. That being said, where can I view the list of bug fixes that are in 2.3.43?

Hi, Pierangelo: Unfortunately, we're more or less at the mercy of Red Hat when it comes to the versions of packages that are included in their distribution. We use a commercial version, not Fedora, for support reasons. In this particular case, the fact that we were exceeding the default limit of 1024 file descriptors for select(2) resulted in pam_authenticate blocking for up to four minutes, which is a huge problem in a production system, enough to justify including a rebuilt RPM. Generally, JPam's use of libldap is pretty simple -- just enough to bind and authenticate a user -- so as long as that basic functionality works as desired, we should be okay with 2.3.27. <http://2.3.27.> :-) If we're not, then we'll have to include our own RPM.