Getting SAS Software running on CrunchBang Linux 64-bit

This is a follow-up to my prior post on Getting SAS® Software running on Arch Linux 64-bit. In my quest for a new Linux distro the next stop was CrunchBang Linux. I like the look of CrunchBang because it’s lightweight, based on Debian, and uses Openbox by default. Being Debian based, like Ubuntu, I get to re-use the knowledge I gained from using Ubuntu over the last few years (it’s hard not to automatically type apt-get whenever I want to install something!). CrunchBang is not a rolling release distro like Arch or Gentoo but it’s other attributes make it well worth a look. I’ve seen a disclaimer on the web site where they say it “… could possibly make your computer go CRUNCH! BANG!” but from everything else I’ve read it sounds pretty stable. Anyway, I like my (own) computers to go crunch bang every now and then – it’s a great opportunity to learn something new ;)

I installed the CrunchBang 11 “Waldorf” 64-bit testing image in a multi-boot configuration, alongside Arch and Ubuntu, to test it with our existing SAS deployments. These are the steps I needed to take to get the existing SAS software installation running on CrunchBang 64-bit. As with Arch, no changes were needed to the SAS deployments, it just required a few minor changes and additional libraries for the CrunchBang installation.

After CrunchBang had been installed and I’d mounted the SAS installation volume, I tried to run SAS 9.3 M2 first and got the following error: Continue reading “Getting SAS Software running on CrunchBang Linux 64-bit”

Getting SAS Software running on Arch Linux 64-bit

Recently, I’ve been looking to switch from Ubuntu to an alternative distro as the primary Linux platform for our Metacoda development/testing environments, where we also run SAS® software. I’ve run quite a few distros in my time including Slackware, RedHat (pre-Fedora), Fedora, Gentoo & Ubuntu. Ideally I’d like something lighter and perhaps a rolling release too: lighter, so more resources go to SAS; rolling release, because given the choice I prefer regular small upgrades to occasional big upgrades. One of the potential candidates is Arch Linux and so I’ve recently installed it, in a multi-boot configuration with the existing Ubuntu installation, to test it with our existing SAS installations. This is one of the things I love about running SAS on Linux. The SAS software gets installed and configured once and the underlying operating system can be completely upgraded or replaced without having to re-install SAS. It might just take the installation of a few libraries to get everything working again but that’s not much compared to the effort of re-installing and configuring our SAS 9.3 M2, SAS 9.3 M0, SAS 9.2 and SAS 9.1.3 SP4 dev/test environments.

These are the steps I needed to take to get the existing SAS software installation running on Arch Linux 64-bit. No changes were needed to the SAS deployments, it just required a few additional libraries to be added to the Arch installation. If you’re wondering why several SAS versions?, it’s because we need to test our Metacoda software with each of them. The SAS 9.3 and 9.2 installations are 64-bit and the older SAS 9.1.3 installation is 32-bit (so takes a bit more work).

SAS 9.3 (and 9.2)

After Arch had been installed and I’d mounted the SAS installation volume, I tried to run SAS 9.3 M2 first and got the following error: Continue reading “Getting SAS Software running on Arch Linux 64-bit”

SAS 9.3 Framework Data Server (and the missing license)

Whilst troubleshooting why my SAS 9.3 Framework Data Server wasn’t starting I discovered that, unlike Foundation SAS where the license (a.k.a. SID or setinit) is applied once a year, the SAS Framework Data Server requires the presence of a setinit.sas during every start up. Mine had been deleted. I’m not 100% sure how that came to be but I suspect it was probably one of two things: Continue reading “SAS 9.3 Framework Data Server (and the missing license)”

Running SAS on Ubuntu Linux: Dash to Bash

It happened to me again today … the Ubuntu dash-bash-default-shell-thing:

userid@hostname:~$ /opt/sas92/SASFoundation/9.2/sas
/bin/sh: 0: Illegal option -p
userid@hostname:~$ /opt/sas93/SASFoundation/9.3/sas
/bin/sh: 0: Illegal option -p

