SAS Viya backup and restore has recently introduced some exciting new features that offer greater flexibility in backing up and restoring SAS Viya Environments. In this post, I will provide an overview of these features, and discuss the advantages and disadvantages of each approach. This will help you determine which backup and restore strategy best suits your requirements.   As a reminder, the tools are commonly used in three main scenarios: restoring in place, SAS Viya 4 to 4 migration, and disaster recovery. Let’s start by taking a look at the classic backup and restore functionality that we have had since SAS Viya 4 was released.   SAS Viya Application Backup and Restore   Backup with SAS Viya application backup is the default. This is the functionality we have had available since the release of SAS Viya.   A backup includes a complete backup of PostgreSQL databases, Configuration Server, and CAS metadata and data. The PostgreSQL backup and restore are performed using pg_dump and pg_restore. These utilities make a complete copy of the database into and out of the backup package. CAS data and metadata are likewise copied in full to and from the package.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Backups can be used for disaster recovery, SAS Viya 4 to 4 migration, and in-place restores. While this method is versatile and can be used in all scenarios, it may run more slowly when working with large amounts of PostgreSQL data. Similarly, the CAS backup will be slower when the default caslibs contain large volumes of data.   Backup and Restore Using Provider-Specific Processes for PostgreSQL in addition to SAS Viya Application Backup   You can exclude the PostgreSQL data from the backup process and use the PostgreSQL provider to manage that part of the backup. To do this set the environment variable INCLUDE_POSTGRES=False in the backup configMap. A full backup excluding PostgreSQL includes a complete backup of the Configuration server, CAS metadata and data, but does not include any of the PostgreSQL databases.   The PostgreSQL database backup is managed by the PostgreSQL provider. No PostgreSQL data is written to the backup package. For more details on this approach check out this article which covers its usage on Azure using Azure Flexible PostgreSQL server. This approach can also be used in conjunction with the internal PostgreSQL server using the pgBackRest utility of Crunchy PostgreSQL.     The PostgreSQL provider must support Point-in-time restore (PITR). In addition, the retention period of the PostgreSQL backup and the SAS Viya backup should be synchronized to ensure both parts of the backup are available at the point in time selected for restoration. All backup and restore scenarios are supported, except in cases where internal Crunchy PostgreSQL is used; in these cases, only in-place restore is supported.   Both the backup and the restore process are significantly faster when using this approach. The backup PVC’s will require less storage space since no PostGresSQL data is included.   Backup and Restore Using Provider-Specific Processes for PostgreSQL and Incremental SAS Viya Application Backup   A recent addition to backup and restore functionality added the ability to incrementally backup CAS data. An incremental backup strategy involves storing only the data that has been modified since the last backup was taken. The first backup in the series is a complete backup, and the subsequent backups only store the modified or new data, which is the incremental differences. This approach helps to save time in performing frequent backups.   There are two parts to the CAS backup: the CAS metadata (permstore) and the CAS data in the default caslibs. This approach creates a full backup of CAS metadata but an incremental backup of CAS data.   To use this approach, you must: Enable the Viya incremental backup job. Use Provider-Specific Processes for PostgreSQL by specifying INCLUDE_POSTGRES=false The incremental backup job, when enabled, runs every day (except Sunday) at 6 am. The retention period of the PostgreSQL backup and the SAS Viya backup should be synchronized. In addition, to perform incremental backups, a periodic full SAS Viya backup is required.   Incremental backups are supported for all scenarios except when internal Crunchy PostgreSQL is used. Again, in the latter case only in-place restore is supported.  When using this approach there are significant improvements in the speed of PostgreSQL and SAS Viya backups, especially if you have a lot of data in the databases and/or the default caslibs. In addition, the volume of data stored in the backup PVC’s will be a lot smaller.   Comparison of Backup and Restore Approaches   The table below summarizes the 3 approaches.       The recent changes mean that for all scenarios your backup package looks a little different. The format of the backup ID has changed. The backup ID is a date timestamp value that uniquely identifies each backup.   The SAS-BACKUP-ID of the full Viya backup is in the format of YYYYMMDD-HHMMSSF (the F as it signifies that this is a full backup). For example, 20240228-160410F   The SAS-BACKUP-ID of an incremental backup is in the format YYYYMMDD-HHMMSSF_YYYYMMDD-HHMMSSI. For example, 20240228-160410F_20240301-120310I. The incremental backup ID's first timestamp refers to the last full backup, and the second to the last incremental backup.     In both cases, YYYY represents the year, MM represents the month, and DD represents the day of the month. HH represents the hour, MM represents the minute, and SS represents the second. All times are in UTC.   For SAS Viya 4 to 4 migration and disaster recovery, you must copy all backup packages, including one full backup and all related incremental backups, from the source to the target.   Wrap Up   SAS Viya has recently been updated to improve its backup and restore functionality, providing more flexibility in how the process is managed. With the new changes, it’s now possible to perform point-in-time restores of PostgreSQL and incremental backups of the CAS filesystem. This allows for more efficient use of resources and faster processing of backup and restore. If you’re not concerned about time and resource usage, the existing backup and restore process remains a good option that’s easy to use.   I would like to thank Dawn Schrader, Penny Downey, JK Min and Scott McCauley for their valuable input to this post.   Please check out the Backup and Restore documentation for more details:   Backup and Recovery: Workflows Perform a Restore Using Only SAS Viya Processes for All Content Perform a Restore Using Provider-Specific Processes for PostgreSQL Schedule an Incremental Backup Perform an Incremental Ad Hoc Backup Restore PostgreSQL Cluster from pgBackRest Backup Completely or Point-In-Time-Recovery (PITR)   Check these related blog posts:   Restore a Viya Backup with SAS Viya Backup and Database Point in Time Restore | Global Enablement & Learning Blog SAS Viya: Restore a Backup in 2023.10 and later. | Global Enablement & Learning Blog A first look and Backup and Restore in Viya 4 | Global Enablement & Learning Blog (sas.com)   Find more articles from SAS Global Enablement and Learning here. ... View more

