Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
matt4 Honored Contributor.
Honored Contributor.
939 views

Fixing SSL Libraries

I have 3 SLES 12 SP4 servers running eDir 9.1.2. On two of them, SSL connections using tools like curl and wget work fine, but on the 3rd server, I get errors like this:

curl https://www.google.com
curl: /opt/novell/lib64/libssl.so.1.0.0: no version information available (required by /usr/lib64/libcurl.so.4)
curl: /opt/novell/lib64/libcrypto.so.1.0.0: no version information available (required by /usr/lib64/libcurl.so.4)
curl: (60) SSL certificate problem: unable to get local issuer certificate

So I did ldd /usr/bin/curl and I see that libssl and libcrypto are pointing at the Novell versions for some reason:

libssl.so.1.0.0 => /opt/novell/lib64/libssl.so.1.0.0 (0x00007fca1f438000)
libcrypto.so.1.0.0 => /opt/novell/lib64/libcrypto.so.1.0.0 (0x00007fca1df34000)

on the working servers, I see this:

libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007fc6d9365000)
libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007fc6d8efe000)


I can't for the life of me figure out how to fix this (no symlinks that I can find, no path issues that I can see). I've force reinstalled the OpenSSL and libopenssl RPMs. I've tried force reinstall eDir too.

I did open an SR, but SuSE supports says it is a NetIQ issue and NetIQ says it is a SuSE issue. Neither has offered much in the way of suggestions to fix this.

There must be a way though to correct this? I figured I'd try here in the eDir forum first.

Short of rebuilding the server, any ideas?

Thanks!

Matt
Labels (1)
0 Likes
9 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Fixing SSL Libraries

Chances are it is a NetIQ issue, and that they do not realize this is
disheartening. Next time, push to get to the backline on the NetIQ side
and they will hopefully point you to TID# 7021958 which has Bug# 1054152
behind it which I reported a couple years ago. As 9.x has become the
norm, this has shown up a bit more, but it's easy to fix: nuke the
ntls.conf file from /etc/ld.so.conf.d/ and then run 'ldconfig' (as 'root')
and that should help.

I can explain the "why" if you really want, but this should never happen
again as that conf file is no longer used.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
matt4 Honored Contributor.
Honored Contributor.

Re: Fixing SSL Libraries

ab;2494348 wrote:
Chances are it is a NetIQ issue, and that they do not realize this is
disheartening. Next time, push to get to the backline on the NetIQ side
and they will hopefully point you to TID# 7021958 which has Bug# 1054152
behind it which I reported a couple years ago. As 9.x has become the
norm, this has shown up a bit more, but it's easy to fix: nuke the
ntls.conf file from /etc/ld.so.conf.d/ and then run 'ldconfig' (as 'root')
and that should help.

I can explain the "why" if you really want, but this should never happen
again as that conf file is no longer used.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.



Actually, I'm well aware of that TID. There is nothing in /etc/ld.so.conf.d on this server.
That is a standard step I do if I do an in-place upgrade to SLES 12, remove ntls.conf and run ldconfig.
I too found this issue a while go too. That TID may have even come from one of my SRs actually!


So this is something different.

There must be a way to just "fix" the linkage to OpenSSL, but I'm not enough of a SuSE guru to figure it out.

So I opened yet another SR on this. Unfortunately, they came right back with the same TID you did.

It's now like my quest to figure out how to fix this without wiping the box. I can't believe there is no way to fix this!

Matt

P.S. Why does support think I don't know how to use Google? 🙂
0 Likes
matt4 Honored Contributor.
Honored Contributor.

Re: Fixing SSL Libraries

matt;2494349 wrote:
Actually, I'm well aware of that TID. There is nothing in /etc/ld.so.conf.d on this server.
That is a standard step I do if I do an in-place upgrade to SLES 12, remove ntls.conf and run ldconfig.
I too found this issue a while go too. That TID may have even come from one of my SRs actually!


So this is something different.

There must be a way to just "fix" the linkage to OpenSSL, but I'm not enough of a SuSE guru to figure it out.

So I opened yet another SR on this. Unfortunately, they came right back with the same TID you did.

It's now like my quest to figure out how to fix this without wiping the box. I can't believe there is no way to fix this!

Matt

P.S. Why does support think I don't know how to use Google? 🙂



Update! I got it.

This TID did send me in the right direction. I started looking around for other files that affect the LD config, and sure enough, there is a file /etc/ld.so.conf. And guess what was in that file?


