Category: General

All Systems Go with SAS 9.3

Over the past few weeks I must have done about half a dozen SAS® 9.3 installations and deployments (mainly Linux 64-bit server and Windows 7 32-bit client). Not because of any problems really, just trying out a variety of options. My experiences have been very good. I must say the SAS installation and migration process is getting really streamlined now. Refreshingly easy actually. I even repeated a couple of installs because it would be easier to change some items during install than manually modify them in the new installation (something I wouldn’t have done with SAS 9.1.3). Of course, whilst SAS installations/migrations are getting more straightforward, I’d still recommend getting SAS Professional Services or one of the SAS partners to help – being businesses that install, migrate and configure SAS software on a daily basis they are very efficient and have extensive support resources at their disposal. I can’t imagine how it could be cost effective for SAS customers to acquire those skills when it’s something they might only do once or twice every few years.

My first impressions of SAS 9.3 have been very good. The installs and migrations went very smoothly. At Metacoda our installations are based on standard deployment plans and used for development and testing of our Metacoda Security Plug-ins software. Whilst our SAS installations are not very complex, we do have deployments with lots of carefully constructed, weird and wacky metadata security configurations. Deployments that, were you to see them in real-life, would have you wondering what was that administrator thinking! They are perfect for developing and testing our Metacoda Security Plug-ins software though! With SAS Migration Utility (SMU) based migrations our Lev1 and Lev2 security metadata came over perfectly from SAS 9.2 to SAS 9.3. We also did a clean empty Lev3 deployment too. I’m hoping that in future, with virtual folders in SAS 9.3, and the ability to easily export ACTs, users, groups, and roles, we could switch to using package exports and imports to promote this security metadata from SAS 9.3 to SAS 9.4 and beyond.

From our perspective SAS 9.3 seems to be very compatible with SAS 9.2 too. We were very pleasantly surprised to find our Metacoda Security Plug-ins ran in SAS Management Console 9.3 almost without change. A few minor modifications based on underlying changes in the SAS metadata model (the Login object changed its parent from SecondaryType to PrimaryType) and now we are running our plug-ins in SAS Management Console 9.3. We are so happy with it that our V2 release currently in beta will support both SAS 9.2 and SAS 9.3 when it goes live soon.

I have heard some people say they are hesitant about upgrading from SAS 9.2 to SAS 9.3 based on their experiences with SAS 9.1.3 to SAS 9.2. Personally I remember the move from SAS 9.1.3 to SAS 9.2 seemed more like a major version upgrade than a point release. I always wondered why SAS 9.2 was not SAS 10 ;). In contrast, the move from SAS 9.2 to SAS 9.3 does feel more like a point release upgrade to me. Whilst there may have been lots of improvements under the covers and a several welcome new additions, as a SAS platform administrator it still feels very similar to SAS 9.2. No huge learning curve and the users get to use almost the same clients they were using with SAS 9.2 M3 too.

I’ll certainly be recommending upgrades from SAS 9.2 to SAS 9.3 and for those currently on 9.1.3 it makes much more sense to me to go straight to 9.3 – the direct migration path is supported and why do two migrations and two rounds of testing when you can do one?

Some of the main administration oriented improvements I’m keen to look at in detail include:

  • Integrated scheduled SAS metadata hot backups. Now everyone gets scheduled metadata backups out of the box with no down time for the metadata server.
  • Easy SAS metadata restores with roll-forward recovery.
  • SAS Management Console virtual folders for exporting and importing users, groups, ACTs etc.
  • New SAS Management Console Search tab.
  • Enhancements to pre-assigned libraries.
  • IWA support for UNIX servers.

Keep an eye out for a few more posts from me on SAS 9.3. I’m hoping I get some time to document some of my 9.3 experiences as I investigate further.

Update 30Aug2011: Andy Ratcliffe mentions this post in his blog post NOTE: Upgrading to SAS 9.3 where he also makes some good recommendations about obtainining pre-installation architecture plans and post-installation implementation documentation.

SAS Restricted Options on UNIX