Traditionally SAS Viya has relied on internal processes to perform backup and restore. A recent change has added support for using third-party functionality to backup the SAS Infrastructure Data Server portion of the Viya deployment. In this post I will introduce this new feature and demonstrate how you can use it, using a SAS Viya deployment on Azure Kubernetes Service (AKS).   It is important to note that this is an addition of functionality, not a replacement. Instead of a single workflow that uses SAS Viya application backup tools to perform a backup and restore, there are now two workflows available:   SAS Viya Application Backup Only SAS Viya Application Backup and Cloud-Provider for external PostgreSQL ​   To use the second workflow the PostgreSQL provider must support Point-In-Time-Recovery (PITR) of the external PostgreSQL server to a custom restore point based on date and time. Many cloud-provider databases do provide this functionality. For example, the Azure Doc states:   “Azure Database for PostgreSQL - Flexible Server automatically performs regular backups of your server. You can then do a point-in-time recovery (PITR) within a retention period that you specify.”   Check out this page for more details on Azure Database for PostgreSQL - Flexible Server   The benefit of using PITR is that it can be significantly faster to perform a restore than the traditional SAS Viya Backup which uses pg_dump and pg_restore The traditional approach can be very slow when there is a large volume of data in the PostgreSQL database.   Let's look at how to backup and restore using SAS Viya application backup and Azure Database for PostgreSQL - Flexible Server PITR.   Backup   To rely on the Azure Flexible PostgreSQL server point-in-time restore functionality for the SAS Infrastructure Server backup we will set a parameter that will exclude the Infrastructure Data Server from the SAS Viya Application backup. To exclude the SAS Infrastructure Data Server from the backup add the parameter INCLUDE_POSTGRES='false' to the sas-backup-job-parameters configmap. Add the following code to the configMapGenerator section of kustomization.yaml and perform a build and apply.   configMapGenerator: [... previous resource items ...] - name: sas-backup-job-parameters behavior: merge literals: - INCLUDE_POSTGRES="false" [...]   With the backup configMap updated, we can now run an ad-hoc backup. In this step, we start the backup job from the scheduled backup cronjob and give it the name sas-scheduled-backup-job-adhoc-001.   kubectl create job --from=cronjob/sas-scheduled-backup-job sas-scheduled-backup-job-adhoc-001   Follow the log of the backup job until it is completed.   kubectl logs -f job/sas-scheduled-backup-job-adhoc-001 -c sas-backup-job | gel_log   Check the job log to make sure the backup ran successfully.    Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   NOTE: in the previous command we pipe to a custom function(gel_log) that uses JQ to reformat the log from JSON to a more human-readable format.   If we review the backup package in sas-common-backup-data PVC there will be no /sas-common-backup-data/${backupid}/default/postgres directory because the SAS Viya Infrastructure data server PostgreSQL database was not included in the backup. The diagram below shows the overall process and result.     Restore   Prepare for Restore   The first step in the restore is to get the backup ID of the backup to restore. Each backup is identified using a timestamp value called the backup ID. When performing a restore that includes PITR we use the timestamp value to identify :   The SAS Viya backup package AND Restore "point-in-time" within the PosgtGresSQL backup.   In this step, retrieve the backup ID from the job that created the backup.   backupid=$(yq4 eval '(.metadata.labels."sas.com/sas-backup-id")' <(kubectl get job sas-scheduled-backup-job-adhoc-001 -o yaml)) echo Backup Id is: $backupid   Output:   Backup Id is: 20240104-150710   Recently the format of the SAS Viya backup ID changed. The new format of the backup ID is YYYYMMDD-HHMMSSF (the F can be ignored as it signifies that this is a full backup) In YYYYMMDD, YYYY is an integer that represents the year, MM is an integer that represents the month of the year, and DD is an integer that represents the day of the month. In HHMMSS, HH is an integer representing the hour, MM is an integer representing the minute, and SS is an integer representing the second. All time is UTC.   NOTE: the new backup ID format is backward compatible with the old format.   The restore point format for Azure Postgres PITR is YYYY-MM-DDTHH:MM: SSZ eg. "2021-05-05T13:10:00Z". You can use this command to convert the backup ID to the format of the restore point.   restorePoint=${backupid:0:4}-${backupid:4:2}-${backupid:6:2}T${backupid:9:2}:${backupid:11:2}:${backupid:13:2}Z:${backupid:12:2}Z echo Restore Point is: $restorePoint   Output:   Restore Point is: 2024-01-04T15:07:10Z:71Z   An important feature of PITR is that the process does not restore to the same PostgreSQL server instance. To restore you need to provide a new instance name, which should be unique. It's a good practice to have a naming convention for your instances as you may end up with multiple instances in a cluster. For our purposes, we will just prepend the backup ID to the existing Flexible PostgreSQL server name eg. ${backupid}-blitz-0331-rg-default-flexpsql. In this step, we create an environment variable with the new name.   RESTORE_DB_NAME=d${backupid,,}-${GELENABLE_PREFIX}-default-flexpsql echo Restored DB instance: ${RESTORE_DB_NAME}   Output:   Restored DB instance: d20240104-150710f-boxer-p02095-default-flexpsql   Perform Point-in-Time Restore   The restore can be performed in the Azure Portal or using the Azure CLI. In the Azure Portal select the Resource Group of your Viya Deployment. Under the listed resources, select the Azure PostGresSQL Flexible server. Within the flexible server under Settings on the right, select Backup and Restore. Follow these steps to restore:   Step 1. Select the Fast Restore option for the Automated Backup with the Completion timestamp before, but closest to the restore point.     Step 2. Select the radio button Select a custom restore point and provide.   The date and time of the restore point that matches the backup ID. Give the new database instance a unique name.     Select Review and Create and then Create.   The deployment of the new instance will start with the message "Deployment in Progress". When it is completed the UI will output the message "Your deployment is complete".  This will complete the restoration of the Viya Infrastructure data server. It is restored to the new instance name and in Azure you now have two instances, the Viya environment still points to the original instance. In the following steps of the restore, we will switch Viya to point to the restored instance.   Restore the SAS Viya Backup   When using PITR for the PostGresSQL database you must select a backup package that does not include the SAS Viya Infrastructure Data Server data. The restore process happens in two steps. These steps are summarized here and covered in more detail in my previous post.   Step 1 The Restore Job   Restores the SAS Configuration Server Stop the CAS Server(s)   Step 2 Clear the CAS PV's and restart CAS in RESTORE mode   Delete existing data from the CAS PV's Restores CAS data and content   Run the Restore Job   Firstly, identify the sas-restore-job-parameters configMap that needs to be modified. This step returns the config map for the restore job.   restore_config_map=$(kubectl describe cronjob sas-restore-job | grep -i sas-restore-job-parameters | awk '{print $1}'|head -n 1) echo The current restore Config Map is: $restore_config_map   Output:   The current restore Config Map is: sas-restore-job-parameters-hgd4ftbmmm   Edit the configMap to set the restore parameters.   SAS_BACKUP_ID to the backup ID of the package to restore. SAS_DEPLOYMENT_START_MODE to RESTORE. AUTO_SWITCH_POSTGRES_HOST to True. DATASERVER_HOST_MAP to map the name of the restored PostGresSQL Server.   We have stored these values in environment variables in prior steps. This code updates the restore configMap with the relevent values and checks the values have been updated.   RESTORE_DB_HOST=${RESTORE_DB_NAME}.postgres.database.azure.com kubectl patch cm $restore_config_map --type json -p '[ {"op": "replace", "path": "/data/SAS_BACKUP_ID", "value":"'${backupid}'"},{"op": "replace", "path": "/data/SAS_LOG_LEVEL", "value":"DEBUG"},{"op": "replace", "path": "/data/SAS_DEPLOYMENT_START_MODE", "value":"RESTORE"},{"op": "replace", "path": "/data/AUTO_SWITCH_POSTGRES_HOST", "value":"True" },{"op": "replace", "path": "/data/DATASERVER_HOST_MAP", "value":"sas-platform-postgres:'${RESTORE_DB_HOST}'"}]' kubectl describe cm $restore_config_map     Start the Restore Job from the Restore cronjob. This process will restore the SAS Configuration Server. In addition, it will stop the CAS server to prepare for restore of the CAS server.   kubectl create job --from=cronjob/sas-restore-job sas-restore-job   After giving the job some time to run you can check for specific messages in the log to check the status.   kubectl logs -l "job-name=sas-restore-job" -c sas-restore-job --tail 1000 | klog | grep "restore job completed successfully" -B 3 -A 10   IMAGE   Restore the CAS Server   With the restore job completed the second step will restore the CAS server. This process is covered at a high level here but is covered in more detail in this post.   The restore job has stopped all CAS Servers in the environment. To restore CAS, the CAS Server will be started in RESTORE mode and data and configuration will be restored during server startup. Firstly, let’s check that CAS is not running.   kubectl get pods --selector="app.kubernetes.io/managed-by==sas-cas-operator"   Output:   No Resources in yournamespace namespace.   The process uses two provided CAS scripts.   sas-backup-pv-copy-cleanup.sh deletes the existing data from the CAS PV's. scale-up-cas.sh starts the CAS server(s) in RESTORE mode.   Make the provided CAS scripts executable.       Restoring the data to the two CAS file PVCs requires a clean volume. Run the sas-backup-pv-copy-cleanup.sh script to clean up the CAS PVCs. This step deletes the existing data on the CAS permstore(cas-default-permstore) and CAS data(cas-default-data) PVCs.   ~/project/deploy/${current_namespace}/sas-bases/examples/restore/scripts/sas-backup-pv-copy-cleanup.sh gelcorp remove "default"   Startup the CAS Server   ~/project/deploy/${current_namespace}/sas-bases/examples/restore/scripts/scale-up-cas.sh gelcorp "default"   When the CAS server starts it checks the Restore Job configMap attribute SAS_DEPLOYMENT_START_MODE. If it is set to RESTORE, the CAS server will start and restore the data from the directory that matches the BACKUP_ID in the sas-cas-backup-data PVC.   Check the log to see if the CAS server performed the restore. The logs should show the start of the restore process that restores the backup content to the target CAS persistent volumes.   kubectl logs sas-cas-server-default-controller -c sas-cas-server | gel_log | grep -A 10 "RESTORE"   Finalize the Restore   To complete the switch over to the newly restored Postgres instance, restart all the services with the sas-stop-all and sas-start-all cronjobs. This code runs the stop job and waits for all the PODS on the namespace to stop before running the start and job and then waiting for Viya to start.   kubectl create job --from cronjobs/sas-stop-all restart-stop RUNNING_PODS=$(kubectl get pods --field-selector=status.phase=Running -o go-template='{{len .items}}') until [ $RUNNING_PODS -lt 2 ]; do echo Running Pods: $RUNNING_PODS; RUNNING_PODS=$(kubectl get pods --field-selector=status.phase=Running -o go-template='{{len .items}}'); done kubectl create job --from cronjobs/sas-start-all restart-start   To ensure that SAS Viya 4 is referencing the restored PostgreSQL instance, execute the following command for each PostgresSQL instance in the cluster. The command should show the address and services as the new name that you gave to the PostgresSQL database.   HTTP_PROTOCOL=https CONSUL_SVC_NAME=sas-postgres kubectl exec -it sas-consul-server-0 -c sas-consul-server -- bash -c "export CONSUL_HTTP_ADDR=$HTTP_PROTOCOL://localhost:8500; /opt/sas/viya/home/bin/sas-bootstrap-config catalog service $CONSUL_SVC_NAME" { "items": [ { "address": "d20240115-134651f-blitz-p02095-default-flexpsql.postgres.database.azure.com", "createIndex": 692506, "datacenter": "viya", "modifyIndex": 692506, "node": "sas-postgres", "nodeMeta": null, "serviceAddress": "d0240115-134651f-blitz-p02095-default-flexpsql.postgres.database.azure.com", "serviceEnableTagOverride": false, ........   Finally, we will reset the SAS restore job configMap parameters.   kubectl patch cm $restore_config_map --type json -p '[{ "op": "remove", "path": "/data/SAS_BACKUP_ID" },{"op": "remove", "path": "/data/SAS_DEPLOYMENT_START_MODE"} ,{"op": "remove", "path": "/data/AUTO_SWITCH_POSTGRES_HOST" },{"op": "remove", "path": "/data/DATASERVER_HOST_MAP"} ]'   The Viya manifests point to the PostgreSQL server used before the restore. An important final step ensures that when any future changes are made Viya continues to point to the restored server.  To ensure that Viya continues to point to the restored server update the manifests to point to the new host for the PostgreSQL server. The file to be updated is usually at $deploy/site-config/postgres /{ POSTGRES-SERVER-NAME }-dataserver-transformer.yaml. Here is an example of an updated file.   apiVersion: builtin kind: PatchTransformer metadata: name: sas-platform-postgres-dataserver-transformer patch: |- - op: replace path: /spec/users/0/credentials/input value: secretRef: name: platform-db-user usernameKey: username # For internal use, do not modify passwordKey: password # For internal use, do not modify - op: replace path: /spec/registrations/0/host value: d20240115-134651f-boxer-p02095-default-flexpsql - op: replace path: /spec/registrations/0/port value: 5432 - op: replace path: /spec/ssl value: true target: group: webinfdsvr.sas.com kind: DataServer version: v1beta1 name: sas-platform-postgres   Considerations   The Azure Flexible server for Postgres has a default retention period of 7 days. The retention period for the Postgres should be changed so that it is in synch with the SAS Viya backups. SAS Viya backups have a retention period of 30 days by default. Matching retention periods will ensure that if we need to restore a backup the required PostgreSQL and SAS data is available.   The restore process created a new PostGresSQL instance. You may need to keep the old and new instances around for a while to provide the ability to do a PITR during the 30-day retention period.   Wrap-Up   The addition of support for using third-party functionality to backup and restore the SAS Viya Infrastructure Data Server portion of the Viya deployment is a welcome update. This support depends on the database supporting Point-in-time restore. This addition adds flexibility to the SAS Viya Backup and Restore functionality and will be particularly useful when the volume of data stored in the Infrastructure Data Server is large. The SAS Viya Administration Backup and Restore documentation has been updated to cover the new workflow.     Find more articles from SAS Global Enablement and Learning here. ... View more