/usr/local/lib64
/usr/local/lib
include /etc/ld.so.conf.d/*.conf
# /lib64, /lib, /usr/lib64 and /usr/lib gets added
# automatically by ldconfig after parsing this file.
# So, they do not need to be listed.
/opt/novell/lib64



I took the /opt/novell/lib64 out, ran ldconfig -v, and voila! It was fixed.

I can't tell you how many times I looked in /etc/ld.so.conf.d but NEVER thought to look at the conf file itself in etc!! duh!!

Matt
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Fixing SSL Libraries

Well done. Is it safe to assume this system has a different version
history (OS and/or eDirectory) than the others? For example, has it had
older versions of eDirectory on it, or maybe other eDir-related software
(iManager, etc.)?

Sharing the results will likely help others, so thank-you for that too.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Highlighted
matt4 Honored Contributor.
Honored Contributor.

Re: Fixing SSL Libraries

ab;2494353 wrote:
Well done. Is it safe to assume this system has a different version
history (OS and/or eDirectory) than the others? For example, has it had
older versions of eDirectory on it, or maybe other eDir-related software
(iManager, etc.)?

Sharing the results will likely help others, so thank-you for that too.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.


The only difference is that this server we tried to see if we could get VisualClick's DSRazor zero-admin agent to run on this server (which we could not). This was prior to me upgrading it to SLES 12 SP4 (it was SLES 12 SP3 as originally built, w/ eDir 9.1).

Now, in trying to get that agent to work, I did install the OES Cross Platform (XPLAT) Libraries on the server, but later removed them. I guess it is possible they stuck the entry into the ld.so.conf file? It must have been that, because other than eDir and iManager, there are no other Micro Focus/NetIQ products on the box.

Matt
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Fixing SSL Libraries

I would probably bet on the OES side of things. While the ld.so.conf file
will never be a file listed in those packages, if you query the pre or
post-install scripts associated with those packages I would not be
surprised if one of them appended the line to that file:


rpm -q --scripts /path/to/package/here.rpm | grep ld.so.conf


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
matt4 Honored Contributor.
Honored Contributor.

Re: Fixing SSL Libraries

ab;2494358 wrote:
I would probably bet on the OES side of things. While the ld.so.conf file
will never be a file listed in those packages, if you query the pre or
post-install scripts associated with those packages I would not be
surprised if one of them appended the line to that file:


rpm -q --scripts /path/to/package/here.rpm | grep ld.so.conf


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.



I had to add -p because the RPMs are no longer installed, but sure enough, that is where it came from:

rpm -qp --scripts *.rpm |grep ld.so.conf
warning: novell-xplatlib-1.4.3-0.42.14.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 04a29db0: NOKEY
if ! grep /opt/novell/lib64 /etc/ld.so.conf >/dev/null; then
echo "/opt/novell/lib64" >>/etc/ld.so.conf


Mystery solved!

Thanks for the tip! That sucker sure caused me a lot of grief!

Matt
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Fixing SSL Libraries

On 01/25/2019 01:24 PM, matt wrote:
>
> I had to add -p because the RPMs are no longer installed, but sure
> enough, that is where it came from:


Yes, well done; sloppy of me to forget that. Thanks for updating this.
For completeness all in one command:


rpm -q -p --scripts /path/to/package/here.rpm | grep ld.so.conf


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Fixing SSL Libraries

ab;2494348 wrote:
Chances are it is a NetIQ issue, and that they do not realize this is
disheartening. Next time, push to get to the backline on the NetIQ side
and they will hopefully point you to TID# 7021958 which has Bug# 1054152
behind it which I reported a couple years ago. As 9.x has become the
norm, this has shown up a bit more, but it's easy to fix: nuke the
ntls.conf file from /etc/ld.so.conf.d/ and then run 'ldconfig' (as 'root')
and that should help.

I can explain the "why" if you really want, but this should never happen
again as that conf file is no longer used.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.


I tripped over this earlier today. I have a SLES12Sp2 VM that was being managed with SUSE Manager. That was fine.

I took the VM offline for a few months, doing some eDirectory testing for an SR. Installed eDir 9.1 and iManager. Testing is going still.

For other reasons, I needed to bring the VM back on-line and found that it could no longer be managed from SUMA. Zypper not happy, with curl errors. Searching for those turned up:

https://www.suse.com/support/kb/doc/?id=7022161

Using strace, turned up that a non-standard openssl library was being used, which brought me to this thread.

Removed ntls.conf and ran 'ldconfig' and now it works again.

I don't know if ntls.conf came from eDir 9.1 or iManager being installed. Either way, it's annoying, but thanks for the fix.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.