Darren J Moffat wrote:
> [ Yeah Yet Another Ldap Library :-) The more the merrier! ]
>
> Is it possible to put the schema in /usr/share somewhere eg:
> /usr/share/openldap/schema/. Not a big issue just seems that they
> shouldn't need to be edited.
The schema files are not static in the sense of "these will never change"
They are static in the sense of a LDAP server administrator "should not
modify these unless they really know what they are doing."
The schema files in /etc/openldap/schema are loaded via include
statements during the initialization phase via the slapd.conf configuration
file.
Server administrators need to be able [and do] to modify, add and potentially
delete some schemas as part of the configuration setup for the server.
>
> While I see that the prefix of "o" means Open it reads as
> old-apadd, old-apcompare old-adppasswd. Also given the ancient precent
> of awk, owak, nawk. Maybe just make the prefix "open" (for the
> commands and the man page sections) since that is already used in
> /usr/share/doc/openldap/ giving:
>
> openldapadd, openldapcompare, openldappasswd etc.
>
> It may also be useful, but I wouldn't inst on it to have
> /usr/lib/openldap/bin/{ldapadd,ldapcompare,ldappasswd,...} this would
> allow scripts written to assume OpenLDAP clis to be more easily adapted
> to OpenSolaris/Solaris by changing $PATH rather than having to change
> every instance of ldapadd etc to the prefixed name.
We are willing to adjust the names of the tools from o* to open* and adding a
second directory [/usr/lib/openldap/bin] of symlinks as suggested above if
that is the consensus of PSARC? If so I will revise the spec.
>
> What is the rationale for starting slapd with root and all privs rather
> than having SMF start it as openldap:openldap with basic,net_privaddr ?
It seemed the simple solution. I will revise the spec, correct the SMF
manifest,
and retest etc.
>
> The library naming looks strange but as the case says this is what is
> used elsewhere, what is recorded as the SONAME in the ELF files ?
The history, as I understand it, is that OpenLDAP 2.3.x use libldap.so.2.3.*
[and the default name of libldap.so]. Some Linux's still distribute both
libldap.2.3.* and the newer libldap.2.4 forms. The default name was
changed so that both libraries can exist parallel on Linux boxes. It
just happens to work for us (OpenSolaris) as well, but for a different reason.
[Mozilla vs. OpenLDAP.2.4...]
The SONAMES from the libraries are:
$ dump -Lvp libldap-2.4.so.2.1.0|grep SONAME
[11] SONAME libldap-2.4.so.2
$ dump -Lvp libldap_r-2.4.so.2.1.0|grep SONAME
[11] SONAME libldap_r-2.4.so.2
>
> Can this OpenLDAP server be used as the LDAP *server* for nss_ldap and
> pam_ldap ? If so can instructions for configuring it be provided
> somewhere (ideally in /usr/share/doc/openldap but I'd accept
> wikis.sun.com, opensolaris.org or blogs.sun.com initially). If it
> doesn't work I'd like to see a short outline of what is needed to make
> it so.
Yes, it can. At the moment Google has multiple references. Some are:
http://docs.alkaloid.net/index.php/Solaris_LDAP_client_with_OpenLDAP_server
http://www.bolthole.com/solaris/LDAP.html
http://docs.lucidinteractive.ca/index.php/Solaris_LDAP_client_with_OpenLDAP_server
...
As part of this projects testing we are testing nss_ldap against the OpenLDAP
builds with the intent of publishing our own set of instructions to
opensolaris.org
(probably the Sparks project) with relevant blog pointers, and in order to
gather
the list of issues for additional improvements.
One of those future tasks includes making the necessary modifications
to nss_ldap to make OpenLDAP setup easier, and needed changes to idsconfig
so that idsconfig can configure both SJS DSEE and OpenLDAP slapd.
[Side note, when we change idsconfig, we expect pull out the inline
schema code and place it in a previously suggested shared location.
The expectation would be to update the LDAP admin guide with additional
new instructions as part of these idsconfig enhancements. We expect to submit a
fast track for this work once it is further along.
>
> I don't want it to stop the integration of this case but having the
> existing /usr/lib/ldap.so.5 from Mozilla and the OpenLDAP library in the
> same process is *highly* toxic and leads to very strange and hard to
> debug problems - particularly when using LDAP over SSL/TLS. So I'd
> encourage the projects teams management to fund the switch to OpenLDAP
> for libsldap and nss_ldap ASAP.
We are currently investigating the conversion of nss_ldap/libsldap to OpenLDAP.
Additionally, OpenSolaris and s10u4+ are currently integrated with the sparks
enhancements to the name service switch (PSARC/2005/133).
By design, in sparks when nscd is running, the only application that should ever
load nss_ldap is nscd. Currently all LDAP processing is managed by nscd.
This LDAP processing includes connection pooling and shared connections of
multiple requests/responses over those managed connections.
Given that nscd/nss_ldap/libldap.so.5 are all built in a controlled environment
w/ -Bdirect, nscd already properly loads with the correct libraries. This
greatly
reduces the possibility of a collision due to naming services linkage issues.
In general any application linking with a libldap today, should no longer have
library collisions due to the nsswitch's use of libldap.
>
> --
> Darren J Moffat