A SAS Model Studio project is a top-level container for analytic work in Model Studio. A Model Studio project contains the data source, the pipelines, and related project metadata (such as project type, project creator, share list, and last update history). SAS Model Studio projects are, by default, saved in Viya Content to the user’s “My Folder”. Content Migration of Viya Model Studio Projects has been troublesome in some cases because of the strict prerequisites. Now we have improved functionality that makes life easier. In this post, I will examine these improvements.   Firstly, what are the prerequisites? To import a Model Studio Project:   The user who owns the project must exist and must have logged on in the target environment​​ Before import, data must be available and loaded into the memory in the target environment (in the same caslib as in the source environment). A user-created pipeline or node template must be promoted separately.   For more details on these items see the documentation here.   These prerequisites, particularly the requirement that the user that owns the project must already exist and have logged in, have at times made it challenging to migrate Model Studio projects.  This requirement makes it difficult to migrate Model Studio Projects when the source owner: is no longer at the organization. doesn’t have authorization to the target. is a different user in the target. is the same in the target, but the user ID is managed differently. For example, on the development server, the id is dev_user1 and on the test server, the id is test_user1.   One solution to the problem is to change the ownership of a Model Studio Project to a user who does exist and has logged on to the target environment. In the past, there was no supported way to change ownership of a project. New functionality in the transfer plugin of the sas-viya CLI now allows an administrator to change the ownership of Model Studio Projects and other content types prior to import.   New functionality in sas-viya transfer   There are two methods to migrate Model Studio projects between environments you can export using: The transfer service using SAS Environment Manager or the sas-viya CLI, this creates a transfer package (JSON file)​ SAS Model Studio creates a ZIP file containing one JSON transfer file per project   The new method of changing ownership works with the transfer method of migrating. The process works like this: Use the transfer plug-ins list-owners command to generate an "owners list" JSON file from the transfer package Modify the generated file to map the old owner to a new owner Use the transfer plug-in replace-owners command and the edited "owners list" file's content to create a new transfer package file with the ownership of the content in the package changed.   NOTE: to be clear the ownership of the object is changed in the transfer package not in the source system.   Changing Ownership of Model Studio Projects for Import to Viya   Let’s look at the process in detail using an example. In this example, Sarah has some Model Studio projects in one Viya environment and she needs to share them with a different user in another environment.   She starts by using SAS Environment Manager to export a transfer package and shares that transfer package with the other user GEL Administrator (geladm).   Review the Transfer Package   Firstly, let’s review the content of the provided transfer package.   packageid=$(/opt/sas/viya/home/bin/sas-viya --output json transfer upload --file /tmp/viyapackages/SarahMyFolder.json | jq | jq -r '.["id"]') echo "View the package with id" $packageid sas-viya --output text transfer show --details --id $packageid   The output shows that the package contains the folder path to Sarah’s “My Folder” and the content of the folder which consists of the Model Studio Project and supporting resources.       Generate the  "owners list" file   The first step is to generate the "owners list" file from the transfer package. To do that we can use the new “list-owners” command pass it the transfer package file and output the results to an owners list file. The owner's list file is in JSON format and contains a map of the existing owner(sourceUserID) to a potential new owner(targetUSERID). The source and target are initially the same.     sas-viya transfer list-owners --source-file "/mnt/workshop_files/SarahModelStudio/SarahMyFolder.json" --owners-list-file /tmp/theowners.json [ { "sourceUserID": "Sarah", "targetUserID": "Sarah" }, { "sourceUserID": "anonymousUser", "targetUserID": "anonymousUser" } ]   Update the "owners list" file and change ownership   To change the ownership of objects in this package edit the file and change the targetUserID to the user in the target system who you want to own the content.     [ { "sourceUserID": "Sarah", "targetUserID": "geladm" }, { "sourceUserID": "anonymousUser", "targetUserID": "anonymousUser" } ]   Using the updated file create a new transfer package with the ownership changed from the user Sarah to the user geladm. Pass to the transfer replace-owners command: --source-file the source transfer package --owners-list-file the update owners list file --target-file a file to store the updated transfer package   sas-viya transfer replace-owners --source-file /mnt/workshop_files/SarahModelStudio/SarahMyFolder.json --owners-list-file /tmp/theowner-geladm.json --target-file /tmp/geladm-modelstudio.json     Notice the output indicates that the ownership in the package has been changed based on the content of the file. Simple as that. Of course, to truly test if this works we need to import the package.   Import the new transfer package file   In SAS Environment Manager import the package (you could also use the CLI). When we open the package in the Environment Manager import interface notice that the content will be imported to the user geladm’s personal folder. This is the first clue that we have successfully changed the ownership of the content.         After walking through the import wizard the summary screen shows the content, including the Model Studio projects was imported successfully into the My Folder area of the geladm user.     In the Content Area of SAS Environment Manager, we can see the content, originally owned by Sarah in the source environment is now owned by geladm and is located in geladm's "My Folder".         Wrap Up   When migrating Model Studio projects there are specific prerequisites required to ensure a successful migration. One of those requirements is that the user that owns the project must already exist and have logged in to the target system. This has at times made it challenging to migrate Model Studio projects. One solution to the problem is to change the ownership of a Model Studio Project to a user who does exist and has logged on to the target environment. New functionality in the transfer plugin of the sas-viya CLI now allows an administrator to change the ownership of Model Studio Projects and other content types prior to import.   For more information:   Content Migration Considerations for SAS Visual Data Mining and Machine Learning   Machine Learning Users Guide: Importing and Exporting Projects   ... View more

