Modifying Server Startup Configuration in SAS Viya

3 Likes

SAS servers have always used configuration files, read on server startup and used to make resources like data or files available to the server, and to set options to change behavior. In SAS Viya 2020, server startup configuration files for CAS and Compute sessions are no longer stored and maintained in operating system files. Instead they are persisted in the SAS Configuration server (Consul) and read from that location when the server is launched. In this post I will look at what this changes means for a Viya administrator.

In SAS Viya 3.x (and even SAS 9.4) users could edit "usermods" files on the file system to control server behavior and make resources available. To use the compute server as an example, two of they key "usermods" files available for customization by an administrator were:

autoexec_usermods.sas: contains SAS statements that are executed immediately after SAS starts
sasv9_usermods.cfg: specifies start-up options for the server.

The CAS server also had a set of lua files that were used to perform similar processing when CAS starts. For example, castartup_usermods.lua allows the administrator to make user-defined formats and global-scope caslibs available on server startup and also potentially load global-scope tables.

In the latest release of SAS Viya on Kubernetes these files are no longer available in a file system location. For an administrator this means that instead of using a text editor to change autoexec and config options, the updates are made in Environment Manager or using the configurations plugin to the sas-viya command-line interface.

Updating Startup Files in Environment Manager

Compute

Compute server startup configurations is now persisted in the Configuration Server (Consul) and the configuration is loaded to files in the /config directory inside the Compute pod when the Compute server is initialized.

In SAS Environment Manager you can edit the startup settings in the Configurations area. There are a few configuration definitions where you can make modifications that impact SAS sessions.

sas.compute.server applied to the SAS Compute server.
sas.batch.server applied to the SAS Batch server
sas.connect.server applied to the SAS/CONNECT Server.

Lets look at updating the Compute Server autoexec. The changes made here would apply to all SAS sessions launched from SAS Studio. Keep in mind that the following process also applies to the batch server and the connect spawner.

As an administrator in SAS Environment Manager navigate to the Configuration page and change the view to Definitions . Select the sas.compute.server configuration definition. There are three configuration instances that can be updated for compute.

Compute service: autoexec_code (loaded to /config/autoexec.sas) would have been autoexec_usermods.sas and contains SAS code that is run on server startup
Compute service: configuration_options (loaded to /config/sasv9.cfg) would have been sasv9_usermods.cfg and contains SAS configuration options defined for the SAS Session
Compute service: startup_commands: (loaded to /config/startupscript.sh) would have been sasenv_local and contains environment variables and other commands to be set or executed prior to startup of the SAS Compute server.

Edit the Compute service: autoexec_code configuration instance. In the contents property field, add the SAS code. Currently there is no syntax checking on anything entered in Environment Manager. Be careful editing the files as errors can break the server.

For compute servers there is no need to restart any services after this change. The changes will be effective when the next user launches a compute server by, for example, logging into SAS Studio. (The connect spawner does require a restart).

In addition to making server level changes for autoexec and config, changes can be made on the different Compute Contexts. To make changes at this level, In Environment Manager select Contexts > Compute Contexts, choose a Context and select Edit.

NOTE: With version 2020.1.1, configuration instances that allow start-up script modification(startup_commands) are disabled by default, but can be enabled by a Kubernetes Administrator.

CAS

CAS Startup files are surfaced in the same way. CAS server configurations are persisted in Consul and the configuration is loaded to /cas/config (located in the cas container on each CAS pod) when the CAS server is initialized. For each cas server instance (in this case cas-shared-default) the following configuration settings are available.

cas-shared-default: config ( loaded to/cas/config/casconfig_usermods.lua) sets environment variables and/or configuration options in the CAS server and sessions.
cas-shared-default : settings (loaded to /cas/config/cas_usermods.settings) sets environment variables in the CAS server and sessions.
cas-shared-default : startup (loaded to /cas/config/casstartup_usermods.lua)start-up scripts (load data and formats etc.) executed before a CAS users’ session connects to the CAS server (session zero).
cas-shared-default : logconfig (loaded to /cas/config/logconfig.xml) sets the level of logging levels for CAS.
cas-shared-default : delete is used delete/reset all configuration instances for the CAS deployment when the CAS server is shutdown or restarted.

NOTE: For releases 2020.1.1 and later, all the CAS configuration instances are disabled by default.To allow the SAS administrator to modify the scripts in the configuration instances, set SAS_ALLOW_ADMIN_SCRIPTS to TRUE in the sas-shared-config configMap. The CAS server does require a restart after making configuration changes. To restart the CAS server.

kubectl delete pod --selector 'app.kubernetes.io/managed-by=sas-cas-operator' -n $current_namespace

Automation

What if we want to automate the process of reading and updating the startup files This is possible using the configuration plugin of the sas-viya cli as described in this post. Step 1 Read the existing autoexec file from the configuration definition and write it to a file. This step grabs the id of the configuration instance and uses it to download the configuration using jq to extract just the code from the "contents" field.

/opt/bin/sas-viya configuration configurations download -d sas.compute.server -s compute |
jq -r '.items[] | select(.name=="autoexec_code") | .contents' > /tmp/compute_current_autoexec.sas

Step 2 Next create any new autoexec code in a file.

tee /tmp/autoexec_usermods.sas /dev/null << EOF
libname findata '/gelcontent/gelcorp/finance/data/';
libname hrlib '/gelcontent/gelcorp/hr/data/';
EOF

Step 3 Append the two files and store the contents of the new file in an environment variable. Make sure each line has a linefeed at the end as does the environment variable.

cat /tmp/compute_current_autoexec.sas /tmp/autoexec_usermods.sas > /tmp/compute_autoexec.sas

sed -i 's/$/\\n/' /tmp/compute_autoexec.sas
COMPUTE_AUTOEXEC=$(cat /tmp/compute_autoexec.sas)
COMPUTE_AUTOEXEC="${COMPUTE_AUTOEXEC//$'\n'/ }"

Step 4 Create the configuration JSON to include the updated code from the environment variable and then apply the update.

tee /tmp/compute-autoexec.json /dev/null << EOF
{
"items": [
   {
         "version": 1,
         "metadata": {
            "isDefault": false,
            "services": [
               "compute"
            ],
            "mediaType": "application/vnd.sas.configuration.config.sas.compute.server+json;version=1"
         },
         "name": "autoexec_code",
         "contents": "${COMPUTE_AUTOEXEC}"
   }
],
"version": 2
}
EOF

/opt/bin/sas-viya configuration configurations update --file /tmp/compute-autoexec.json

As you can see things have changed for the administrator in relation to the management of server startup files. Hopefully this post has given you a good overview of the changes For more information checkout:

Bueno · ‎04-06-2021

Teacher !