In a tweet by Gordon Cox last month, I was reminded of the restricted options facility available with SAS® software on UNIX platforms. This is capability where an administrator can set mandatory SAS system options at multiple levels of granularity: globally, per-group, and/or per-user. The reason for this post is that I don’t look at the documentation for this very often and every time I do it takes me a while to track it down. I always think its going to be in the UNIX companion in the Base SAS area… but it’s not! That gets me every time. Instead it’s tucked away in the Configuration Guide for SAS 9.2 Foundation for UNIX Environments (PDF) in Chapter 2 – Restricted Options. You can find this document in the Install Center section of support.sas.com under SAS Installation Note 36467: Documentation for a SAS® 9.2 installation on UNIX.

The context of the tweet was that the restricted options facility is another mechanism whereby a default setting of the NOXCMD option for SAS platform servers could be overridden for a subset of trusted users or groups in a SAS platform installation. The NOXCMD option is discussed in an earlier post: NOXCMD: NO eXternal CoMmanDs!

A quick summary of restricted options:

  • SAS Systems Options under UNIX set by an administrator, that cannot be changed by a user
  • Processed in the order global, group, then user. The last instance of an option is the one that wins.
  • Global restrictions are read from the file !SASROOT/misc/rstropts/rsasv9.cfg
  • Group restrictions are read from the file !SASROOT/misc/rstropts/groups/<groupname>_rsasv9.cfg
  • User restrictions are read from the file !SASROOT/misc/rstropts/users/<userid>_rsasv9.cfg

On Linux (at least) I can use the command “id -gn <userid>” to find out the effective group name for a user, given their user id. For example, “id -gn sassrv” might generate “sas“.

In my SAS 9.2 installation on Linux, whilst everyone else is still constrained by the NOXCMD option, I can ensure that the SAS Enterprise Guide user Bob Baxter, who has a user id of bob, can still use operating system commands in the SAS programs he runs on the SASApp server, by creating the file /usr/local/SAS/SASFoundation/9.2/misc/rstropts/users/bob_rsasv9.cfg with the following contents:

-xcmd

Of course, this only applies to SAS processes launched and run as the requesting user. Whilst it can be used to override NOXCMD for specific users/groups using a standard workspace server, it cant be used to distinguish between different users on the same stored process server, since all users will share SAS stored process server processes running under a shared identity (like sassrv). In that situation directing the users to separate SAS application servers would be more appropriate. There is an example of this in Jim Fenton & Robert Ladd’s SAS Global Forum 2010 paper 311-2010: A Practical Approach to Securing a SAS® 9.2 Intelligence Platform Deployment

Thanks to Gordon for reminding me about the restricted options facility.

Some PlatformAdmin.com Milestones …

My platformadmin.com blog has seen a few milestones of late:

  1. It had 1st birthday recently (boy that year went quickly!)
  2. … then, thanks to mentions from Waynette Tubs in the June edition of the SAS® Technical Report, and Andrew Ratcliffe in his excellent NOTE: blog, it saw a fair bit of extra traffic this month. The unique monthly visitor count for platformadmin.com topped 1000 visitors for the first time! I got especially geeky excited when I saw it hit 1024.
  3. … and finally, in a lesser milestone, the number of total spam comments deleted over the past year topped 1000 too – would have been happy not to have seen that milestone, but I guess it’s probably peanuts compared to what other blogs get :)

Thanks to all the readers out there, and special thanks to those that comment, tweet, retweet and say nice things about platformadmin.com on other sites/blogs too.

Happy SAS platform admin-ing to all.

Cheers
Paul

Desktop Files for Launching SAS Apps on Ubuntu

Whilst I often use the command line on Linux, it’s also nice to have icons in the menus to start SAS® applications like SAS Management Console and SAS Display Manager. These days I mostly use GNOME Do as an application launcher (its a bit like Quicksilver for Mac OS X). Naturally I like to be able to launch SAS apps from GNOME Do too. One day soon I’ll give Ubuntu Unity another try, and when I do eventually make the switch I probably wont use GNOME Do any more (but I’ll remember it as good friend), so then I’ll want to launch SAS apps from Unity. Thankfully I can use the same custom .desktop files in all of these situations.