In previous posts published in the early days of SAS Viya on Kubernetes, I introduced the benefits of running the SAS Viya CLI inside a docker container and discussed how you can orchestrate Viya administration tasks using a CLI container and Argo Workflow. You can catch up on updated versions of these two posts here:   SAS administration command-line interface in a container: Part 1 Docker SAS administration command-line interface in a container: Part 2 Kubernetes and Argo Workflow   At SAS recent developments around orchestration and scheduling have focused on using Apache Airflow to schedule and manage flows. The SAS Airflow Provider allows SAS Viya administrators/power users to orchestrate SAS jobs and SAS Studio flows using Apache Airflow. Argo Workflow allowed us to orchestrate common administration tasks performed with the SAS Viya CLI. With the focus now on Apache Airflow I wondered if it could do the same. The short answer is yes, read on for the details.   Apache Airflow v Argo Workflow   Select any image to see a larger version. Mobile users: If you do not see this image, scroll to the bottom of the page and select the "Full" version of this post.   Firstly let's compare the two applications. Apache's Airflow and Argo Workflows are two of the most popular workflow engines available. A workflow engine is a platform for scheduling, starting, stopping, organizing, and monitoring flows containing sets of related tasks. How do Apache airflow and Argo workflow compare? First, the similarities. They both use Directed Acyclic Graph (DAG). A DAG models multi-step workflows as a sequence of tasks and includes the dependencies between tasks. They can both be used in Kuberenetes, Argo is entirely Kuberenetes native while Airflow is Kubernetes-friendly, and can be run in a Kubernetes cluster to take advantage of the increased stability and autoscaling options that Kubernetes provides. The big difference between the two is how you define your DAG workflows, in Argo you define them in YAML whereas in Airflow you define them in Python. (You have to say that Argo does have the cooler logo :))   Apache Airflow and the SAS Viya CLI   Apache Airflow is modular and can interface with other software by installing additional packages, called providers or operators. The SAS Airflow Provider is a good example of this, it was created to allow Airflow to run SAS processing. Other commonly used operators include, for example, the Bash operator and the Python operator. The Bash operator can run shell scripts or a set of commands and would be one option for running the sas-viya CLI commands. You can see an example of this in Michael’s post here. However, the obvious choice for us is the Airflow KubernetesPodOperator which executes a task defined as a Docker image in a Kubernetes Pod. Let’s look at how we run our sas-viya administration workflow with Airflow and the KubernetesPodOperator.   In our environment, Apache Airflow is installed and configured in Kuberenetes as described in Nicolas's post here. One of the key aspects of integration is that the environment is configured so that Airflow DAGs (Python scripts) are automatically discovered by the Airflow framework when they are saved in a specific directory.   Define and Run an Administrative Workflow   Here is how we define and run a Viya administration workflow in Airflow. Our flow will automate the performance of the initial administration tasks for a new Viya environment. It will:   Setup identities Create a folder structure Apply an authorization schema to the folder structure Create Caslibs for data access Load Data to CAS Apply CAS authorization Load Viya Content Validate that the previous steps were successful   The first thing we need is a container image that includes the CLI and any dependent software. How we achieve this was covered in this post. Next, we define our Python script, which will create the flow. Let’s take a walk through the script.   At the start, we import the Python Packages we will need in the script. Then define the Volumes, Volume mounts in a Python list, and the environment variables in a Python dictionary. These elements will be passed to the KubernetesPodOperator. The ConfigMap volumes make the CLI configuration and credentials file and the Viya environment certificates available to each POD. The environment variables define the CLI profile to use and the paths to the certificate files. When the POD for each task is started the environment variables will be set and the volumes mounted.     Next, we create the DAG giving it a name (01-load-content-flow) and setting default attributes including the schedule, start date, etc. In our example, we are going to create a flow that is not scheduled and we will trigger it manually in the UI. If you want to provide a schedule you provide it in Cron format.     Following the DAG we define the tasks. Each task in our case uses the KubernetesPodOperator and will run a script that contains SAS Viya CLI commands. For each task, we provide the container image, give the task a name, and reference the volume, volume mount, and environment variables. We pass the bash -c command with a single argument which is the script that will run. Each script contains CLI commands that achieve the result of the task.     The final part of the Python program defines the dependencies for the tasks in the DAG.     Save the Python program to our directory that Airflow is configured to monitor and the DAG is imported to the Apache Airflow and we can view it in the application. Notice the dependencies setup in the DAG definition are honored.  As was mentioned before the flow can be scheduled or triggered from the UI.     The application also allows you to monitor flows.  The screenshot below shows a flow in progress, the color-coding shows that 5 tasks have been completed successfully, one task is running and the final two tasks are waiting to start.     When tasks are running or complete you can view the logs. In the screenshot below from the data load task we can see messages indicating that the data is being loaded to CAS.     You can also use tools like kubectl or Lens to monitor the process.  A kubectl get pods shows a completed POD for each task in the flow (pods can also be automatically deleted on completion).   kubectl get pods -n airflow | grep task     Wrap-Up   In this post we have looked at two Automation and Workflow Management tools; Apache Airflow and Argo Workflow. Both applications provide similar functionality. The main difference between the two applications is the language used to define flows. Apache Airflow uses Python and Argo Workflow uses YAML. Apache Airflow can be run in and take advantage of Kubernetes. In a prior post, we automated the execution of Viya administration tasks with Argo Workflow. In this post, we demonstrated that you can automate, schedule, execute, and monitor SAS Viya administration tasks using Apache Airflow, a containerized SAS Viya CLI and the Airflow KubernetesPODOperator.     Find more articles from SAS Global Enablement and Learning here. ... View more

