Unix SAS installations are done on RedHat Enterprise Linux (RHEL) these days. Linux has lower cost of ownership, no real memory limitations, and lighter-weight OS background services than other operating systems, such as Windows.
SAS provides a multitude of documentation to install and configure SAS 9.4 on Linux, but sometimes it is overwhelming to review all the aspects of an installation.
The Pre-Installation Requirements Document (PIRD), otherwise known as the checklist document, gets generated from creating a custom plan.xml file. The PIRD produced by the SAS Planning Application (requires registration/login), does provide quite a bit of detail, but even this document does not cover all aspects of an install.
This article provides key guidance on important items to check before starting a SAS 9.4 install – details that are typically overlooked or missed.
For most of these tips, you will need sudo privileges or root access:
1. /tmp directory
SAS recommends a minimum of 30MB free space in the /tmp directory for a typical SAS installation.
/tmp is normally a small partition with a disk allocation anywhere between 5G to 10GB. If you don’t have the prerequisite minimal 30 MB of space available before you start the SAS install, you will most likely have to clean up the /tmp directory and restart the installation from scratch after it crashes midway through.
Reference: See Space Requirements section of the System Requirements for SAS® 9.4 Foundation for Linux for x64 document
2. Ulimit Settings
SAS has specific requirements for the mid tier to increase the default nproc (number of processes), stack, and nofile (number of open files) operating system settings.
This is mandatory for the mid tier server (where all the web apps are running), but these ulimit settings are also normally applied across the board for the meta server and compute server tiers.
At Zencos, we use a best practice of setting both the soft and hard values for nproc, stack and nofile to 20480 for the sas installer account.
For RHEL, you will need to modify the following files:
/etc/security/limits.conf /etc/security/limits.d/20-nproc.conf
Example below:
Reference: See Linux section of the SAS® 9.4 Web Applications: Tuning for Performance and Scalability documentation
3. X11 libraries, gclib and other yum packages
Most RHEL servers come preinstalled with the X11 graphical window management packages, but in case they do not, you will want to install them using:
sudo yum groupinstall “Server with GUI”
SAS Foundation (a.k.a. “Base SAS”) requires gclib support.
Zencos also installs the telnet yum package as good practice, since it is useful to test inter-server port communications.
References:
See Software Requirements section of the System Requirements for SAS® 9.4 Foundation for Linux for x64 document for the packages needed
See this Red-Hat discussion regarding installing X11
4. PAM Authentication
The majority of Linux installs use LDAP or Microsoft Active Directory to manage their users. Typically, your IT team will want to use a branch of this directory to manage the SAS Users group and have Linux point to it for authentication purposes. This means that a PAM module will be installed on Linux to allow users to use their Windows account to login to Linux.
There are many providers of PAM modules, including Centrify, BeyondTrust, CyberArk, IronSphere, etc.
Regardless of the PAM provider that is installed on Linux, SAS requires that an /etc/pam.d/sasauth be created on each of the SAS tiers.
Reference: https://support.sas.com/kb/49/432.html
5. vFabric License Location
The SAS 9.4 mid tier has a specific requirement for its web apps such as SAS Studio®.
The /etc/opt/vmware/vfabric directory must be manually created and be Read-Write accessible by the sas installer account before the SAS Deployment Wizard (SDW) is kicked off to install/configure any web apps.
Reference: https://support.sas.com/kb/50/433.html
6. JUnit Download
JUnit is a third-party software Java JAR file that is used by the SAS Deployment Tester service. The SDW will not let you proceed until you point to the local copy of this file that you need to download ahead of time. Due to licensing reasons, SAS cannot package this file with the SAS Depot that you download, so instead you must download it manually. Zencos normally downloads this JAR file and saves it in the SAS Depot location when we do SAS 9.4 installations.
The SAS Deployment Tester service is used to qualify the SAS installation and is found under the Application Management section of SAS Management Console. The instructions.html file that is generated at the end of a SAS installation/configuration by the SDW, provides the steps needed to run the IQ/OQ qualification tests. After the tests/qualifications have been completed and you have 100% successful results, you can stop to the SAS Deployment Tester services to free up SAS computing resources.
The official SAS website provide a download link to this third-party software, but you can use the Reference in this article to download it directly to save you a few clicks. As with all releases of SAS 9.x, you must use the 4.8.1 version of JUnit as shown below. You only need to download the JAR file.
Reference: Direct download link for JUnit 4.8.1 https://sourceforge.net/projects/junit/files/junit/4.8.1/
7. Database Clients
The trickiest portion of a SAS installation is connecting to third-party databases such as Oracle, MS SQL Server, Progress, and Teradata, just to name a few.
SAS uses ACCESS Engines to enable connectivity to these databases, but there is some prep-work magic that needs to be completed first, to make the connectivity between SAS and the database, functional.
The setup of Unix specific database client software on the SAS compute tier should be completed and tested prior to starting a SAS installation. In addition, pre-configuring some database connections is normally done at this time, to make it simpler for the customer to connect to the various databases/table that they need access to.
For example, MS SQL Server can be accessed either through SAS’ ACCESS/MS SQL Server or through SAS ACCESS/ODBC. In either case, a third-party driver called DataDirect from Progress Inc. is installed, which requires an ODBC Driver Manager. The primary difference between ACCESS/MS SQL Server and ACCESS/ODBC is that under the hood, SAS provides the DataDirect driver with ACESS/MS SQL Server, while with ACCESS/ODBC, the customer is responsible for obtaining and installing an MS SQL Server ODBC driver.
Regardless of the database your customers want to connect to, there is connectivity work to be done before starting a SAS installation.
8. Check for Open Ports
If your SAS 9.4 environment consists of more than one server, then you will most likely have to deal with firewall issues that the IT team have either zealously put in place to thwart your install (or because of actual corporate security reasons!)
SAS has some important default ports, such as 8561 for the Metadata server among others, that you will want to ensure are open between the SAS servers (normally the case if all the SAS servers are located on the same switch/subnet) and between the SAS servers and the users’ laptops/desktops (normally closed since users are accessing the SAS servers from a different subnet).
A complete list of ports is found in the checklist.doc file that gets generated by the SAS Planning Application. These ports are also shown and can be updated during installation process.
Utilities such as telnet and Linux commands like netstat -a |grep <port#> will come in handy to troubleshoot connectivity issues.
Reference: checklist.doc (generated by the SAS Planning Application)
9. HTTPS / Certificates
You will need your IT or security team to generate a machine or “subject” certificate/key in PEM (base-64 encoded) format and also provide the ROOT and INTERMEDIATE certificate chain in PEM format, if you plan on accessing the SAS mid tier using HTTPS. Get all of these certificates created before you start the SAS installation.
Certificates generated by Windows Certificate Authorities typically have a *.CRT or even a *.CER extension but can simply be renamed to a *.PEM extension. Remember to remove the end-of-line (CR+LF combination) from a Windows generated certificate file after you move it to Linux, which only uses LF to terminate its lines. You can do this easily with Textpad, Notepad++ in Windows, or Linux commands such as “dos2unix” or “sed” utilities, or use the “a” method when ftp’ing the file down to the Linux server.
Alternatively, you can leave the certificates on a load balancer such as an F5 (hardware based) or HAProxy+keepalived (software based), enabling URL forwarding/re-writes and install SAS using HTTP. That’s a larger discussion for another article.