SAS Viya Transfer CLI: HTTP Connection Error on Import Command (HTTPS connection defined)

[daithi1990]

Hi, 

I've tried importing an SPK from a 9.4 VA Environment to a SAS Viya VA Environment. This is using the transfer CLI on windows. We have our Viya instance setup via AWS and for obvious security reasons have disabled access over http://, i.e. we are only accepting traffic over a https:// request. (and no reopening http is not an option) I've taken the following steps to get to the sticking point. I was wondering if anybody else had the same issue and if so what steps have they taken to resolve? It all looked to be going pretty good until push came to shove. 

Step 1: Create the Profile

C:\Users\Folder>sas-transfer profile init

Enter configuration options:

Service Endpoint>  https://site:7980

Output type (text|json|fulljson)> text

Saved 'Default' profile to C:\Users\Folder\.sas\config.json.

Step 2: Get an OAuth Token for profile

C:\Users\Folder> sas-transfer authenticate login -u sasadmin -p password

Login succeeded. Token saved.

Step 3: Upload SPK with Mapping File

C:\Users\Folder> sas-transfer upload --spk package.spk --mapping mapping.yml
Id 3e253eb5-cfd5-47fd-b949-ba4d86f1082a
Name package.spk
INFO: Mapping file mapping.yml created.

Step 4: Import updated file and mapping (the puzzling bit)

C:\Users\Folder>sas-transfer import -packageId 3e253eb5-cfd5-47fd-b949-ba4d86f1082a --mapping mapping.yml

running ....failed

The following errors have occurred:

Get http://site/SASHome/: dial tcp 10.10.10.10:80 : connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Http Status: 0

Why would the cli default back to http:// especially when I've specified the request/site to be https://? 

Kind Regards, 

David 

[angian]

This may help you 

Set the SSL_CERT_FILE Environment Variable
http://go.documentation.sas.com/?cdcId=calcdc&cdcVersion=3.3&docsetId=calcli&docsetTarget=n1e2dehluj...

[daithi1990]

Hey Angian, 

Will give it a try 🙂 

[angian]

What documentation are you looking at? I am not familiar with this specific CLI but normally you would need to run the import from the target Linux server?  Sorry to ask a question on your question.  My boss has actually worked with this CLI so I will get confirmation unless somebody beats me to it.  Also what is your target system? Viya 3.2 or 3.3?

[daithi1990]

Hi Angian, 

This is the documentation i'm working with. 

http://documentation.sas.com/?cdcId=calcdc&cdcVersion=3.2&docsetId=calpromotion&docsetTarget=n0ihk3d...

At the moment the target env is Viya 3.2 (soon to be upgraded though)

You effectively install the .exe from viya into the location you wish to transfer from (in this case windows)

So have updated the env variable and am getting a slightly different message. 

C:\Users\Folder>sas-transfer import -packageId d2dfe0c1-3b03-4de1-b962-4d91f2cd84b6 -mapping mapping.yml
running .....failed
The following errors have occurred:

Get http://url/SASHome/: dial tcp <insertiphere>:80: connectex: No connection could be made because the target machine actively refused it.
Http Status: 0

[alexal]

@daithi1990,

Either one you have entered incorrect address/port or you have a firewall between sas-trasfer and SAS Viya 3.2.

[daithi1990]

Thanks alexal, 

Just breaking your comment down there a little. 

1. I was able to OAuth and upload .spks to the Viya instance, so that could in my own mind rules out the firewall/wrong address issue. i.e. I can connect and interface with the site. 

2. I noticed some Strange behaviour with the exe is despite the fact I've entered https:// it reverts to http:// on the import stage. I have an inkling that this is what's causing the problem, as our viya instance is setup only to accept https:// not http:// requests. 

[alexal]

@daithi1990,

Please add -verbose to your sas-transfer command and show me the outcome.

[daithi1990 · Accepted solution]

Okay so a few points to note:

1. As we are running our Viya instance on AWS we have defaulted all external traffic through our load balancer to Port 443.

The request then internally is converted into a port 80 request when it hits the server.

We temporarily had to open our Load Balancer to Port 80 to accept HTTP traffic for this to work.

2. When this occurred we received a report of the reports we were ingesting however it contained errors on the CLI import log. 

/var/log/sas/viya/importvaspk/default/<logfiles>

We checked in the log, and saw that a missing PNG Shared object in the renderer folder was stopping the ingest of report files. (Apparently we had installed the Golden Build too, good old SAS ;))

Status: Report import failed. 1) error converting unknown page/section: unexpected java.lang.UnsatisfiedLinkError thrown. Message = "/opt/sas/viya/home/lib64/renderer/libCommonsJava.so.2.0.0: libpng12.so.0: cannot open shared object file: No such file or directory"

We then used YUM to install the 64 bit renderer 

yum install libpng12

And copied this file 

cp /usr/lib64/libpng12.so.0 /opt/sas/viya/home/lib64/renderer/

Then we reran the process and reports uploaded successfully. 

[SimonDawson]

Good catch. libjpeg-turbo is another package that is often overlooked. The documentation often is written with an assumption that the installation package group is one of the larger ones like “server with GUI”.
When you deploy a much more minimal package set for your base some prerequisites get missed.