One of the regular tasks of managing a SAS 9.4 deployment is updating licenses in the appropriate locations when a license is about to expire or has expired. For those of you who have applied these licenses you know that the SAS Deployment Manager (SDM) is the tool to get the job done. Although applying the new SID file is a fairly straightforward task, there may be a need or a preference to run the SDM without the GUI. In this blog we will review a method of applying licenses without the GUI that you may not have encountered before now.
The SAS Global Enablement and Learning team creates and manages many collections of multi-machine SAS environments to enable the technical services community at SAS. As you are probably aware, the license file associated with a new SAS 9.4 deployment is valid for one year, plus a warning and grace period. Therefore there is a need to update the licenses of those collections as efficiently as possible and with little to zero errors. In operational/production environments, automation and efficiency are typically key aspects of maintaining a deployment. Therefore the administrators of such environments may prefer to execute a command/script to accomplish the update in a repeatable and timely manner..
By now you have figured out where this is headed. Yes, it is accomplished using "quiet" mode. Just as you can capture a response file for the SDW and use it for playback of a deployment, you can capture the responses from the SDM for playback. However to do so on a repeated basis you will need tweak the response files. This capability has been around since the SAS 9.3 days.
The examples in this blog are for a Visual Analytics deployment on RHEL. And if you are familiar with Visual Analytics 7.x deployments, you are probably aware that there are three separate components that are licensed when using the SDM:
Updating the licenses for a VA deployment requires two passes through the SDM. One for Foundation and LASR and one for Metadata. The update of Foundation and LASR requires all services be stopped before applying. And the update of Metadata obviously requires that the Metadata server be started.
Shown below is the architecture of an environment that required an update of licenses. The environment consists of five Red Hat machines with SAS Visual Analytics and SAS EBI deployed across them. Machine sasserver01 contains the metadata server and VA compute server, as well as the LASR root node and Hadoop name node. Machines sasserver02-sasserver04 contain the LASR worker and Hadoop data servers. And sasserver05 houses the VA and EBI middle tier as well as the EBI compute server. As a result of this configuration license updates are required on sasserver01 and sasserver05.
To apply a license via a response file, it is first necessary to capture the responses using the same method as the SDW. Execute the SDM as the SAS installer account with the -record and -responsefile parameters.
Once the prompts have been select, view the response file to familiarize yourself with the parameters. Notice that "renewalLicense" is the task that is chosen.
Now that the response file has been created, run the SDM again as the SAS installer account in quiet mode and reference the response file.
The quiet SDM execution does not provide a response back to the session when it completes, but the log for it can be found in the .SASAppData subdirectory of the home directory for the account used to apply it.
This install log doesn't show the results of the setinit job, but the path of the SETINIT log can be found in the IT install log. Although you must view a second for the Foundation update, the results of applying the LASR license can be viewed in this (IT install) log.
To verify that the SETINIT was successful for Foundation, you can review the setinit log at this location /opt/sas/sashome/SASFoundation/9.4/install/admin/logs/setinit_2017-08-02-14.37.58.log. Here is a snippet from that log.
Future invocations of the SDM to update the licenses would just require a change to the path of the new SID file within in the response file.
Some solutions require license updates to Metadata. Therefore a second execution of the SDM with the -record and -responsefile options will be required to capture the responses. The SDM metadata update contains several additional prompts, some of which will automatically be supplied. They can be seen in the example below.
Once responses have been captured you will have to apply the license. Note that this update takes longer than updating Foundation and LASR. This update may take a minute or two as opposed to the Foundation update that takes seconds. If necessary it will start the metadata server.
Like the Foundation/LASR update, there is no indication that is written back to the session. The SDM log can be scanned to verify it completed successfully.
The log for the loadSetinitintoMetadata task can be found at this location:
But the easiest way to verify that the setinit was updated in metadata is use the SAS Management Console. Drill down to Metadata Utilities under Metadata Manager, right click on the utilities folder and select "View metadata setinit details".
The resulting window will show the updated setinit with each product number.
Since the response file contains the encrypted SAS administrator password, you'll want to ensure that the file is secured so that only the installer account running the SDM has access to it. And future updates will require that the SID file path and file name be updated to reflect the current SID file. Finally you'll need to restart all of the services. That's all there is to it.
Although the license file update process is a well-known process for any installer or administrator, the capability to run in quiet mode may not be so popular. Once the response files are generated, it is easy to tweak them to invoke in quiet mode for future updates. This assumes the configuration has not changed. The examples in this blog reflect a deployment on RHEL, but a similar process can be followed on other platforms.