Users of SAS Software are used to accessing external resources. Many of them store their SAS code and data in files located in directories in the file system. They then access the data in SAS libraries and path-based CAS libraries and the code from SAS clients. In SAS Education this is also the case for our workshop environments. In developing the Viya 4 Administration workshop our initial goal was to take our Viya 3.5 Administration environment and get functional equivalence in Viya on Kubernetes. In this post, I will look at how we secured our OS resources in Viya and Kubernetes.   In our Viya 3.x workshops we use a fictional company Gelcorp that has multiple business units Sales, HR, Finance, etc. Each BU has a group in LDAP and the Viya and OS resources are secured to the groups so the Sales cannot see Marketing and vice-versa.  In Viya 3.x:   Identities come from LDAP and users are grouped into Business Units (Sales, Marketing, etc.) System Security Services Daemon (SSSD) is configured on the LINUX server data and files are stored on a Network File System (NFS) I don't want to go into detail about how the security mode is implemented. To summarize the access pattern for a user is established based on their group and secondary group membership.   The permissions structure is shown in the table below. The impact of the settings is that a user can access resources for the groups they are members of, but cannot access resources for other groups. For example, Sally a member of the Sales group can access files in /gelcontent/gelcorp/sales/code but not in /gelcontent/gelcorp/hr/code.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Storage in Viya 4 Viya 4 runs on Kubernetes, it is different. The way you make the physical locations available is different. External storage can be made available using Persistent Volumes.  My colleague Steve Foerster also provides a really nice summary in this article.   In Viya 4 (like Viya 3.x) these OS resources must be secured so that they can be accessed by service accounts running SAS processes and by specific users and groups.​   Identities In Viya 4 identities can be either read from LDAP or loaded from a SCIM provider. In our case, we use the same LDAP provider as in our Viya 3 environment. The LDAP provider holds the users' POSIX attributes including primary and secondary group IDs. The data on our NFS share is secured using the identities of the provider.   In Viya 3.5 SSSD is the method we use to return identity information from LDAP to the OS. System Security Services Daemon is a system daemon. Its primary function is to provide access to local or remote identity and authentication. By default in Viya, SSSD is turned off for CAS and Compute, and all identity information is returned by the Identities service.   Let's look at one user on the system, Henrik to see how identity information is returned   Outside the pod on the NFS server, the id command shows the identity information of Henrik(4015) who has a Primary Group of sasuser(2003) and is a member of one secondary group HR(3001)         id Henrik           We can use a new pyviyatool getposixidentity.py to get the identifier information for Henrik that is stored in the Identities service. The names of the groups are not available from identities but the group IDs match what was returned by the id command.         /opt/pyviyatools/getposixidentity.py -u Henrik -o simplejson           What Identity Runs the Process? In order to determine how to secure the content on the filesystem we need to understand what identity runs the process. By default, it is different for CAS versus Compute.   Compute sessions:​ sessions are launched by the SAS Launcher Service and run as the requesting user by default.​ All Operating system access is by default by the user account.​ CAS sessions:​ by default, run as a process inside the CAS controller as the CAS service account (sas: uid=1001, gid=1001). ​ All Operating system access is by default by the service account.   To see this in operation and understand the implications for securing our OS content we can use the user Henrik and launch a compute and a CAS session. In Studio we run a SAS Program that will list our user ID, home directory, and the name of the compute pod that was launched. The program also starts a CAS Session.     To see the user running the compute session use kubectl to exec into a container in the pod that was launched to perform the SAS processing. Inside the container run the id command. The result is that the process is running as Henrik (4015) and the primary and secondary groups have been returned by the identities service.          kubectl exec -it $(kubectl get pod -l launcher.sas.com/requested-by-client=sas.SASStudio,launcher.sas.com/username=Henrik --output=jsonpath={.items..metadata.name}) -- bash -c "id"           For CAS we don't get a separate POD per session, we get a different process inside the CAS container on the CAS controller. We exec into the CAS container in the CAS controller pod. and execute the ps command we can see a CAS session running under the shared account (1001).   kubectl exec -it $(kubectl get pod -l casoperator.sas.com/node-type=controller --output=jsonpath={.items..metadata.name}) -c cas -- bash -c "ps -ef | grep 1002"   As you can see CAS and Compute behave differently. CAS, by default, uses the shared account, and Compute uses the requesting user's account.   Standardize Configuration For the compute server our setup is done. The OS permissions on the mounted directories will be honored because the compute sessions run as the requesting user and the Viya environment is using identity information from the same LDAP server as the NFS server.  For CAS we have some choices to make.   Firstly, we could ensure that in LDAP the Shared account has the group membership of all the business units via its secondary groups. If that were the case then the shared account would be able to access the data for the requesting user.  If the current shared account does not have this access pattern CAS can be configured to run as a different account.   Perhaps a more straightforward approach is to configure CAS so that the sessions run as the identity of the requesting user. To configure all CAS sessions to run as the requesting user's identity, set the CASALLHOSTACCOUNTS environment variable. Alternatively, adding specific users to the CASHostAccountRequired custom group will make CAS sessions for those users run as the identity of the requesting user. To test the difference let's use the last approach for the user Henrik.   Firstly, create the CASHostAccountRequired group and add Henrik as a member.   sas-viya --output text identities create-group --id CASHostAccountRequired --name "CASHostAccountRequired" --description "Run CAS as users account" sas-viya --output text identities add-member --group-id CASHostAccountRequired --user-member-id Henrik   Now run the SAS Program again and use the same command to check the process owner of the CAS session. Now we will see there is a process for Henrik(4015) in the CAS container of the CAS controller. The CAS session is running under the identity of the requesting user and the access pattern will be governed by that user's identity information.   kubectl exec -it $(kubectl get pod -l casoperator.sas.com/node-type=controller --output=jsonpath={.items..metadata.name}) -c cas -- bash -c "ps -ef | grep 4001"     With CAS and Compute standardized and the Viya deployment using the same LDAP server as the NFS server we can use the same group and secondary group membership techniques to secure resources that we do in a non Kubernetes Viya deployment.   This post has talked about securing data on NFS using POSIX attributes. In the cloud, there are many more storage options available and other options for identities where POSIX attributes are not available. That is a topic for another day.   For more information: Stuart Rogers blog on SAS Viya Secondary Groups and Posix Considerations CASHOSTACCOUNTREQUIRED and CASCLOUDNATIVE documentation   I would like to thank my colleagues @GillesChrzaszcz and  @StuartRogers, who were companions on this journey during the early releases of Viya 4.   Find more articles from SAS Global Enablement and Learning here. ... View more

