I’m working on a new FRS-3.0.13 config, and started getting errors from raddebug along the lines of "TLS: could not shutdown NSS…”. I remembered seeing some comments in the config files which suggested NSS resulted in fiery explosions and potential loss of limbs. A quick google search on the error messages turned up a few forum posts mentioning the exact messages I was getting, and even a link to some wiki commentary about the problem (and more mention of bad juju). http://wiki.freeradius.org/modules/Rlm_ldap#errors-with-ldap-over-tls-connec... Printing the shared library dependencies revealed the following: $ ldd /usr/lib64/libldap* | grep ssl libssl3.so => /lib64/libssl3.so (0x00007fefd95ea000) libssl3.so => /lib64/libssl3.so (0x00007f2df88bb000) libssl3.so => /lib64/libssl3.so (0x00007f3192055000) libssl3.so => /lib64/libssl3.so (0x00007fd99a617000) libssl3.so => /lib64/libssl3.so (0x00007f8bb0703000) libssl3.so => /lib64/libssl3.so (0x00007fb6b917c000) $ ldd /usr/lib64/libssl3.so linux-vdso.so.1 => (0x00007fff3abf6000) libnss3.so => /lib64/libnss3.so (0x00007f25c5a5b000) --> libnssutil3.so => /lib64/libnssutil3.so (0x00007f25c582e000) libplc4.so => /lib64/libplc4.so (0x00007f25c5629000) libplds4.so => /lib64/libplds4.so (0x00007f25c5425000) libnspr4.so => /lib64/libnspr4.so (0x00007f25c51e6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f25c4fca000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f25c4dc6000) libc.so.6 => /lib64/libc.so.6 (0x00007f25c4a04000) libz.so.1 => /lib64/libz.so.1 (0x00007f25c47ee000) librt.so.1 => /lib64/librt.so.1 (0x00007f25c45e6000) /lib64/ld-linux-x86-64.so.2 (0x00007f25c5fd0000) I could set lifetimes and timeouts for the ldap connections to zero, but that doesn’t really solve the problem. I’m still mastering the Linux environment, but I imagine that I could install libldap from source, compile it to use openssl, give it a new prefix, and then have FR use that library without conflicting with the rest of the system?? Am I on the correct path here? Has anyone here done something like this? ======================= Mark Williams markhw@vt.edu (2A83CAC8)
Yep. Build openldap from source. Installing to eg /usr/local so it doesn't interfere with the district . Then compile FR using that local copy of libs/includes etc. alan On 21 Apr 2017 11:24 pm, "Mark Williams" <markhw@vt.edu> wrote:
I’m working on a new FRS-3.0.13 config, and started getting errors from raddebug along the lines of "TLS: could not shutdown NSS…”. I remembered seeing some comments in the config files which suggested NSS resulted in fiery explosions and potential loss of limbs. A quick google search on the error messages turned up a few forum posts mentioning the exact messages I was getting, and even a link to some wiki commentary about the problem (and more mention of bad juju).
http://wiki.freeradius.org/modules/Rlm_ldap#errors-with- ldap-over-tls-connections
Printing the shared library dependencies revealed the following:
$ ldd /usr/lib64/libldap* | grep ssl libssl3.so => /lib64/libssl3.so (0x00007fefd95ea000) libssl3.so => /lib64/libssl3.so (0x00007f2df88bb000) libssl3.so => /lib64/libssl3.so (0x00007f3192055000) libssl3.so => /lib64/libssl3.so (0x00007fd99a617000) libssl3.so => /lib64/libssl3.so (0x00007f8bb0703000) libssl3.so => /lib64/libssl3.so (0x00007fb6b917c000)
$ ldd /usr/lib64/libssl3.so linux-vdso.so.1 => (0x00007fff3abf6000) libnss3.so => /lib64/libnss3.so (0x00007f25c5a5b000) --> libnssutil3.so => /lib64/libnssutil3.so (0x00007f25c582e000) libplc4.so => /lib64/libplc4.so (0x00007f25c5629000) libplds4.so => /lib64/libplds4.so (0x00007f25c5425000) libnspr4.so => /lib64/libnspr4.so (0x00007f25c51e6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f25c4fca000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f25c4dc6000) libc.so.6 => /lib64/libc.so.6 (0x00007f25c4a04000) libz.so.1 => /lib64/libz.so.1 (0x00007f25c47ee000) librt.so.1 => /lib64/librt.so.1 (0x00007f25c45e6000) /lib64/ld-linux-x86-64.so.2 (0x00007f25c5fd0000)
I could set lifetimes and timeouts for the ldap connections to zero, but that doesn’t really solve the problem. I’m still mastering the Linux environment, but I imagine that I could install libldap from source, compile it to use openssl, give it a new prefix, and then have FR use that library without conflicting with the rest of the system?? Am I on the correct path here? Has anyone here done something like this?
======================= Mark Williams markhw@vt.edu (2A83CAC8)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On 21 Apr 2017, at 18:57, Alan Buxey <alan.buxey@gmail.com> wrote:
Yep. Build openldap from source. Installing to eg /usr/local so it doesn't interfere with the district . Then compile FR using that local copy of libs/includes etc.
Or use the LDAP Tool Box project packages, then upgrading is much simpler. -Arran
On Apr 21, 2017 7:00 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
On 21 Apr 2017, at 18:57, Alan Buxey <alan.buxey@gmail.com> wrote:
Yep. Build openldap from source. Installing to eg /usr/local so it doesn't interfere with the district . Then compile FR using that local copy of libs/includes etc.
Or use the LDAP Tool Box project packages, then upgrading is much simpler. -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list /users.html Well, I already have a custom install of OpenLDAP. In fact, I just wrote an Ansible play to handle that for me and specify --with-tls=openssl . I don't remember seeing such an option for FreeRADUS. How would I get FR to compile with those libraries as well?
On Apr 21, 2017, at 7:15 PM, Mark Williams <markhw@vt.edu> wrote:
Well, I already have a custom install of OpenLDAP. In fact, I just wrote an Ansible play to handle that for me and specify --with-tls=openssl . I don't remember seeing such an option for FreeRADUS. How would I get FR to compile with those libraries as well?
The long answer is "linker magic". :( The short answer is that it's safest to ensure there's only ONE version of libldap on the system when you build it. Then, do: $ ./configure --with-rlm-ldap-lib-dir=LIBDIR --with-rlm-ldap-include-dir=INCDIR Where LIBDIR and INCDIR are the actual paths to the libraries and header files. It's generally best to do builds like this on a dedicated build VM. It should be the same base OS as the production VM, but with no production software installed. That way you're sure it's linking to the right thing. Then, ensure that the production system has the same libldap in the same location as the build VM. It should just work. Alan DeKok.
participants (4)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Mark Williams