Configuring SAS Studio 4.1 while ensuring your changes survive updates

[#1]

SAS Studio 4.1 for SAS Viya® 3.1 has many configuration settings you can adjust. Some of them can be set in more than one place. In this article, we'll see how to change the root directory users see under the Files folder tree, and do it in such a way that your change is not lost when your Viya deployment and SAS Studio are updated.

SAS Studio 4.1 has a default configuration properties file at /opt/sas/viya/home/SASStudio/war/config/config.properties.  In a multi-machine deployment, you'll find this on the Viya host, the one serving SAS Studio, which was in the [sas-viya] host group during deployment.

The picture below shows part of this file, in MobaXterm's build-in text editor:

 The webdms.customPathRoot property highlighted in the screenshot above sets the root folder users see when they expand Server Files and Folders > Files (/) in SAS Studio. With no value set for this property, SAS Studio maps the Files root to the filesystem root folder on the Viya server:

 
With a value set for this property (important: read on before you change it, though!), you can have the Files folder start at another folder in the filesystem, instead of root.

Why might you want to do this? As an administrator, think about what you must do to:

• Create and secure filesystem directories for users’ work
• Backup and restore users’ work
• Manage disk space
• Migrate to newer versions of SAS
• Promote between environments (Dev -> Test -> Prod)

Each of these tasks is easier if user content is in known filesystem location(s). Administrators should constrain their users to allow them to put their content only in those location(s), by configuring SAS Studio, and also through a well-designed filesystem security model.

But you should NOT edit the config.properties file mentioned above to change this setting - or any of the other settings in it. If you did, the next time an administrator runs yum update, either directly or by re-running the SAS Viya deployment playbook, this file is liable to be overwritten with a new default version, and any custom changes you made would be lost.

Instead, to override the value for any of SAS Studio's configuration properties, you should do one of the following three things:

1. Add a line to the vars.yml file in your sas_viya_playbook directory, like the line in bold below, and then re-run your ansible deployment playbook so that ansible makes sure your Viya deployment is in the new desired state:
   
   
    
   When you have added the line above to vars.yml, and re-run the ansible deployment playbook, you will see a new line in /opt/sas/viya/config/etc/sasstudio/default/init_usermods.properties, like this:
   
   
    When the SAS Studio service starts up, it reads the config.properties file described above first, then this init_deployment.properties file, and then init_usermods.properties in the same directory. So, because they are read in that sequence, the order of precedence between these files is effectively:
   
   init_usermods.properties (read last, so always wins)  >
   init_deployment.properties (read second-last) >
   config.properties (in the home directory structure, read before the other two, values set can be overridden in either of the other two)
   
   Values specified in vars.yml would be re-configured in the init_deployment.properties file even if you undeployed and redeployed your Viya software. 
   
   
2. Manually add a line to the file /opt/sas/viya/config/etc/sasstudio/default/init_usermods.properties, like this:

   webdms.customPathRoot=/demo
   

   Here's what the modified copy of the init_usermods.properties file could look like:
   
    
   Restart SAS Studio on the Viya server to make it read its changed configuration properties, e.g.:
   

   [user@viya-host ~] sudo service sas-viya-sasstudio-default restart 

   Changes made to the init_usermods.properties file are preserved unless you completely uninstall and reinstall your SAS Viya deployment. They override changes made in the init_deployment.properties file in the same directory.
   
   
3. Add an additional task (or role) to your SAS Viya deployment playbook, which modifies the custom init_usermods.properties file as described above. This is considerably more effort, but would apply a configuration change which survives both updating SAS Viya, and uninstalling and reinstalling, and even deploying again (with the your modified playbook or a new playbook modified similarly) on another environment. For such a simple change which can easily be made by modifying vars.yml, there is little point going to all this trouble. But, if you wanted to make more significant post-deployment configuration changes to your SAS Viya deployment, you may choose to include this along with all the others in a custom ansible role, so that you could manage the ansible tasks which make all your custom configuration changes together, in the same place.

   


However you make your configuration change to the webdms.customPathRoot configuration setting, here is what the Files structure in SAS Studio should now look like, when it has restarted:

Now, SAS Studio users cannot so easily save files anywhere else on the filesystem, through the visual interface. Making this configuration change does not otherwise prevent users from saving files elsewhere using program statements, which is why managing end user's permissions at the filesystem level is also important.