POSIX attributes like UID and GID, and Secondary GID are vital elements of an operating system-level security model. In SAS Viya POSIX attributes can often be returned from the identity provider.  But what if your identity provider does not return POSIX attributes? In this post, I will look at the current default Viya behavior and how you can still use POSIX attributes to secure access to shared resources even when your identity provider does not return them.   The two main POSIX attributes we will focus on are UID and GID. UID and GID are the numerical equivalents of the username and primary group name referenced by the operating system and applications when determining access privileges. For example, every file and directory on a Linux system has an owning user and group.  When you want to share folders or files between groups of users or with another system you often use UID, GID, and Secondary GID information to determine who can access file system resources like SAS programs, CSV files, and SAS datasets.  In a previous blog post, I discussed securing OS resources that reside on the file system in SAS Viya 4.   Viya and POSIX attributes default behavior During the lifetime of SAS Viya, there have been some changes in how POSIX attributes are returned and managed. Let's first look at the current (2023.04) defaults. The identities service is the service that manages POSIX attributes. The following properties of the identities service determine the behavior:   sas.identities.identifier.disableGids : disables the lookup and generation of GIDs for users and groups. The default value is false sas.identities.identifier.generateGids: generates GIDs for users and groups. The default value is false. sas.identities.identifier.generateUids:  generates UIDs for users. The default value is true.   The default values for a Viya Deployment can be viewed in Environment Manager or surfaced using the configuration plug-in of the sas-viya cli.     sas-viya configuration configurations show --id $(sas-viya configuration configurations list --definition-name sas.identities | jq -r '.items[0]["id"]') | grep identifier         identifier.generateUids : true identifier.generateGids : false identifier.disableGids : false     As you can see, by default, with SAS Viya platform 2022.10 and later releases the identities service: always provides a generated UID allows you, as a SAS Administrator, to provide GID values   In our SAS Viya Administration course environment, we have an LDAP server that can return POSIX attributes and we keep the default settings for the identities.identifier properties. Let's use the user Delilah to demonstrate the resulting behavior. In SAS Environment Manager we see that Delilah is a member of the GELCorp Power Users, HR, and SAS Users groups.     We can check the POSIX attributes of Users and Groups using the identities plug-in of the sas-viya CLI. Here using the show-group command and --show-advanced option we see that HR has a GID of 3001, SAS Users has a GID of 2003 and Power Users has a GID of 3007. These values were read from our LDAP server because it can return the POSIX attribute and we are using the default setting identifier.generateGids : false.     sas-viya --output text identities show-group --id HR --show-advanced sas-viya --output text identities show-group --id sasusers --show-advanced sas-viya --output text identities show-group --id powerusers --show-advanced       Using the show-user command and the --show-advanced option we can see that the UID of the user Delilah is a generated value.     sas-viya --output text identities show-user --id Delilah --show-advanced       The default behavior when the UID is generated for a user is their primary GID (returned as just gid from the identifier endpoint) is always set to the same value as the UID. At first glance, this can be confusing. However, notice that secondaryGid values are populated with the GID’s read from LDAP for the groups that the user is a member of sasusers[2003], powerusers[3007], and HR[3001]   The default settings where GID is provided but UID is generated are useful when accessing data where a file system security model already exists and is developed based on Secondary GIDs. There might be times when the actual UID is important to the security mode. In these cases, we can just update the value of identifier.generateUids to true. In our case where LDAP does provide the POSIX attributes the UID values will then also be read from LDAP.   Generating POSIX Attributes In Viya environments where the identities service is configured to use SCIM, and in many where it is configured to use Active Directory, POSIX attributes are not returned. In this situation, where the identity provider cannot return the POSIX attributes, the SAS Viya Identities service will, for each user, automatically generate a UID and optionally a GID.   To generate the POSIX attributes the identities service will:​​   use the identity type (either USER or GROUP) along with the identity name  (e.g Delilah) and generate an SHA hash Map the SHA hash onto numerical space to generate the UID and GID values   Let’s look at the attributes for Delilah in another environment where the POSIX attributes are not available from LDAP. In this Viya on Azure environment, POSIX attributes are not available and Delilah has a slightly different group membership.     In this environment, in order to generate the POSIX attributes(UID and GID )the identities.identifier properties are set as follows. identifier.generateUids : true identifier.generateGids : true identifier.disableGids : false Let's look at what is returned for Delilah and the two Groups. The output shows we are returned both generated UID and GID values.     sas-viya --output text identities show-user --id Delilah --show-advanced sas-viya --output text identities show-group --id HR--show-advanced sas-viya --output text identities show-group --id PowerUsers --show-advanced       The generated UID and GID values can be problematic in managing access to file system content. If your filesystem content is shared with other applications and secured using existing UID, GID, and Secondary GIDs then the generated values will not match the existing values. As a result, many SAS processes will not be able to read the filesystem content. To address this problem Viya allows an administrator to provide POSIX attributes.   Providing POSIX Attributes There are two ways to use existing POSIX attributes. We have seen the first one where the attributes are read from the Identity Provider. Now we will look at the second approach where we load POSIX Attributes. POSIX attributes can be loaded to SAS Viya using the sas-viya CLI. This can be done for individual users, or you can bulk-load multiple users and groups from a CSV file.   The first thing we need to do if we want to switch to loading UID and GID is update the identities.identifier properties so that the POSIX attributes are not generated. In SAS Environment Manager under Configurations, select Definitions and sas.identities. Toggle identifier.generateGids and identifier.generateUids to the OFF position.     You can also make the same change using the configurations plugin of the sas-viya CLI.      If we look at Delilah after we change the properties notice, we no longer have POSIX attributes returned. At this point, our identity provider does not return POSIX attributes and we have not loaded any to the identities service (NOTE: the display is a little misleading the value for the UID and GID are not actually the number zero).     The identities plugin of the SAS Viya CLI can update individual UID/GID information. The sas-viya identities update-user command will update UID and primary GID  for a user, the update-group command updates the GID  for a group. For example, to update Ahmed:     sas-viya --output text identities update-user --id Ahmed --uid 4005 --gid 2003     This is useful for updating a single user or group. Using the CLI after 2022.10 you can use the bulkload-user-identifiers command to update multiple the UID and GID for multiple users from a CSV file. The format of the CSV file for users is:   Column 1: identity type (USER or GROUP) Column 2: identity name Column 3: numeric UID Column 4: numeric primary GID Here are a few lines from an example CSV.     USER,sasldap,1003,1003 USER,sasadm,2002,2002 USER,sastest1,2003,2003 USER,sastest2,2004,2003 USER,geladm,4000,2002 USER,Douglas,4001,2003 USER,Delilah,4002,2003         sas-viya --output text identities bulkload-user-identifiers -f "gelcorp_user_csv.csv"       Similarly, there is bulkload-group_identifiers command The format of the CSV file for groups is:   Column 1: identity type (USER or GROUP) Column 2: identity name Column 3: numeric GID Here are a few lines from an example CSV.     GROUP,HR,3001 GROUP,Sales,3003 GROUP,Finance,3004 GROUP,Managers,3002 GROUP,powerusers,3007     To bulk-load user POSIX attributes use bulk-load-group-identifiers     sas-viya --output text identities bulkload-group-identifiers -f "gelcorp_group_csv.csv"       NOTE: if you are using a release before 2022.10 this can also be accomplished with the setposixattributes.py tool of the pyviyatools.     If we run the show-user command now we will see that the UID and GID have been loaded from our CSV files to the identities service and the Secondary GIDs are available.     sas-viya --output text identities show-user --id Delilah --show-advanced       There is not an easy way to do this for all users using the sas-viya CLI but we can use one of the pyviyatools getposixidentity.py to get a list of the attributes for all users and groups.     /opt/pyviyatools/getposixidentity.py -o csv       Ongoing Maintenance When using this model of providing UID and GID information to identities service the administrator needs to be aware of the ongoing maintenance task of setting the UID and GID values when a new user is added to the identity provider. Failure to override the POSIX attributes when a new user is added will most likely result in the user not being able to access resources in the Viya system.   Wrap-up POSIX attributes like UID and GID, and Secondary GIDs are vital elements of an operating system-level security model. SAS Viya will often need to use POSIX attributes when accessing files on shared file systems. In this post, we looked at how Viya can access POSIX attributes. We looked at two scenarios, the first in which POSIX attributes were read from the LDAP identity provider. The second was where POSIX attributes were not available from the Identity Provider. In the latter case, we saw how Viya can generate POSIX attributes and how we can override the generated values. Thank you to my colleague Stuart Rogers for his input on this post. I have listed some additional resources below, in addition to these the Viya 4 Administration guide has an excellent section on "How to manage UIDs and GIDs with the identities service".   Additional Resources SAS Viya 2022.10 UID and GID Changes   SAS Viya Secondary Groups & POSIX Considerations   Accessing AWS S3 as NFS from CAS and SAS – Part 3   Group-based access to Azure Files in the new SAS Viya   ... View more

