Greetings:
Good point about the Sun version of openssl.
Using the -s option of ldd, did indeed point out that the amandabackup user had
no LD_LIBRARY_PATH environment variable set. I've added that and now, when I
run selfcheck manually from the /usr/local/libexec/amanda directory, it no
longer throws an error. In fact, on all five servers that command now just sits
there, maybe that's normal. However, the two failing servers continue to fail
with the exact same error message. Nuts, I'd hoped this would change that!
I'm assuming that when amcheck is run on the amanda server, the scripts are run
as amandabackup, the amanda user, on the client. Does this get executed with a
somewhat restricted environment that bypasses the .profile script, in this case?
Thanks!
Neil
On 2012.01.12 9:53 AM, Chris Hoogendyk wrote:
Just a quick note in support of the Sun version of openssl -- although the
version is slightly old on the face of it, it has been patched for many of the
more recent security notices (see `openssl version` [note no minus or double
minus in front of version] ). Also, if you happen to be on a server with a T2
or newer CPU, the Sun version is compiled to take advantage of the on chip
encryption accelerators (one per core). So, linking with the Sun version gets
you that performance boost, while replacing it with a third party version
loses it.
Use a "-s" on the ldd. That will display the search path it used to find the
dependencies. Altogether possible that your shell environment provides library
path information that is not available when running automatically. Then you
might use crle to set a universal directive for finding libraries.
On 1/12/12 9:37 AM, Neil Carter wrote:
Greetings:
Apparently not. It appears than a Solaris version of openssl is installed,
SUNWopenssl, instead. This is working fine on three other Solaris 10 servers.
Since the Solaris version is installed, I really don't want to introduce a
third-party version.
The interesting thing is that when I ran the ldd syntax on all five of my
Solaris 10 servers, only two of the five list that file, and they are the
ones that are failing. They all use the same dumptype, which calls for the
encryption to be done on the amanda server, not the client.
More ideas?
Thanks!
Neil
On 2012.01.12 4:59 AM, Jean-Louis Martineau wrote:
Neil,
Add libcrypto.so.0.9.7 on the solaris client.
The article says to install the openssl-rt package (CSWosslrt), do you have
this package installed?
Jean-Louis
On 01/11/2012 08:37 PM, Neil Carter wrote:
Greetings:
I found the article 361http://network.zmanda.com/lore/article.php?id=361
and it
seemed to fit perfectly, as I get the same error:
Amanda Backup Client Hosts Check
--------------------------------
WARNING: horus-iflex: selfcheck request failed: tcpm_recv_token: invalid size:
"ld.so.1: amandad: fatal: libcrypto.so.0.9.7: open failed: No such file or
directory\n" Client check: 1 host checked in 0.042 seconds. 1 problem found.
However, upon checking, it looks like the client DOES have the OpenSSL
installed:
root@horus-iflex# pkginfo|grep ssl
system SUNWopenssl-commands OpenSSL Commands (Usr)
system SUNWopenssl-include OpenSSL Header Files
system SUNWopenssl-libraries OpenSSL Libraries (Usr)
system SUNWopenssl-man OpenSSL Manual Pages
system SUNWopensslr OpenSSL (Root)
root@horus-iflex#
Yes, this is a Sun SPARC client, Solaris 10. The Amanda server is on Linux,
and
it's Amanda 3.3.0.
The libcrypto.so.0.9.7 file DOES exist on the server in two separate
locations. Can someone tell me where amanda wants to find it?
Am I reading this wrong? Any other suggestions?
Thanks!
Neil