Originally I used to point and click my way through editing the menus to add a custom launchers for SAS apps, but I soon tired of that. I’m a programmer too. Pointing and clicking doesn’t stay fun for long ;)

I found out about .desktop files after delving into what happened behind the scenes when I was editing the menus using point and click methods. There’s a GNOME Dev Center tutorial on it “Desktop files: putting your application in the desktop menus“. The freedesktop.org site also has a list of the Recognized desktop entry keys that can go into a .desktop file.

Below are some of the .desktop files that I use to launch SAS applications on my Ubuntu installation. I have only tested these on Ubuntu using GNOME but, since they are standard freedesktop files, I imagine they should also work in KDE and other Linux distros.

If you place the .desktop files into the ~/.local/share/applications directory (e.g. /home/userid/.local/share/applications) they will only be available to that single user. Alternatively, if they are placed into the /usr/share/applications directory then they will be available to all users.

The nice thing I have found about editing .desktop files is, so far at least, the changes have shown up in the menus immediately (i.e. without having to logout/login). In my installation the menu entries for these .desktop files can be found in the Ubuntu Applications > Other menu. They show up in GNOME Do too.

Here are the .desktop files I use:

SAS Management Console 9.2

This is a sas-mc-92.desktop file that I use to launch SAS Management Console 9.2 on Ubuntu.

#!/usr/bin/env xdg-open

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Terminal=false
Name=SAS Management Console 9.2
Icon=/usr/local/SAS/SASManagementConsole/9.2/SMCApplication.ico
Exec=/usr/local/SAS/SASManagementConsole/9.2/sasmc

SAS 9.2 Display Manager

This is a sas-dms-9.2.desktop file that I (sometimes) use to launch the old SAS Display Manager System (DMS) interface on Ubuntu. If you’ve used DMS on Linux you’ll probably understand why I only use it sometimes ;). I’d love to have a native SAS Enterprise Guide like interface to SAS on Linux (without having to start Windows in VirtualBox). I know, given the numbers, it’s unlikely to ever happen, but I can’t help wishing nonetheless :).

#!/usr/bin/env xdg-open

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Terminal=false
Name=SAS Display Manager 9.2
Icon=/usr/local/SAS/sas-logo-48x48.png
Exec=/usr/local/SAS/SASFoundation/9.2/sas

You wont find the /usr/local/SAS/sas-logo-48×48.png file in your installation so you should substitute that with the path to an appropriate icon available in your installation.

SAS Management Console 9.1

This is a sas-mc-913.desktop file that I use to launch SAS Management Console 9.1 on Ubuntu.

#!/usr/bin/env xdg-open

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Terminal=false
Name=SAS Management Console 9.1
Icon=/usr/local/SAS/SASManagementConsole/9.1/SMCApplication.ico
Exec=/usr/local/SAS/SASManagementConsole/9.1/sasmc

If you are a SAS user on Linux then I hope you find these useful too. If you have any info/experiences to share regarding .desktop files launching SAS apps in other desktop environments (KDE, Xfce etc.) or other distros (RHEL, Fedora etc.) then please leave a comment.

Using SAS92HFADD & ViewRegistry on Windows Server 2008 R2

In my earlier post on Reviewing Installed SAS 9.2 Software and Hotfixes I mentioned that I ran into a few User Access Control issues on Microsoft Windows Server 2008 R2 when using the SAS ViewRegistry Report utility and the SAS 9.2 Hot Fix Analysis, Download and Deployment Tool (SAS92HFADD).

To get the SAS ViewRegistry Report and SAS92HFADD utilities functioning correctly on Windows Server 2008 R2, the User Access Control (UAC) feature will require you to go through a few extra hoops (unless you have it disabled). UAC is a security feature that, when enabled, means that administrators log in and operate as standard users most of the time, and when they need to do something that requires elevated privileges they will be prompted by Windows (or as I also found out sometimes silently blocked). If you want more information (and a fuller explanation of UAC) then read the Microsoft document User Account Control Step-by-Step Guide.