User-defined formats are long-term SAS features that are very powerful and often used by SAS programmers and developers. User-defined formats can be used to change how data is displayed and can provide a means to do data conversion and even table lookups. When SAS introduced CAS as a new in-memory analytical engine it included support for using SAS formats. However, there are significant differences in the way CAS treats formats to the way the SAS Programming run-time servers (Base SAS) do.  With the release of the SAS Viya platform running on Kubernetes and the focus on migration from SAS 9.4 to Viya, it is worth taking another look at how you make User-Defined formats available to CAS.   User-defined formats in CAS Overview   User-defined formats in the SAS Programming run-time (9.4 or Viya Compute) are stored and read from SAS catalogs inside a SAS Library. In Viya the CAS server cannot read SAS catalogs. To use formats the CAS server requires formats to be stored in a CAS Format library inside a CAS Library.   To make formats available to the CAS Server SAS catalogs must be converted to a CAS Format Library (sashdat file). The CAS Format Library must be:   promoted to global added to the Formats path-based CAS library added to the CAS server format search path.   NOTE: The CAS format library is a .sashdat file. However, the .sashdat files are in a different format from the .sashdat files that contain data.   Let us look at the out-of-the-box configuration for user-defined formats in Viya 4. The standard install sets up a global path-based CAS library named Formats. The CAS library is physically located on the cas-default-data CAS persistent volume and is mounted into the CAS Controller at /cas/data/caslibs/formats/. In Viya 4, unlike Viya 3.x, there are no default CAS format libraries available in the CAS library.      How to make user-defined formats available   There are two levels of access to format administration in Viya.   A SAS Viya Administrator can manage formats in existing CAS format libraries including:   Create new formats Edit existing formats Copy and delete formats Import formats from an: Item store file accessible from the CAS controller SAS catalog file accessible from the machine that runs the compute service sashdat file accessible from the CAS Controller   In addition to all the above functionality, a SAS Viya administrator that is also a CAS Super User can create and delete CAS format libraries and manage the CAS format search path.   File Types available for import   The three types of files from which we can import formats are a SAS catalog, a SAS item store, and .sashdat file. Let us look at the differences.   SAS Catalog   Customers migrating from SAS 9.4 will likely import their formats from SAS Catalogs. LINUX catalogs can be imported directly, catalogs from other operating systems must be exported using PROC CPORT and imported using PROC CIMPORT. A SAS catalog file must be encoded in UTF-8 to import. If your catalog is already UTF-8 then you can import it directly. If your catalog is not UTF-8 then you can convert it to UTF-8 (CPORT and CIMPORT), or convert it to a SAS item store and import the item store.     SAS Catalog files can be imported from locations accessible to the Viya Compute Server. The files must have the extension .sas7bcat.   SAS Item store file   A SAS item store is a file that can contain multiple format libraries. The FMTC2ITM  procedure can copy the formats in one or more format catalog to a single item store physical file. The item store can be convenient as it allows you to package server SAS catalogs into a single file for import. In addition, PROC FMT2CITM can convert natively encoded catalogs to UTF-8(the default encoding on Viya). The example code below shows two SAS catalogs being added to an item store.   /* create itemstore with all formats in one file*/ proc fmtc2itm catalog=(sformats.formats hformats.formats) encoding=wlatin1 print locale itemstore="c:\temp\cport\itemstore\allformats.itemstore";   SAS Item store files can be imported from locations accessible to the Viya CAS Controller. The files must have the extension .itemstore (or no extension for import with the sas-viya CLI)   NOTE: the FMTC2ITM procedure is available in SAS 9.4M3 and later.   SASHDAT file   For customers already on Viya, if you have an existing CAS format library stored in a .sashdat file, it can be imported to a different Viya environment. SASHDAT files can be imported from locations accessible to the Viya CAS Controller.   Making files available for import to Viya   Prior to import the files containing the formats must be copied to a location accessible to either  CAS or Compute. This can be a little bit more complex in Viya 4. In most cases, a Viya 4 environment will have a shared storage location mounted from a location outside the cluster to the CAS and Compute servers. This is the location where you can copy the files that contain your formats. In addition, this location must be in the allowlist for the selected server. For more details on this topic see this post:  Accessing path-based data from CAS in Viya 4     In rare situations where you do not have shared storage, a Kubernetes Administrator can copy files to the CAS controller using the Kubernetes command-line interface (kubectl).   kubectl cp "/shared/gelcontent/gelcorp/cport/itemstore/allformats.itemstore" sas-cas-server-default-controller:/tmp -c sas-cas-server Interface to import user-defined formats   There are three interfaces available to import user-defined formats. All the interfaces support the three types of files.   SAS Environment Manager   SAS Environment manager provides a visual user interface to manage formats. A Viya Administrator who is a CAS Super User can create and manage format libraries and import formats. The details are documented at SAS Help Center: Managing User-Defined Formats in SAS Viya Platform: Manage Format Libraries     A Viya Administrator (not a CAS Super User) can create new formats, edit existing formats, and import formats to existing CAS format libraries. The details are documented at SAS Help Center: Managing User-Defined Formats in SAS Viya Platform: Manage Formats   NOTE: the file extension of the source path option can be .sashdat, .sas7bcat, or item store. The file extension triggers what type of import occurs.   CAS plug-in to the sas-viya command line interface   The CAS plug-in to the sas-viya command allows the administrator to create format libraries, update the format search order, and import formats. The command below performs all these tasks in one step.   ./sas-viya cas format-libraries create --server cas-shared-default --format-library hrformats --search-order prepend --source-path /gelcontent/gelcorp/hr/formats/formats.sas7bcat --su NOTE: the file extension of the --source-path option can be .sashdat or .sas7bcat any other file extension is treated as an item store. For more details on all the tasks you can perform with the sas-viya command check out SAS Help Center: CLI Examples: Formats   SAS Code   You can also use SAS Code to manage user-defined formats in CAS. For more details check out this documentation at SASHELP: Using User-Defined Formats in SAS Cloud Analytic Services: Migrate User-Defined Formats from SAS to CAS   CAS Format Library persistence   In previous versions of Viya, there were additional steps required to persist CAS format libraries across CAS server restarts. In Viya 4 there are no added steps needed. CAS format libraries persist across CAS server restarts by default. For more details on this change check out this post. SAS Viya CAS Format library persistence   Summary   If a CAS table has columns that reference user-defined formats, the formats must be made available to the CAS server. CAS cannot directly read SAS catalogs that store user-defined formats. They must be converted to a CAS format library and stored in a .sashdat file in the Formats path-based CASLIB. A Viya administrator can perform the steps to import formats using SAS Environment Manager, the sas-viya command-line interface, or SAS code.   For more information.   CAS Documentation: User-Defined Formats in CAS Viya Platform Administration Guide: Managing User-Defined Formats in SAS Viya Platform Viya Administration Guide: Formats (CAS) CLI Examples Thanks to my colleagues  @ScottMcCauley, @ChristianaLycan, and Gregor Hermann for their input on this post. Look for an upcoming post from Gregor on using user-defined formats with VA on Viya. ... View more

