Data Backup and Recovery Discussions

Highlighted

SC 4.1C CLI issue

Trying to use SC 4.1C CLI on SLES11SP2x64 results in the following error messages:

/opt/netapp/scServer4.1.0c/snapcreator --server 127.0.0.1 --port 8443 --user admin --passwd password --profile Novell --config DATA --action backup --policy daily --verbose

500 Can't locate object method "new" via package "LWP::Protocol::https::Socket" at /</opt/netapp/scServer4.1.0c/snapcreator>SnapCreator/Service/Engine.pm line 152

For me it looks like the CLI can't talk to the SC servers SOAP API via SSL. As SSL is new to 4.1 I haven't seen this problem before.

Does anybody know if this is a SC issu or  a problem with the local Perl installation?

20 REPLIES 20
Highlighted

Re: SC 4.1C CLI issue

Hi

This is a known issue we dont ship SSL libraries with CLI binary instead we dynamically link and sometimes the libraries can be linked differently depending on linux style which can create this problem. You need to manually link them.

The requirements for HTTPS for Linux/Unix are as follows:

1) openssl package

2) SSL symlinks

Make sure the following symlinks are located under /usr/lib oder /usr/lib64 (depending on if OS is 64bit or not)

libssl.so.6

libcrypto.so.6

If the symlinks dont exist please cd to /usr/lib or /usr/lib64 and run following command to link them. Make sure what we are linking to is installed, again pre-requisite is openssl so it should be installed first.

ln -sf libssl.so.0.9.8 libssl.so.6

ln -sf libcrypto.so.0.9.8 libcrypto.so.6

Regards,

Keith

Highlighted

Re: SC 4.1C CLI issue

Hi Keith,

thanks for the hint and sorry for the late reply.

I created the symlinks and after that had the problem that the command hangs. strace says:

open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 3

read(3, "0\n", 2)                       = 2

close(3)                                = 0

open("/usr/lib64/.libcrypto.so.6.hmac", O_RDONLY) = -1 ENOENT (No such file or directory)

futex(0x1bac8f8, FUTEX_WAIT_PRIVATE, 2, NULL

I installed libopenssl0_9_8-hmac and created corresponding symlinks but the command still hangs:

open("/lib64/libz.so.1", O_RDONLY)  = 3

read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\"\0\0\0\0\0\0"..., 832) = 832

fstat(3, {st_mode=S_IFREG|0755, st_size=88704, ...}) = 0

