SAS Administration: How to Use Your Windows Knowledge for Linux Commands
10/15/2020 by Nick Welke
From time to time we work with a customer who switches from a Windows-based SAS environment to a Linux-based one. Often in these scenarios, System Administrators who are fluent with Windows commands and toolsets are asked to perform similar tasks in the Linux world, with which they are far less familiar. Here are several frequent tasks in a Windows-based SAS Administrator’s repertoire and their Linux equivalents.
For tasks that can be scripted, batched, and scheduled, command-line functionality remains the common denominator for these two families of operating systems. So although this is not really an apples-to-apples comparison as most tasks in Windows (and more and more in Linux) are optimally performed through graphical tools, here are some common tasks that one would run from the command-line in Windows, and their Linux equivalents.
For specificity, these commands were run on a Debian system running Ubuntu 20.04LTS and a Windows 10 Pro Build 18363. Both were run on the same hardware. In fact, this is where we begin. How would you find out your OS version and other system specs? In a Windows environment, there are several command-line tools to use: NET, SET, and VER. To find out your OS version we would run VER.
To do the same in Linux, you’d look at the /etc/*release file. (For example, on RHEL systems you’ll find an /etc/redhat-release file).
To find processor information (how many cores, what type of processors, speed, etc.), you would check the environment variables in windows with a SET command and search for only processor information with a FIND command.
In Linux, you would look at the /proc/cpuinfo file and grep for the model, vendor, and cpu family strings for the same information.
Note that -c on the grep statement will count the number of times a matching string is found, so in this case the number of processor entries in the file (or your number of cores). The sort -u at the end removes duplicate output as the cpuinfo file contains all the relevant cpu information for each core, fully replicated once per core.
To find out how long the server has been running on Windows, you’d use the NET STATS [SERVER|WORKSTATION] command (depending on whether you’re running a Windows server or workstation) and search for the “since” line with a FIND command.
In Linux you’d run an uptime command to show how long the machine had been up.
In both SAS 9.4 and SAS Viya, environments log files can be located in multiple paths across the environment. To keep track of these locations, it’s important to know your current location in the directory tree. By default this is indicated in the prompt, but for use in scripts it can be displayed with a command. On Windows systems this is the CD command without parameters.
The corresponding Linux command is pwd.
Now that you know where you are, you should look around and see what files we see here. In Windows, this is done with the DIR command.
In Linux, the same type of information (directory entries, file size, and timestamp) is displayed with the ls command with -la as the parameter. Note that ls will also indicate permissions, owner, and group assigned to listed objects.
While the above examples are great for looking around, in a script you want to only list the filenames without all that superfluous metadata. To generate just a list of files in Windows, you use DIR /B.
In Linux, you use ls without parameters.
Next, you may want to look not just in the current directory but in multiple subdirectories for potential log files. In Windows this is done with the DIR command with a /S parameter and using the wildcard *.log to find all files with a .log extension.
In Linux you could also use a variant of the ls command, but a more effective command is find, with the top of the search path (in this case the current directory .), and a -name “*.log” parameter to only find files ending in .log.
Now that you have some files to look at, you need to search through them for interesting content. Most systems will label an event of interest with an ERROR tag, so you can search through a log file to only display lines with the ERROR tag. In Windows this can be done with the FIND command, indicating the search string in double quotes, and the file(s) to search as the second parameter.
In Linux you can use grep in much the same way.
Typically you may want to search through multiple files at the same time rather than specifying each log to search through. To do this in Windows you would use the *.log wildcard as the filename for your FIND command.
Similarly, you would use *.log with the grep command in Linux.
Another commonly scripted task is to search for and count user activity, such as connections to a Metadata Server. This breaks down into two steps. Locating all instances where a given user connected first, and then counting those instances. In Windows, you would again use the FIND command to locate all references to the username of interest , and then pipe that list to another FIND command searching for new connection messages (or counting them with a /C parameter).
In Linux, you would again use the grep command and follow a similar path. First, find all references to the username , then pipe that list as input to a second grep command looking for new connections , and finally add the -c parameter to only count those new connections.
Finally, as part of startup or shutdown scripts, it may be necessary to check that specific ports are listening or available. Both Windows and Linux use the netstat command for this, but there are some differences in how they present their output.
For comparison, here is a Windows NETSTAT -A command, piped through a FIND command to list only listening ports.
And here is the Linux equivalent: a netstat -a command piped through a grep for the string LISTEN.
The above examples give a sense of how a Windows administrator can use their knowledge of Windows commands to employ Linux commands in managing and troubleshooting a SAS environment running on Linux. Although there are syntactic differences, there is a close mapping between Windows and Linux command-line tools for many common troubleshooting functions.