SAS 9.4 M8 release is the latest release of SAS 9.4. The main purpose of the 9.4 M8 release is to address security vulnerabilities. In this post, I will look at some considerations for customers updating their deployment from an earlier maintenance release of SAS 9.4 to M8. I will look briefly at what has changed in M8, review the approaches to upgrading to M8, and look at changes to the System Evaluation application that is key in preparing for a move to M8.   What is new in M8   I am not going to go into details on all the changes in SAS 9.4 M8 in this post. Please checkout Margaret Crevar's SAS Communities Post for that detailed information. Some key aspects of the release are:   A number of operating systems versions are no longer supported SAS private JRE is updated to Java 11 The HP-UX platform is no longer supported The list of retired SAS products has expanded Some SAS Solutions are not supported at the initial release Many third-party components have been updated or replaced Getting to SAS 9.4 M8   In a previous post, I looked at the various ways you can upgrade a SAS 9 deployment.  As a reminder, there are three main approaches (for the details check out the previous post). Each approach has its own pros and cons and each could be used to get to M8. Checkout the post for details.     In this post, we will focus on Update-in-Place, with a detour into Automated Migration. Update-in-Place is the process of modifying an existing SAS Deployment to apply maintenance or add and update SAS products. Update-in-place is only supported within a major SAS release. For example, you can use update-in-place to update SAS 9.4 deployment from earlier maintenance to 9.4 M8, however, you cannot use update-in-place to transition a 9.3 deployment to SAS 9.4. The update modifies the existing deployment rather than creating a new deployment.   System Evaluation and 9.4 M8   A key step in the update process is to run the System Evaluation application. System Evaluation is delivered with Content Assessment and is designed to help customers prepare for an update-in-place of SAS 9.4. System Evaluation examines a SAS Deployment it looks for possible issues that could adversely affect updating from one release of SAS 9.4 to another.   With the release of SAS 9.4 M8, this is a good time to take another look at System Evaluation. My colleague @ScottMcCauley looked in detail at System Evaluation in a previous post. This post is still very useful, and I would encourage you to read it. In this update, I will concentrate on specific items relating to System Evaluation and updating to SAS 9.4 M8.   To get the System Evaluation application download Content Assessment from support.sas.com.   Content Assessment is updated each month. When updating to SAS 9.4 M8 make sure you use the System Evaluation application delivered with the Content Assessment 2023.01 or later.   System evaluation should be run before any update-in-place of a SAS 9.4 environment. It should be run   Using the SAS install account On each machine in your deployment with a SAS Configuration Directory Some common System evaluation findings in M8   Products Retired   Several products have been retired and are not available on SAS 9.4 M8. System Evaluation will identify these products. The System Evaluation report lists any retired products in the deployment and provides a link to the documentation on “Removing SAS Configuration”. You can use the SAS Deployment Manager to un-configure any retired products prior to the update. A best practice is to unconfigure retired SAS before you update to M8 and to uninstall them after you update. System Evaluation provides a link to the documentation on removing the configuration.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Operating System Supported?   With SAS 9.4 M8 several operating system versions have been deprecated.   System Evaluation helps with this issue by providing information on the Operating System(OS) of the SAS 9.4 environment. In addition, on the System Evaluation Summary report under “Helpful Links” is a link to support.sas.com where you can check if your current Operating System release is supported for SAS 9.4 M8.   In some cases, to assist with this issue, System Evaluation may identify your specific current operating system and release.  In others, you may need to perform additional steps on your environment to get the details of what release of an Operating System you are running.     For example, the output above shows we are on the Linux OS but does not give the version of Linux or the release number. This is information you will need to determine if your current Operating System is supported.   How you identify the release of your Operating System varies by the type of OS. The best way to determine a Linux distribution name and release version information is by using the cat /etc/os-release command, which works on almost all Linux systems. (if you are on a different OS I recommend Googling “how to I identity the version of my <insert your os here> operating system?", you will find plenty of information on the internet)   cat /etc/os-release      Once you have determined the release of your Operating System you use the link provided in the System Evaluation Summary report to determine if 9.4 M8 is supported on your OS release. https://support.sas.com/supportos/list   If your OS version supports SAS 9.4 M8 you can proceed with an update-in-place. If it does not, then you cannot perform an update on existing hardware. One option available would be to update the version of your OS, we will not look at this option in this post. Let’s look at what your options are if you want to use SAS tools to get to M8 without updating the OS of your current environment.   Getting to M8 if my current OS is not supported   It is a little more complicated to get to M8 if your current OS is not supported. Basically, you must use the automated migration tools (SAS Migration Utility and SAS Deployment Wizard) to migrate your environment to new hardware where 9.4 M8 is supported. But that is not all. If you are familiar with automated migration you will remember that when performing a migration, you must analyze and package your source environment with the SAS Migration Utility (SMU) that is delivered with your target SAS Software order. The version of the SMU delivered with M8 requires Java 11. As a result, in order to perform a migration directly to M8 your source environment must support Java 11. If your source environment does not support Java 11, you will need to migrate first to a SAS 9.4 M7 or earlier environment and then update that environment to M8. The diagram below summarizes the paths available to get to SAS 9.4 M8 if you are currently on an unsupported OS.       To summarize this again if your 9.4 source environment is not on an OS supported by 9.4 M8 and: supports Java 11 then you can migrate directly to M8 on a new environment on an OS where SAS 9.4 M8 is supported. DOES NOT support Java 11, then you must migrate to an interim environment on SAS 9.4 M7 (or earlier) and then perform an update-in-place on this environment to get to 9.4 M8.   NOTE: deploying a new environment and promoting content is also an option for any 9.4 environments.   Updates to Configuration to Support a Successful UIP   As mentioned earlier the details of the System Evaluation are included in a previous post. It is worth mentioning that the Summary Report may also flag recommended configuration changes that you should make prior to an update. Based on prior experience these changes improve the success rate of the update process. You should make these changes before you update the environment.       Final Words   SAS 9.4 M8 is an important release for SAS. It eliminates many of the security vulnerabilities that have crept into earlier releases and modernizes much of the third-party software that is part of SAS 9.4. Please remember to run System Evaluation before updating to SAS 9.4 M8. The tools will provide you with detailed information to assist with a successful Update-in-Place. Here are some additional resources:   System Evaluation Tool Helps with SAS 9 Upgrade-in-place Planning System Evaluation Documentation Check if your Operating System is supported A review of the options available for upgrading a SAS 9 deployment Removing SAS Configuration SAS Guide to Software Updates SAS Migration Utility Requirements Issues addressed in 9.4 M8 (sas.com)   Find more articles from SAS Global Enablement and Learning here. ... View more