On Thu, Aug 28, 2008 at 12:45 AM, Howard Chu hyc@symas.com wrote:

Nicholas Dronen wrote:

...

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?

OpenLDAP's libldap has supported poll() since 2004. Whatever you're working with is far out of date. As stated here http://www.openldap.org/devel/contributing.html we only accept patches against current code. http://www.openldap.org/project/

Hi, Howard:

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@sys-net.itwrote:

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?

Regards,

Nick

--On Thursday, August 28, 2008 8:04 AM -0600 Nicholas Dronen ndronen@gmail.com wrote:

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.

Basing the OpenLDAP *server* you run on based on the version of OpenLDAP in RedHat is an extremely flawed and broken approach, that will only open yourself to heartache. Their RPM's are years out of date, and missing critical fixes. You need to understand that the OpenLDAP included in their release is to provide the client API, not a stable OpenLDAP server. For that, you need to use up to date versions of OpenLDAP. Buchan Milne provides pre-built RPMs for RedHat, and Symas Corp provides prebuilt builds of OpenLDAP that support can be purchased for. Either of those options are thousands of times more desirable than what RedHat ships.

Buchan's stuff: http://staff.telkomsa.net/packages/ Symas's stuff: http://www.symas.com/

FAQ entry you should read: http://www.openldap.org/faq/data/cache/1456.html

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

On Thu, Aug 28, 2008 at 9:32 AM, Luca Scamoni luca.scamoni@sys-net.itwrote:

Nicholas Dronen wrote:

...

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.

I would say you're at the mercy of redhat 'cause you want to. You are free to package your own version of openldap and install it on your system without losing support from RH as long as it doesn't interfere with RH existing packages. We deploy our own openldap rpm to our customers. It installs in /opt/ldap, is up-to-date with recommened versions of openssl, cyrus-sasl, berkeleydb and anything else it could need (it's latest OpenLDAP, of course), has its own init script, man pages and so on. So it's up to you...

Hi, Luca:

I agree that it's up to us. We are, for example, going to include our own version of OpenLDAP in our current release to work around the problem with select(). In our next release, we're going to be using syncrepl, and we plan to use a more recent version of OpenLDAP than the one included in RedHat EL 5.2. But take it to the other extreme. If a person always upgraded every package in a vendor's distribution just because the vendor was horribly backlevel, they might as well maintain their own distribution, which just isn't worth it. Keep in mind that we distribute an entire distribution on the appliance, so it's not just OpenLDAP we have to care about.

That being said, this is tangential to the original question, and I have 120 more pages of a requirements document to finish today, so I have to leave off here.

Regards,

Nick