Some users of Solaris may use LDAP clients based on the library /usr/lib/libsldap.so.1. One such example is the Sun-provided /usr/lib/nss_ldap.so.1. These clients have historically been at best partially compatible with OpenLDAP, for various reasons. While there has been a lot of good progress towards standards compliance (or at least standards accommodation), paged results have had a long-standing bug. The results cookie was improperly handed by libsldap, causing any results in excess of the page size (1,000 in the case of libsladp) to be lost.
Rutgers has significantly more than 1,000 entries, and brought this through Sun support channels. Patches were released for Solaris 9 last week, which fix this issue
6278068 native ldap client: simple page mode broken in S9 and S10
I note this to openldap-software for users considering migration to OpenLDAP slapd(8) who may have experienced this behavior and falsely attributed it to OpenLDAP software. When properly patched, I can attest that Solaris nss and OpenLDAP work "out of the box" together.
On Wednesday 14 February 2007 11:17, Aaron Richton wrote:
Some users of Solaris may use LDAP clients based on the library /usr/lib/libsldap.so.1. One such example is the Sun-provided /usr/lib/nss_ldap.so.1. These clients have historically been at best partially compatible with OpenLDAP, for various reasons. While there has been a lot of good progress towards standards compliance (or at least standards accommodation), paged results have had a long-standing bug. The results cookie was improperly handed by libsldap, causing any results in excess of the page size (1,000 in the case of libsladp) to be lost.
Rutgers has significantly more than 1,000 entries, and brought this through Sun support channels. Patches were released for Solaris 9 last week, which fix this issue
6278068 native ldap client: simple page mode broken in S9 and S10
I note this to openldap-software for users considering migration to OpenLDAP slapd(8) who may have experienced this behavior and falsely attributed it to OpenLDAP software. When properly patched, I can attest that Solaris nss and OpenLDAP work "out of the box" together.
Do you also know whether they released a patch for S10?
BTW, just for the record, the patch number for S9 is 112960-45.
Karsten.
I do not know if they released for S10; you'd be better off asking Sun.
On Wed, 14 Feb 2007, Karsten Künne wrote:
On Wednesday 14 February 2007 11:17, Aaron Richton wrote:
Some users of Solaris may use LDAP clients based on the library /usr/lib/libsldap.so.1. One such example is the Sun-provided /usr/lib/nss_ldap.so.1. These clients have historically been at best partially compatible with OpenLDAP, for various reasons. While there has been a lot of good progress towards standards compliance (or at least standards accommodation), paged results have had a long-standing bug. The results cookie was improperly handed by libsldap, causing any results in excess of the page size (1,000 in the case of libsladp) to be lost.
Rutgers has significantly more than 1,000 entries, and brought this through Sun support channels. Patches were released for Solaris 9 last week, which fix this issue
6278068 native ldap client: simple page mode broken in S9 and S10
I note this to openldap-software for users considering migration to OpenLDAP slapd(8) who may have experienced this behavior and falsely attributed it to OpenLDAP software. When properly patched, I can attest that Solaris nss and OpenLDAP work "out of the box" together.
Do you also know whether they released a patch for S10?
BTW, just for the record, the patch number for S9 is 112960-45.
Karsten.
Well, here it is, 1983, so it won't be long before you start reading a lot of boring stories about people like Vance Hartke. Hartke is a governor or mayor or something from one of the flatter states, and the reason you'll be reading about him is that he's one of the 50 top contenders for the 1984 Democratic presidential nomination. These men will spend the next 18 months going around the country engaging in the most degrading activities imaginable, such as wearing idiot hats and appearing on "Meet the Press". "Meet the Press" is one of those Sunday morning public interest shows that the public is not the least bit interested in. It features a panel of reporters who ask questions of a guest politician, who wins an Amana home freezer if he can get through the entire show without answering a single question ... -- Dave Barry, "On Presidential Politics"
I am having a few issues getting openldap-2.3.34 to build in solaris 10 x86.
The first issues is the order of the include files basically anywhere <avl.h> is included it is picking up /usr/include/sys/avl.h instead of the openldap avl.h library. You can pretty much just grep for <avl.h> or "avl.h" and find all the places it conflicts.
The real trick here is I think it is netdb.h requires sys/avl.h
second in portable.h /* Define to `int' if <sys/socket.h> does not define. */ #define socklen_t int
This should be commented out it is defined as: typedef size_t socklen_t; typedef uint32_t socklen_t; in <sys/socket.h>
Third. and I didnt document all the places but #include <netdb.h> isnt being included.. libraries/libldap/os-local.c libraries/libldap/util-int.c libraries/libldap_r/os-local.c libraries/libldap/os-ip.c
Fourth:
/opt/dloads/openldap-2.3.34/servers/slapd/slap.h needs to include #include <sys/socket.h>
Just one nitpick. include/lber_types.hin include/ldap_config.hin include/ldap_features.hin include/portable.hin
arent these usually called x.h.in ? --
Im not sure I caught all the places.. for the netdb.h and sys/socket.h includes.
It still isnt building completely because of the avl.h stuff.
-------------------------------------- Sean O'Malley, Information Technologist Michigan State University -------------------------------------
Sean O'Malley wrote:
I am having a few issues getting openldap-2.3.34 to build in solaris 10 x86.
The first issues is the order of the include files basically anywhere <avl.h> is included it is picking up /usr/include/sys/avl.h instead of the openldap avl.h library. You can pretty much just grep for <avl.h> or "avl.h" and find all the places it conflicts.
This has been reported before in the ITS. I haven't seen this problem, but I've only been building on Solaris 10 for Sparc. Strange that such a thing would be architecture-specific. Also, unless something is broken in your compiler, the order of include-flag processing should mean that OpenLDAP's avl.h is located first.
The real trick here is I think it is netdb.h requires sys/avl.h
second in portable.h /* Define to `int' if <sys/socket.h> does not define. */ #define socklen_t int
This should be commented out it is defined as: typedef size_t socklen_t; typedef uint32_t socklen_t; in <sys/socket.h>
Third. and I didnt document all the places but #include <netdb.h> isnt being included.. libraries/libldap/os-local.c libraries/libldap/util-int.c libraries/libldap_r/os-local.c libraries/libldap/os-ip.c
<netdb.h> should not be included in any source files at all since it's part of <ac/socket.h>.
Fourth:
/opt/dloads/openldap-2.3.34/servers/slapd/slap.h needs to include #include <sys/socket.h>
No, it already includes <ac/socket.h>.
Sean O'Malley wrote:
I am having a few issues getting openldap-2.3.34 to build in solaris 10 x86.
The first issues is the order of the include files basically anywhere <avl.h> is included it is picking up /usr/include/sys/avl.h instead of the openldap avl.h library. You can pretty much just grep for <avl.h> or "avl.h" and find all the places it conflicts.
There's a Sun bugid out there somewhere about avl.h spamming the user namespace.
To work around the issue, here's an excerpt from my notes on how I build OpenLDAP 2.3.xx on Solaris 10 x86:
cd build/openldap-2.3.xx ../runconfigure.openldap make depend /bin/env LTCFLAGS="-xtarget=native -xarch=amd64 -D_AVL_H" dmake -j 4 su PATH=${PATH}:/usr/ccs/bin make install ln -s /opt/openldap-2.3.xx /opt/openldap
Here's the contents of "runconfigure.openldap". It assumes that a 64-bit version of Berkeley database (another interesting hassle with 4.2.52+patches) is in /opt/db and uses OpenSSL from /usr/sfw. Oh yeah, had to build my own libtool too.
#!/bin/ksh
vers=$(basename $PWD) pfx="/opt/${vers}" echo "Using prefix '$pfx'" # can't use -fast or -xarch=amd64a: compiler bug
/bin/env CC=cc CXX=CC \ CFLAGS="-xtarget=native -xarch=amd64 -D_AVL_H" \ CPPFLAGS="-I/usr/sfw/include -I/opt/db/include -I/opt/libtool/include" \ LDFLAGS="-L/usr/sfw/lib/amd64 -L/opt/db/lib -L/opt/libtool/lib -R/usr/sfw/lib/amd64:/opt/db/lib:/opt/libtool/lib" \ ./configure \ --prefix=${pfx} \ --enable-dynamic \ --enable-syslog \ --enable-proctitle \ --enable-local \ --enable-slapd \ --enable-crypt \ --enable-modules \ --enable-rewrite \ --enable-bdb=yes \ --enable-hdb=yes \ --enable-ldap=mod \ --enable-meta=mod \ --enable-monitor=mod \ --enable-null=mod \ --enable-relay=mod \ --enable-overlays=mod \ --with-tls
Once all the hassle of compiling is over, OpenLDAP works great on our Sun x4200s.
-Ben
I wrote:
The first issues is the order of the include files basically anywhere <avl.h> is included it is picking up /usr/include/sys/avl.h instead of the openldap avl.h library. You can pretty much just grep for <avl.h> or "avl.h" and find all the places it conflicts.
There's a Sun bugid out there somewhere about avl.h spamming the user namespace.
BugID: 6419029 http://bugs.opensolaris.org/view_bug.do?bug_id=6419029
Fix should be in patch 118855-36 but I haven't verified that yet.
-Ben
--On Sunday, April 01, 2007 10:19 PM -0400 Benjamin Lewis bhlewis@purdue.edu wrote:
Sean O'Malley wrote:
I am having a few issues getting openldap-2.3.34 to build in solaris 10 x86.
The first issues is the order of the include files basically anywhere <avl.h> is included it is picking up /usr/include/sys/avl.h instead of the openldap avl.h library. You can pretty much just grep for <avl.h> or "avl.h" and find all the places it conflicts.
There's a Sun bugid out there somewhere about avl.h spamming the user namespace.
To work around the issue, here's an excerpt from my notes on how I build OpenLDAP 2.3.xx on Solaris 10 x86:
cd build/openldap-2.3.xx ../runconfigure.openldap make depend /bin/env LTCFLAGS="-xtarget=native -xarch=amd64 -D_AVL_H" dmake -j 4 su PATH=${PATH}:/usr/ccs/bin make install ln -s /opt/openldap-2.3.xx /opt/openldap
Here's the contents of "runconfigure.openldap". It assumes that a 64-bit version of Berkeley database (another interesting hassle with 4.2.52+patches) is in /opt/db and uses OpenSSL from /usr/sfw. Oh yeah, had to build my own libtool too.
# !/bin/ksh
vers=$(basename $PWD) pfx="/opt/${vers}" echo "Using prefix '$pfx'" # can't use -fast or -xarch=amd64a: compiler bug
/bin/env CC=cc CXX=CC \ CFLAGS="-xtarget=native -xarch=amd64 -D_AVL_H" \ CPPFLAGS="-I/usr/sfw/include -I/opt/db/include -I/opt/libtool/include" \ LDFLAGS="-L/usr/sfw/lib/amd64 -L/opt/db/lib -L/opt/libtool/lib -R/usr/sfw/lib/amd64:/opt/db/lib:/opt/libtool/lib" \ ./configure \ --prefix=${pfx} \ --enable-dynamic \ --enable-syslog \ --enable-proctitle \ --enable-local \ --enable-slapd \ --enable-crypt \ --enable-modules \ --enable-rewrite \ --enable-bdb=yes \ --enable-hdb=yes \ --enable-ldap=mod \ --enable-meta=mod \ --enable-monitor=mod \ --enable-null=mod \ --enable-relay=mod \ --enable-overlays=mod \ --with-tls
Once all the hassle of compiling is over, OpenLDAP works great on our Sun x4200s.
Just to note, I found that Linux 2.6 is faster than Solaris 10 on Sun's 4X00 servers. So if you support Linux as well as Solaris, its a reason not to use Solaris. ;) I use the X4100's as my production boxes, using Debian 64-bit.
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
openldap-software@openldap.org
-
Aaron Richton -
Benjamin Lewis -
Howard Chu -
Karsten Künne -
Quanah Gibson-Mount -
Sean O'Malley