I encounter this every now and then. This time I was upgrading my notebook and it’s Ubuntu 64-bit installation to 12.10 and restoring SAS 9.2 & 9.3 installations from backup.

Several years ago the default shell symlink of /bin/sh to /bin/bash was changed to /bin/dash in Ubuntu. You can find out more about the reasoning behind Ubuntu’s switch from bash to dash here – it caused quite a bit of discussion when it happened.

The often suggested fix is to manually change the /bin/sh symlink, but there’s also a command to do it (which also fixes the associated man page symlink too):

Continue reading “Running SAS on Ubuntu Linux: Dash to Bash”

SAS Management Console over SSH

I was asked recently how to get SAS® Management Console to remotely access a SAS metadata server using SSH tunnels. In the absence of a VPN connection to your network, SSH can be an alternative for SAS Management Console access to a remote SAS metadata server.

I am a huge fan of SSH (Secure Shell). I have been using it several times a day for many years now. It’s great. If you haven’t heard of SSH before, take a look at the Wikipedia page for Secure Shell. Here’s a quote from the page that provides a nice intro/summary:

Secure Shell (SSH) is a network protocol for secure data communication, remote shell services or command execution and other secure network services between two networked computers that it connects via a secure channel over an insecure network.

Here are a couple of methods for using SAS Management Console over SSH:

1. Remote execution of SAS Management Console with X11 forwarding to the client

This method can be used when you are accessing a SAS platform installation on Linux or UNIX and have SSH client software and X server software on your remote workstation. Mac or Linux workstations are great for this since they usually have all the required software pre-installed. Windows can also be used if you obtain SSH client and X server software. I personally use Putty as an SSH client when I am working on Windows and would defintely recommend it. I have no specific recommendations for an X server on Windows since it’s been a long time since I’ve done X on Windows.

Assuming, as a SAS platform administrator, you have remote SSH access to the SAS metadata server machine then you can use SSH from your workstation to execute the SAS Management Console remotely and forward the X display to your client workstation.

Here’s an example command to do this:

ssh -X sasmeta.example.com /opt/sas93/SASManagementConsole/9.3/sasmc

Which means SSH connect, with X11 forwarding, to the machine sasmeta.example.com and then execute the SAS Management Console (/opt/sas93/SASManagementConsole/9.3/sasmc) on that remote machine sending the X windows back to the client workstation.

2. Local execution of SAS Management Console with SSH tunneling

SSH also allows you to configure a tunnel – a local port on your workstation that that forwards traffic to a designated server and port in the remote network. This tunnel can be used to make a remote service appear to be a local service. We can use it to make a remote SAS metadata server port appear to be on the local workstation so that a local installation of the SAS Management Console can connect to it as if it had a local metadata server.

Here’s an example command to do this:

ssh -L 8561:sasmeta.example.com:8561 sasmid.example.com

Which means SSH connect to the machine sasmid.example.com and establish a local machine port (8561) that forwards traffic to the remote host/port sasmeta.example.com:8561 accessible via sasmid.example.com. If you are not using public key authentication (recommended) then you will be prompted for a user id and password for the server. Once the connection is active, a local SAS Management Console can be started and will be able to access the remote SAS metadata server using a connection profile that connects to a metadata server on host/port localhost:8561. All traffic to this local port will be sent to the remote metadata server over the SSH tunnel.

Bear in mind that this only makes the metadata server port available on the local machine. So the local SAS Management Console instance can only access the metadata server. It doesn’t necessarily make the client fully functional as it may require additional connections to additional servers e.g. access to a SAS Object Spawner for a SAS Workspace Server session or a connection to the SAS Content Server. You could look into forwarding other ports and will also need to modify your local hosts file to redirect the remote host names found in metadata to the localhost interface. For anything more complex than pure metadata server access it would probably be easier and more robust to use a VPN connection (or remote access via something like X or RDP to remote network client workstations).