If you run your server with UAC disabled then you can just follow the SAS instructions as normal and disregard this particular blog post. Of course running with UAC disabled is not normally recommended. I seriously considered turning it off, but decided I would try to ‘do the right thing’ and also use it as a learning experience. After a bout of UAC frustration I spoke to one of my friends who specializes in Microsoft technologies and he told me he leaves UAC enabled and tends to have an administrative PowerShell window open for when he needs to do some admin things.

In this post I’ll explain what I needed to do, in addition to the SAS provided instructions, to get those utilities working on Windows Server 2008 R2 with UAC enabled.

ViewRegistry Report

The SAS ViewRegistry Report utility is used to generate HTML and text reports listing the SAS software and hotfixes currently installed. You can also feed the output of this utility into the SAS92HFADD utility to generate another report detailing the appropriate available hotfixes that have yet to be installed, together with scripts to download and install them.

When I followed the usage note instructions for Windows and just double-clicked on sas.tools.viewregistry.jar I found nothing happened. I then opened up a command window and ran java -jar sas.tools.viewregistry.jar which gave me a bit more information as shown below:

c:\Program Files\SAS\deploymntreg>java -jar sas.tools.viewregistry.jar
java.io.FileNotFoundException: C:\Program Files\SAS\deploymntreg\registry.lck (Access is denied)
Exception in thread "main" java.lang.NullPointerException
at com.sas.tools.viewregistry.Report.collectRegistryData(Report.java:98)
at com.sas.tools.viewregistry.Report.main(Report.java:66)

I was logged on as someone who was an administrator (sas), so I knew it wasn’t a file system permission issue and must be related to UAC. To run sas.tools.viewregistry.jar with elevated permissions I right-mouse-clicked over the Command Prompt item in the Windows Start Menu, and clicked the Run as administrator menu item:

This opened an Administrator: Command Prompt window where I issued the following commands to run the ViewRegistry Report utility as an administrator:

cd "C:\Program Files\SAS\deploymntreg"
java -jar sas.tools.viewregistry.jar

This time it worked, generating the DeploymentRegistry.html and DeploymentRegistry.txt files as expected.

If you expect to run the ViewRegistry Report utility regularly then you might find it easier to create the file C:\Program Files\SAS\deploymntreg\ViewRegistry.bat containing the following:

@echo off
cd /d "%~dp0"
java -jar sas.tools.viewregistry.jar
pause

To run ViewRegistry.bat as an administrator, right-click over it in Windows Explorer and select the Run as administrator item from the pop-up menu:

SAS 9.2 Hot Fix Analysis, Download and Deployment Tool (SAS92HFADD)

The SAS92HFADD utility takes the output from the ViewRegistry Report utility and generates another report detailing the appropriate available hotfixes that have yet to be installed, together with scripts to download and install them.

SAS92HFADD for Windows is downloaded as a WinZip Self-Extractor (SAS92HFADDwn.exe). I ran this and got the following error:

It also needs to be run as an administrator. This can be done by right-clicking over the SAS92HFADDwn.exe file in Windows Explorer and select the Run as administrator item from the pop-up menu:

I now had the C:\Program Files\SAS\SAS92HFADD directory and files as expected. Into that directory I then dropped a copy of the DeploymentRegistry.txt file from a run of ViewRegistry Report utility. I actually missed this step the first time around and got the >> %%% ERROR: Unable to open DeploymentRegistry.txt error in the tool_log.txt file as explained in the SAS documentation.

Next I ran the C:\Program Files\SAS\SAS92HFADD\SAS92HFADD.exe utility. Initially it looked like it was working:

However, after a few seconds, the window closed and there were no additional files (not even a log file) in the C:\Program Files\SAS\SAS92HFADD directory. I immediately guessed this also needed to run as an administrator. I right-clicked over C:\Program Files\SAS\SAS92HFADD\SAS92HFADD.exe in Windows Explorer and select the Run as administrator item from the pop-up menu:

When it completed I had a new directory tree C:\Program Files\SAS\SAS92HFADD\WX6_1295740219 containing the following files as expected:

  • AnalysisReport\SAS_92_Hot_Fix_Report_WX6_1295740219.html
  • Log\tool_log.txt
  • DownloadTools\ftp_script.bat
  • DownloadTools\ftp_script.txt
  • DownloadTools\MD5_checksums.txt
  • DeployTools\WX6_install_script.bat

The AnalysisReport\SAS_92_Hot_Fix_Report_WX6_1295740219.html file is a report listing all of the available hotfixes that can be installed on the server (that haven’t already been installed):

The DownloadTools\ftp_script.bat file is an automatically generated script that can be run to download all the hotfixes identified in the report. I started out running this by double clicking on it in Windows Explorer. By this time I was almost certain that UAC would be a barrier, but as a learning experience I wanted to see how it would fail anyway. The following screenshot has the error message highlighted – at least there was an error message :)

I ran the FTP script again, this time by right-clicking over it in Windows Explorer and selecting the Run as administrator item from the pop-up menu:

The FTP script to download all the hotfixes ran successfully to completion this time. It took a while, as there were many hotfixes to download, but when it finished I had a bunch of hotfix executables in the DeployTools directory. Now it was time to install them.

To install the hotfixes I used the automatically generated DeployTools\WX6_install_script.bat script that silently installs each hotfix in turn. I started out running this by just double clicking on it in Windows Explorer. I guessed UAC would most likely block it, but once again I wanted to see how it would fail. It took a little while to complete, and appeared to be doing something without generating any errors, however when it had finished I could see by re-running the ViewRegistry Report utility that nothing had changed – no additional hotfixes had been installed.

I ran the install script again, this time by right-clicking over it in Windows Explorer and selecting the Run as administrator item from the pop-up menu:

I saw the command window open and all the commands flash by, possibly with errors, but way too fast for me to see – and also way too fast for the hotfixes to actually have been installed :)

The next method I tried, which worked this time, was to open a command prompt window as an administrator, change directory to the DeployTools directory and run the WX6_install_script.bat script:

The install script continued away for a while silently install each hotfix in turn:

Once the install script had completed, I went through the analysis report to ensure I did all of the outstanding manual tasks. I found the manual tasks by reading through the several linked documents in the analysis report that were tagged with a [D]. In this case it included upgrading metadata using the SAS Management Console, copying a plugins directory into a couple of locations, using the SAS Deployment Manager to rebuild a number of EAR files, and then redeploying the updated EAR files.

With all of this done I did a final check by re-running the ViewRegistry Report utility, copying over the new DeploymentRegistry.txt file, and then re-running SF92HFADD.exe. The resulting analysis report now had a nice green banner indicating that I was up to date with all of the available hotfixes.

Final Notes

This process assumes you want to install all of the available hotfixes. If your update strategy is to only install a subset of the hotfixes (such as those with alert notes) you can edit the generated ftp and install scripts to only download and apply those hotfixes you have targeted. The analysis report is a very useful document to help you determine what hotfixes are available for your platform/product mix that haven’t yet been installed. The report can also be used to help you chose which of those hotfixes are appropriate for your update strategy by reviewing the Issue(s) Addressed links.

Regarding UAC, at some point I also tried using a Windows Explorer (run as administrator) but found that the things it launched did not themselves run as administrator too. Looking back on it now, it probably would have been easier to avoid Windows Explorer completely and just use the administrative command prompt window (or PowerShell) – as my Microsoft oriented friend later suggested. I guess I could have also temporarily disabled UAC for the duration of this process and then re-enabled it afterwards. Taking this easy way out, however, would have meant I didn’t find out what I could and couldn’t do with UAC enabled, and I would have also missed out on the learning experience.

What I originally meant to be a reasonably short post has actually turned out to be much longer than I expected! If you’ve made it to the end and have any comments, or suggestions about alternative approaches, please let me know by leaving a comment below.