mmap(NULL, 2183728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3e2f80f000

fadvise64(3, 0, 2183728, POSIX_FADV_WILLNEED) = 0

mprotect(0x7f3e2f824000, 2093056, PROT_NONE) = 0

mmap(0x7f3e2fa23000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7f3e2fa23000

close(3)                            = 0

mprotect(0x7f3e2fa23000, 4096, PROT_READ) = 0

mprotect(0x7f3e2fd97000, 65536, PROT_READ) = 0

mprotect(0x7f3e30012000, 8192, PROT_READ) = 0

munmap(0x7f3e3001a000, 222534)      = 0
brk(0x1bb9000)                      = 0x1bb9000
brk(0x1be6000)                      = 0x1be6000
mkdir("/tmp/pdk-root/", 0755)       = -1 EEXIST (File exists)

stat("/tmp/pdk-root/29ea4a296c81cb84add64919241a0374/Socket6.so", {st_mode=S_IFREG|0555, st_size=32653, ...}) = 0

open("/tmp/pdk-root/29ea4a296c81cb84add64919241a0374/Socket6.so", O_RDONLY) = 3

read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\32\0\0\0\0\0\0"..., 832) = 832

fstat(3, {st_mode=S_IFREG|0555, st_size=32653, ...}) = 0

mmap(NULL, 1074488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3e2f708000

fadvise64(3, 0, 1074488, POSIX_FADV_WILLNEED) = 0

mprotect(0x7f3e2f70f000, 1044480, PROT_NONE) = 0

mmap(0x7f3e2f80e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f3e2f80e000

close(3)                            = 0

stat("/opt/netapp/scServer4.1.0c/IO/Socket/IP.pmc", 0x7fff0a838ce0) = -1 ENOENT (No such file or directory)

stat("/opt/netapp/scServer4.1.0c/IO/Socket/IP.pm", 0x7fff0a838c40) = -1 ENOENT (No such file or directory)

brk(0x1c08000)                      = 0x1c08000

open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 3

read(3, "0\n", 2)                   = 2
close(3)                            = 0

open("/usr/lib64/.libcrypto.so.6.hmac", O_RDONLY) = 3

close(3)                            = 0

open("/usr/lib64/.libssl.so.6.hmac", O_RDONLY) = 3

close(3)                            = 0

open("/usr/lib64/.libcrypto.so.6.hmac", O_RDONLY) = 3

fstat(3, {st_mode=S_IFREG|0644, st_size=65, ...}) = 0

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3e33524000

read(3, "9c785018d4f2e535d86098da7c39a459"..., 4096) = 65

open("/usr/lib64/libcrypto.so.6", O_RDONLY) = 4

futex(0x1bacaf8, FUTEX_WAIT_PRIVATE, 2, NULL

openssl is version 0.9.8j-0.50.1.  Do you have another hint for me?

Sven

Highlighted

Re: SC 4.1C CLI issue

This thread here is suggesting an upgrade of the openssl package.

http://stackoverflow.com/questions/16035324/perl-lwpuseragent-request-does-not-return-using-http1-1-but-working-fine-using

Could you please try upgrading to openssl-0.9.8r ?

Note: Also for your reference.

http://cpansearch.perl.org/src/GAAS/libwww-perl-5.834/README.SSL

View solution in original post

Highlighted

Re: SC 4.1C CLI issue

Highlighted

Re: SC 4.1C CLI issue

I am seeing this issue running on a RHES 6.4.

The openssl package is: openssl-1.0.0-27.el6_4.2.x86_64

./snapcreator --user scadmin --passwd scadmin --profile r3labdb_db2 --action backupList
500 Can't locate object method "new" via package "LWP::Protocol::https::Socket" at /</r3labdb/soe3/opt/snapdb2-4.0/scServer4.1.0/snapcreator>SnapCreator/Service/Repository.pm line 50

any fix for this coming up?

Highlighted

Re: SC 4.1C CLI issue

This isnt a bug, we dynamically link and linux can link things different even within the same OS. If the links built when you installed openssl are different then what we are looking for you need to do following as is mentioned above:

The requirements for HTTPS for Linux/Unix are as follows:

1) openssl package

2) SSL symlinks

Make sure the following symlinks are located under /usr/lib oder /usr/lib64 (depending on if OS is 64bit or not)

libssl.so.6

libcrypto.so.6

If the symlinks dont exist please cd to /usr/lib or /usr/lib64 and run following command to link them. Make sure what we are linking to is installed, again pre-requisite is openssl so it should be installed first.

ln -sf libssl.so.0.9.8 libssl.so.6

ln -sf libcrypto.so.0.9.8 libcrypto.so.6

In future we may decide to package openssl libs which would mean we arent dynamically linking and thus wouldnt have this issue. Another possibility is we move CLI to java which has much better cross platform support.

Keith

Highlighted

Re: SC 4.1C CLI issue

I do not buy that argument.

We have installed RHEL 6.4 with the openssl that comed with it.

This is supported according to the interoperability matrix.

.

The openssl version you are referring to do not exist in RHEL 6.4

It comeds with openssl-1.0.0-27.el6_4.2.x86_64

Also why do i have to use ssl at all.

We only install SC locally with no access from outside the host.

We do not need it.

Regards Magnus

Highlighted

Re: SC 4.1C CLI issue

SSL is required because the CLI communicates with the SC server over APIs and HTTPS regardless of it it is installed locally or not.

You should create the links so they reflect your SSL version...what is important is that there are libs called:

libssl.so.6

libcrypto.so.6

If not I am afraid it wont work.

keith

Highlighted

Re: SC 4.1C CLI issue

I will test it but this seems to me like a workaround for a bug.

If you claim to support RHEL 6.4 it should work with the openssl that is part of it.

At least I would expect the snapcreator --setup process to warn me about this.

Regards Magnus

Highlighted

Re: SC 4.1C CLI issue

Unfortunately any openssl can be installed and this varies greatly with different Linux releases. Solaris, AIX, HPUX, etc are much tighter on their packaging but certainly this is something we need to improve. As I said this is a known issue in some Linux versions. If this is important to you I would open an NGS case and follow up with support so it gets the appropriate attention.

If the workaround doesnt work let us know

Keith

Highlighted

Re: SC 4.1C CLI issue

I concur - we should get this gets fixed. I would expect an occasional need to create symlinks for libraries when using very old software with a very new OS or vice versa, but the CLI should just work on RHEL6.4

It's not a bug, but it's a definitely problem. This requirement will interfere with scalability. I wouldn't want to have to create custom symlinks on 100 different servers and then deal with ongoing maintenance to put the symlinks back after patching and server rebuilds and such.

I'll submit a bug/RFE report for this.

Highlighted

Re: SC 4.1C CLI issue

Hello,

I´ve the same problem. I can´t start a cli-command, but with GUI it works. The openssl-package is installed, the symlinks created, but it doesn´t work.

The system is a SLES11 SP3, I tried with SnapCreator 4.1.0 and 4.1.0c.

strace -f -o out.txt ./snapcreator --server localhost --port 8443 --user admin --passwd password --profile list --verbose

########## Snap Creator Community Release 4.1.0c Configurations ##########

xxxx:/usr/local/scServer4.1.0c # tail out.txt

17041 open("/usr/lib64/.libssl.so.6.hmac", O_RDONLY) = 3

17041 close(3)                          = 0

17041 open("/usr/lib64/.libcrypto.so.6.hmac", O_RDONLY) = 3

17041 fstat(3, {st_mode=S_IFREG|0644, st_size=65, ...}) = 0

17041 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3a65e4f000

17041 read(3, "9c785018d4f2e535d86098da7c39a459"..., 4096) = 65

17041 open("/usr/lib64/libcrypto.so.6", O_RDONLY) = 4

17041 futex(0x1b9aa28, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted)

17041 --- SIGINT (Interrupt) @ 0 (0) ---

17041 +++ killed by SIGINT +++

Regrads

V. Albrecht

Highlighted

Re: SC 4.1C CLI issue

Any news on this issue? 4.1p1 solved it?

Or is it time to descide that Snapcreator is not an Enterprise solution and look at other solutions?

Highlighted

Re: SC 4.1C CLI issue

Magnus,

Snap Creator 4.1P1 does not include a fix for this, but we agree it needs to be resolved.

Jeff entered BURT 798649 and RFE for this issue and it is currently scheduled for SC 4.2.

Thanks,

John

Highlighted

Re: SC 4.1C CLI issue

Great news. Then we will wait and stay on v3.6p1 until then.

Do you know when 4.2 are tergeted for a release?

Regards Magnus

Check out the KB!
NetApp Insights To Action
All Community Forums