We recently confirmed (via http://support.sas.com/forums/forum.jspa?forumID=10&start;=0) that SAS Enterprise Guide does not support proxy servers between itself and SAS servers (metadata, workspace, stored process, etc). However, if the proxy server can be transparent then EG can work through it.
While implementing SAS BI at a customer site we needed to access servers through a forwarding firewall, effectively the kind of scenario EG does not support. In particular, two server environments (dev and test) were at one site and client components (EG and AMO) were at the other site. Between them was a site-to-site connection through a forwarding (NAT) firewall - each side saw one IP address for all points on the other end of the connection.
To make this configuration work, we had to modify the ports on the SAS BI server configurations to be unique on the forwarding firewall. For instance, the dev metadata server was configured to use port 38561 and the test metadata server to use 28561.
Next, ObjectSpawner had to have the -lbUseHostName option enabled in the ObjectSpawner.sh file to pass the hostname rather than the IP address to EG (see http://support.sas.com/kb/18/503.html).
Finally, the client machines had to have DNS (or hosts file) entries for the physical hostnames defined in metadata that mapped to the firewall address. So where the dev SAS Workspace Server was named SERVER11, the test SAS Workspace Server was named SERVER21, and the firewall remotefw1 we had to add aliases for remotefw1 that would direct traffic destined to SERVER11 and SERVER21 to the firewall. In a hosts file it looked like this:
12.34.56.78 remotefw1 SERVER11 SERVER21 # IP address of firewall with aliases
While not a true NAT configuration (in that the ports have to be identical on both sides of the firewall) this setup does allow EG to connect through a single local IP address to multiple SAS servers residing at a remote location.
4 Comments
Nice job with the firewall research.SAS services are definitely moving in the direction of using standard protocols that hang off of standard ports.SAS Enterprise Guide and the SAS Add-In for Microsoft Office are currently tied to the IOM protocol, which offers different APIs and access points for submitting jobs, accessing data, receiving results and events. The balancing act: keep these desktop clients responsive and usable with a minimum of setup/overhead on a standalone single-machine install, while allowing them to connect to services via standard ports on a mid-tier for those customers that deploy across multiple machines.
Alan, you're right of course. The ideal situation would allow a stream of text (whether encrypted with SAS/SECURE or not) to flow through port 80 and be sorted out at the destination. Failing that, some level of proxy support would be good, perhaps similar to how a SAS/CONNECT session can travel through an SSH tunnel. For now this is the closest we've been able to get.Nick
One other minor point: you declare a port...you declare failure. There has to be EXTRAORDINARY circumstances to validate saying a port needs opening. Work with 80 and assume all is text.Why does SAS need something else!?
SAS really should move to an SOA configuration where the only port that matters is 80. While I know you did what was needed to pull it off (I would have done the same), SAS should operate on either a REST or SOAP dependency and drop the proprietary stuff.My pebble in the pond of the SAS world. Congrats on getting it working.Alan