SC 4.1C CLI issue

[sbuechsenschuetz]

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?

[ktenzer]

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

[sbuechsenschuetz]

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

[sivar · Accepted solution]

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

[sbuechsenschuetz]

Using openssl 0.9.8r from http://download.opensuse.org/repositories/security:/fips/SLE_11_SP1/x86_64/ works.

[volker_albrecht]

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

[VOLVOMAGNUS]

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?

[ktenzer]

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

[VOLVOMAGNUS]

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

[ktenzer]

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

[VOLVOMAGNUS]

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

[ktenzer]

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

[steiner]

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.

[magnus_nyvall]

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?

[spinks]

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

[magnus_nyvall]

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

[marcel_juhnke]

Hi,

I have the same problem as Volker_Albrecht. We are using SC 4.1.1P2, so it seems the bug is not yet fixed.

Also, it was early last year that you said it will be fixed in SC 4.2 but until now there is no sight of SC 4.2. Any news on the release of that?

Thanks

Marcel

[spinks]

Marcel,

Any mention of future product names or version numbers is not a guarantee.  What I shared last year was the plan of record at the time.  Sorry for any confusion or inconvenience.

The next release of Snap Creator is planned as version 4.1.2 and is currently scheduled to be released in a few months time.

If you want a roadmap overview for Snap Creator it can be arranged through your account team.

I'll have to check on this particular BURT.  It was scheduled for the 4.1.2 release, but has since been removed from the release. 

I'm not certain why, but I will inquire.  I suspect that it is just a scope issue.

Have you opened a case?  If so the case number would help us drive this towards closure. 

Thanks,

John

[marcel_juhnke]

Hi John,

thanks for your reply. I have not opened a case yet, as I was able to fix the problem by manually installing OpenSSL 1.0.1 in addition to 0.9.8 which was included in the SLES11 installation. Seems that despite setting the correct Symlink names that the SC CLI does not work correctly with the old OpenSSL version.

Thanks for the hint on the roadmap information. I will ask my account contact on this one, as I'm particularly interested in the future of SC, because for me it seems to be the most compelling solution for a Backup & Recovery console going forward, especially as we never really took off with Protection Manager.

Best regards

Marcel

[VOLVOMAGNUS]

We didnt go forward with SC4 last time because of this serious bug.

Now we are looking at it again and the bug still exists?

I would have thought this would be the top priority to fix?

[VOLVOMAGNUS]

In RHEL 6.x there is a compatibility package called openssl098e-0.9.8e-18.el6_5.2.x86_64.

This solved it for me.

It provides the correct librarys.

Perhaps you should mention this in SC documentation?

Regards Magnus