DNS on Linux presentation

Here is my DNS on Linux presentation I gave just over a year ago at LinuxFest Northwest.
How nice that I can embed it in my blog, thanks to Slideshare.

| View | Upload your own

libmap.conf to the rescue!

Tonight I found myself tripped up by the dreaded "shared object not found" message on my FreeBSD server 'sonar'. See, I upgraded from 6.3-REL to 7.0-REL recently and in doing so, broke probably every port that had been installed prior. In this instance, my nagios plugin(s) were not working.

root@sonar:/tmp>/usr/local/libexec/nagios/check_smtp -H sonar
/libexec/ld-elf.so.1: Shared object "libssl.so.4" not found, required by "check_smtp"

Here's the deal, whenever FreeBSD releases a new version they bump the library version numbers as a matter of course. So there may be little to no fundamental difference between libcrypto.so.4 libcrypto.so.5. Or maybe there is. That's why this is risky... but what have I got to lose?

Cut to the chase... if ldd /path/to/binary reveals one or more libraries that aren't found, it can be time for entries in /etc/libmap.conf (instead of the safer/slower choice of rebuilding the port providing said binary).

/usr/local/libexec/nagios/check_smtp:
        libssl.so.4 => not found (0x0)
        libcrypto.so.4 => not found (0x0)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x40746000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x40852000)
        libc.so.6 => not found (0x0)
        libc.so.7 => /lib/libc.so.7 (0x40956000)

By using `locate libssl.so` and variants I was able to see that the libraries were in fact available, only the versions had been incremented. Here are the libmap.conf entries I created.

libssl.so.4     libssl.so.5
libcrypto.so.4  libcrypto.so.5
libc.so.6       libc.so.7

Now my program is fixed.

root@sonar:/tmp>/usr/local/libexec/nagios/check_smtp -H sonar
SMTP OK - 0.072 sec. response time|time=0.071886s;;;0.000000