SC3.5.0 and OM/PM https communication [ Edited ]

[#1]

I am having problem getting https commuication working from SC3.5.0 Windows version to OnCommand 5 server.

This is the settings in OnCommand. So both http and https are enabled.

I can log in to Managment Console with both protocols.

Both Snapcreator and OnCommand server runs on same Windows host.

But when i use this setting in SC.

OM_PORT=8488

i get the following error:

########## Parsing Environment Parameters ##########

[Wed Jan 25 16:02:07 2012] ERROR: validation of target segotn880 failed [No response received at /<C:\Program Files\NetA

pp\NetApp_Snap_Creator_Framework\scServer3.5.0\snapcreator.exe>SnapCreator/ZAPIExecutor/DfmZAPIExecutor.pm line 65.

]

[Wed Jan 25 16:02:07 2012] ERROR: No response received at /<C:\Program Files\NetApp\NetApp_Snap_Creator_Framework\scServ

er3.5.0\snapcreator.exe>SnapCreator/ZAPIExecutor/DfmZAPIExecutor.pm line 65.

With

OM_PORT=8088

it works just fine.

What am I missing here.

Regards Magnus Nyvall

[#2]

Hi Magnus,

I just tested this and it works for me so it is some issue in environment.

This error means there is some communications issue between scServer and OnCommand.

Did you try "telnet dfmServer 8488"? Does that go through.

Additionally if this is a linux scServer there could be some issues with your ssl libs, SC will link to SSL libs on OS so if they aren't named correctly that can cause issue. It is simple problem to fix you just create symlinks.

Here is info from BURT 499567:

HTTPS may not work on linux out-of-the-box. This appears to mainly be issue with SuSe but really could apply to any Unix. Snap Creator does not include ssl libraries we are dependent on, therefore customer must install openssl and ensure symlinks are created correctly (see below). The reason is simply we dynamically link so customers can update SSL versions of openssl for important security fixes without being dependent on SC versions.

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

If this doesn't work run strace and send to engineering:

strace ./snapcreator --profile <profile> --action snap --policy <policy> --verbose

That is all I can think of

Let me know if this helps?

Keith

[#3]

No it is running on a Windows 2003 Server Standard Edition Service Pack 2.

Its the same server that runs OnCommand and SnapCreator.

telnet command works. I get connect on port 8488.

[#4]

Just tested windows, everything works with HTTPS.

The only thing I can think of is some issue between scServer and dfm server, maybe hostname resolution, maybe ACL but if you can telnet to port and get connection then most likely that stuff is working.

Another idea is maybe you dont have TRANSPORT=HTTPS set in config? Although if that was case I would expect a different error. This error usually indicated hostname resolution.

You could try installing SC on DFM server see if that works, that would tell you if problem is between host and DFM server at least.

Sorry I cant be of more help on this one

Keith

[#5]

>You could try installing SC on DFM server see if that works, that would tell you if problem is between host and DFM server at least.

It is running on the DFM server.

I do have TRANSPORT=HTTP because im communicating direct to a vfiler so HTTPS wont work.

But do that flag have anything to do with the OM integration?

I did not think so?

It is pretty much a base installation of Windows 2003 SP2.

Are there any required updates/patched perhaps?

I have not found any such requirements mentioned in the Admin Guide though.

Regards Magnus

[#6 · Accepted solution]

Yes, TRANSPORT is used for array, vfiler and DFM.

If I remember well the only way to use DFM with vfiler and HTTPS is to use the DFM as proxy (so using USE_PROXY=Y).

Francesco

[#7]

SC will use either HTTP or HTTPS to communicate with both storage systems and DFM.

If TRANSPORT is set to HTTP it means you must also use HTTP to communicate with DFM.

This is the reason it isn't working. If you switched to TRANSPORT=HTTPS and PORT used for filer to 443 it would work. Problem is a vfiler can only talk over HTTP, so option is live with HTTP or communicate with physical filer then you can do HTTPS.

Regards,

Keith

[#8]

Ok thankyou.

This might be a problem at Volvo then.

They want to use vfilers for security reasons and also https to dfm server for security reasons.

DFM as a proxy is not something they want since that would make the DFM server a single point of failure for many database servers. (100-200)

And it is not clustered today. Perhaps in the future.

It would be nice to have an OM_TRANSPORT option to be able to use https only for that and HTTP to vfiler.

Regards Magnus