Watch this Ask the Expert session to understand the role of a SAS Viya administrator and build confidence and improve the configuration, stability, and performance of your SAS Viya deployment.    Watch the webinar   You will learn: The role of a SAS Viya administrator. Which parts of SAS Viya administration are relevant to your role. How to use a checklist of SAS Viya administration tasks The questions from the Q&A segment held at the end of the webinar are listed below and the slides from the webinar are attached.   Q&A Can I contribute new tasks? At the top of the checklist, there's a link to the project README.md (https://github.com/sassoftware/viya4-admin-checklist/blob/main/README.md). Inside that, we have lots of orientation information about the project. You don't need to read all of this before you start, but it can be quite helpful. Within that, we've got a Contributing section, that has a link to a document that describes how to contribute new tasks. There is a fairly simple contributor agreement to that, nothing too onerous. It describes how to go about creating your own task or modifying an existing task and then submitting a pull request. If you can provide a version of the file in any form to us, including as a GitHub pull request, we'll happily look at it. We can review and edit it if needed, and would be delighted for contributions.   How should I suggest ideas for things to include in the checklist? In GitHub, there is an Issues feature. You can raise an issue, and that is a fantastic way to get in touch with the current maintainers of the project. We'll see the issue come in, we get an e-mail notification, and then we can discuss what you'd like, whether that's a suggestion or if you see a problem with something that you'd like us to revise or write new content or change existing content. If you use a GitHub issue, that's probably the quickest way to get in touch with us. You can also get in touch with the individual project team members, but that's a bit more of an unreliable way to do it because over time we may move teams, we may be working on other projects and not be quite as responsive. So, a GitHub issue is absolutely the best way to get in touch.   Regarding Authorization Model: is it possible not only to import Identities from the identity provider but also the organizational groups, roles, etc. in SAS Viya? Currently, we have different SAS 9.4 environments running which are almost fully driven by AD groups: users, user groups, roles, the folder/library creation and access rules (R/W) are driven by AD, new users, users leaving/moving in the organization, ownership of data,… ACT's together with ACL's on Linux level (enhancements to macro's provided by SAS Institute). Is such a setup easy migratable/feasible from SAS 9.4 towards SAS Viya? Well, that is a fantastic question, bravo. Short answer, some bits yes and some bits no. Let's split those out a little bit and we may follow up with this one in the post session material as well.   First of all, about the users and groups. The way that users and groups are managed in SAS 9 is different to the way that it happens in SAS Viya. In SAS 9, you have to do something as the SAS administrator to extract the current list of users and groups from your identity provider, typically Entra ID, Active Directory, or something like that. You have to run some code that will maintain the list of users and groups in your SAS 9 environment in the metadata. SAS Viya doesn't work like that. SAS Viya uses either SCIM, or the Identities service to pull identities from an LDAP provider like Entra ID or some other LDAP provider, OpenLDAP maybe, and it will [do so] automatically. Well, when the identity server pulls users and groups from LDAP, it's a pull model. When you use SCIM to provide identities to SAS Viya then that's a push model. The updates are initiated from the external identity provider. But either way around, what you get is an automatically maintained list of users and groups in SAS Viya. So, you don't need to run something yourself anymore to create them in SAS Viya. And yes, the groups that those users are in will come through if you configure the identity service to pick those groups up correctly. So, part of the job of the initial configuration of your environment is that initial configuration of the identity service so that you get the groups you need and ideally not too many of the groups you're not interested in.   Regarding the part of your question about the ACTs (Access Control Templates) in SAS 9, which are commonly used for securing all kinds of resources in SAS 9, and ACLs which is Access Control Lists on the Linux file system, there is a two-part answer.   The authorization models in SAS Viya are a General Authorization system, used for most things like folders, reports, and application functionality. CAS (Cloud Analytic Services) has its own separate authorization system. But both of those are really quite different to the metadata authorization in SAS 9. So, there is no easy way to automate the translation of the permissions that you have on objects in SAS 9 with ACTs. There's no easy way to automate the conversion of that through to SAS Viya. I've seen lots of people attempt it with varying degrees of success, but it's not a simple, pain-free process. I would expect to have to redesign an authorization system from scratch in SAS Viya based on the same principles as the one you had in SAS 9. But the way [permissions are] implemented in SAS Viya is so different that you can't easily automate the transfer of a SAS 9 authorization system into a SAS Viya one.   The last part you'd touched on was, I think Access Control Lists on the Linux file system. They work the same in SAS Viya (if you're using a POSIX style file system) as they did in SAS 9. All you need to do is make sure that your CAS sessions, or your Programming Runtime sessions are running as the right user. So, when the attempt is made to access something on the file system in that directory structure with those permissions applied to it, it's being accessed as the correct user and not as some service account. But beyond that, it should work more or less the same way that it did with SAS 9.   Is it possible to access and apply these ten points? I'm not totally sure if I know what you mean by that. I mean the list of the 10 tasks that we've picked was indicated by that ‘Essential’ column in the main Checklist, and in the Regular Tasks Checklist. So that's where you can access them. I guess we don't have anything that we provide that's an automated method for designing your backup and restore process, or for designing your authorization model for you. Some of these are higher level design tasks or administrative activities that we can't script.   Can you please share procedure to migrate SAS Viya 3.5 to Viya 4? https://go.documentation.sas.com/doc/en/sasadmincdc/v_054/calmigration3x/n06wplu5iqmgz6n1mnpklw71eyvw.htm   How frequently do we need to install hotfix in SAS Viya? That is up to you. There is an Update Checker report that runs daily which will inform you of the availability of updates. You can then choose to apply the updates at your convenience. Viya Stable releases come out monthly, so we find most customers apply updates at least weekly.   How to convince customers to migrate to SAS Viya from Sas 9.4? Because lot of customers/clients moving to other clouds from SAS 9.4 compared to SAS Viya. This overview of SAS Viya may help https://go.documentation.sas.com/doc/en/calintro/v_001/p0l5bvopo6rhuqn1nw7frbipj7lo.htm   Does SAS support local internal registry for mirror registry? Yes, it does. There is documentation available for that in the SAS Viya Operations Guide (https://go.documentation.sas.com/doc/en/itopscdc/default/dplyml0phy0dkr/p1cq2mti42s7lkn1wl4pfwyq45up.htm)   Do we need any Kubernetes admin knowledge for SAS Viya admin? Yes, that is quite essential. You may not need to be a K8s admin, but it will be helpful to be aware of their duties to communicate effectively with them.   Is there SAS -nodms session launch in SAS Foundation in SAS Viya 4? Yes, you can use the sas-viya command to get something similar for SAS Viya. The command would be like this: sas-viya batch jobs run-saslm -c <context>   What if the cloud admin asks to take all images in single repository in AWS? Is it possible to store all images in a single repository? You can setup a mirror repository and store the Viya images in that repository.     Recommended Resources SAS Viya Administration Checklist SAS Viya 3.5 Administration Checklist Top 10 Platform Administration Tasks Checklist of SAS® Platform Administration Tasks SAS Administration Learning Subscription, SAS Viya Platform topic: 5 courses leading to Administering SAS Viya exam Please see additional resources in the attached slide deck.   Want more tips? Be sure to subscribe to the Ask the Expert board to receive follow up Q&A, slides and recordings from other SAS Ask the Expert webinars. ... View more

SAS Viya Monitoring for Kubernetes' log monitoring stack collects log messages and stores them in its own instance of OpenSearch. At the latest release, version 1.2.21, its command-line tool getlogs.py has been moved to 'production' status.   getlogs.py is a tool for exporting log messages captured in the log monitoring OpenSearch instance to a file or to the console/stdout, formatted as either CSV or JSON. Use it interactively from a command line or a script. Filter criteria and/or a search string can be specified as command parameters, or you can download, edit, and resubmit log queries written in OpenSearch's built-in domain-specific language (DSL) query syntax, to get the specific log messages you are interested in.   In this post, I'll describe my initial experiences setting up and using getlogs.py. The documentation already includes some nice usage examples - I'll add a few of my own too. In a follow-up post, I'll explore downloading, modifying and re-uploading a query with getlogs.py, to see how easy it might be to exploit the richness of the OpenSearch built-in query language from a script.     Prerequisites for getlogs.py   The documentation for getlogs in SAS Help Center lists two requirements: Python 3.11 or later, and an OpenSearch module for python, opensearch-py. Obviously, you'll also need a running instance of the log monitoring stack from SAS Viya Monitoring for Kubernetes version 1.2.21 or later, and a way to access it over the network. This can be either: An ingress for the OpenSearch back-end data store (note this is separate from the OpenSearch Dashboards ingress you might use to access the front-end web application), or A kube config file, giving access to the Kubernetes cluster and the logging namespace where OpenSearch is running, which getlogs.py can use to set up temporary port-forwarding to give it a network path to the OpenSearch back-end data store Python 3.11   If you have a relatively recent version of Linux to deploy the tools on, the Python 3.11 prerequisite and its dependencies is unlikely to be an issue. A quick web search will turn up plenty of guides to installing Python 3.11 if yours is a slightly older version.   During my initial attempts it turned out that the Python 3.11 requirement took more effort to satisfy, because the version of Linux we use for our workshop environments is a little (ahem) 'mature', and didn't have Python3.11 available in its usual package manager. Python3.11's dependency on openssl 1.1.1 was tricky to meet without impacting other components running on the same Linux host that my workshop Kubernetes cluster and SAS Viya were running on (upgrading OpenSSL to a major release that was later than everything else in that Linux release expected broke other services). So I used a separate Linux host to experiment with getlogs.py: an instance of Ubuntu Linux running in WSL (Windows Subsystem for Linux) on my Windows desktop. Since the Ubuntu release running in my WSL was more recent, it already had a suitable version of openssl which meant deploying Python 3.11 was simple (and didn't break anything else). I had no problem getting the opensearch-py Python module installed in either scenario.   Network path to OpenSearch from the host where you run getlogs.py   getlogs.py offers two ways to define a network path from your client machine to the back-end OpenSearch data store. OpenSearch ingress   The samples included with SAS Viya Monitoring for Kubernetes include alternative user-values-opensearch.yaml files illustrating how to set up an ingress for OpenSearch.   To configure host-based ingress like https://opensearch.your-ingress-controller-hostname-or-alias/, see https://github.com/sassoftware/viya4-monitoring-kubernetes/blob/1.2.21/samples/ingress/host-based-ingress/logging/user-values-opensearch.yaml, samples/ingress/host-based-ingress/logging/user-values-opensearch.yaml. To configure path-based ingress like https://opensearch.your-ingress-controller-hostname-or-alias/, see samples/ingress/path-based-ingress/logging/user-values-opensearch.yaml.   If the user-values-opensearch.yaml file in your USER_DIR directory struture has extra attributes like those illustrated in your chosen sample, Kubernetes will set up the corresponding type of ingress for OpenSearch when you deploy the log monitoring stack.   I noted that I could only get an ingress to OpenSearch working properly if I enabled TLS (HTTPS) for it. I got an http 503 bad gateway error when I tried without TLS/HTTPS. Internally, OpenSearch's network access is always over TLS/HTTPS anyway, and it was no problem for me to configure it with HTTPS, so I just did that. Maybe there is a way to get it working without TLS, but I didn't try that particularly hard.   Prior to testing getlogs.py worked, for convenience, I exported four environment variables: OSUSER, OSPASSWD - OSHOST and OSPORT, as illustrated in the documentation under Connect to OpenSearch with Direct Link to Host, so I didn't have to keep telling getlogs.py how to get to OpenSearch with command line parameters, which are the alternative: # Try getlogs.py cd ~/viya4-monitoring-kubernetes/ export OSUSER=admin export OSPASSWD=mysecretadminpassword export OSHOST=opensearch.hostname.something-or-other.com export OSPORT=443 python3.11 logging/bin/getlogs.py If you don't create your own signed certificate for the TLS connection and provide it in the secret named in that yaml file, I think OpenSearch creates its own self-signed certificate. But your browser/command line client might not trust a self-signed certificate, so I prefer to provide one I know is trusted, and avoid that issue. I didn't play around with that very much though. Port forwarding   The other option, attractive if you prefer not to (or cannot) create an ingress to your log monitoring OpenSearch instance, or if you prefer not to pass a username and password to getlogs.py on the command line, is to provide a kube config file that gives access to the logging namespace in your Kubernetes cluster where that OpenSearch instance runs. Save the kube config file somewhere on a file system accessible to the host where you will run getlogs.py, set a KUBECONFIG environment variable to point to it, and run getlogs.py with a -pf parameter as shown below: # Try getlogs.py cd ~/viya4-monitoring-kubernetes/ export KUBECONFIG=~/.kube/config python3.11 logging/bin/getlogs.py -pf This tells getlogs.py to set up a temporary Kubernetes port-forward to use while it queries the OpenSearch data store. In some situations this may be considered more secure - I like that we have a choice.   Default output   Whichever method you use to set up a network path to OpenSearch, with no other parameters on the command line getlogs.py should return the 10 most recently captured log messages, from any logsource/container/pod/namespace, within the past 1 hour, in CSV format. They should look something like the example below - the content will vary depending on what log messages your SAS Viya Monitoring for Kubernetes log monitoring stack most recently happened to capture and stream through to OpenSearch: Searching index: Search complete @timestamp,level,kube.pod,message,_id 2024-02-01T12:58:33.928Z,NONE,canal-qpqww,"2024-02-01 12:58:33.928 [INFO][25162] monitor-addresses/startup.go 432: Early log level set to info ",67065E0E-9E9D-8806-E822-6158E3EACB78 2024-02-01T12:58:33.928Z,NONE,canal-qpqww,"2024-02-01 12:58:33.928 [INFO][25162] monitor-addresses/startup.go 315: Skipped monitoring node IP changes when CALICO_NETWORKING_BACKEND=none ",6C44C501-E7C8-F6ED-1617-FF5CE3E0BA65 2024-02-01T12:58:33.923Z,WARNING,canal-qpqww,Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.,02BD6FBB-6453-CB17-3658-E5A2AF060D92 2024-02-01T12:58:33.870Z,NONE,canal-wkthm,"2024-02-01 12:58:33.870 [INFO][27083] monitor-addresses/startup.go 432: Early log level set to info ",C32FA169-A498-3410-850B-478F16F9B962 2024-02-01T12:58:33.870Z,NONE,canal-wkthm,"2024-02-01 12:58:33.870 [INFO][27083] monitor-addresses/startup.go 315: Skipped monitoring node IP changes when CALICO_NETWORKING_BACKEND=none ",D3BED951-D4B0-911C-0F8E-B19E62C17EFF 2024-02-01T12:58:33.867Z,WARNING,canal-wkthm,Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.,4148E479-215D-7056-9318-85368F213D76 2024-02-01T12:58:33.564Z,NONE,canal-q87j6,"2024-02-01 12:58:33.564 [INFO][11868] monitor-addresses/startup.go 432: Early log level set to info ",418CE3BC-B3D4-F13B-C653-32F3A5914F79 2024-02-01T12:58:33.564Z,NONE,canal-q87j6,"2024-02-01 12:58:33.564 [INFO][11868] monitor-addresses/startup.go 315: Skipped monitoring node IP changes when CALICO_NETWORKING_BACKEND=none ",E8E10D1B-74A3-7437-B1E4-952B796E9A69 2024-02-01T12:58:33.561Z,WARNING,canal-q87j6,Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.,7A4738E1-4196-0FC9-0ABE-EFC504A6C3D5 2024-02-01T12:58:33.123Z,NONE,canal-fs4vm,"2024-02-01 12:58:33.123 [INFO][20724] monitor-addresses/startup.go 432: Early log level set to info ",0E4A2CC2-64FA-C1FD-6235-6943512FC1F0 This serves as a reasonably good validation test that both getlogs.py and your network path (via ingress or port-forwarding) to OpenSearch are configured correctly, and that all of the pre-requisites are met.   If you get an error message instead of log output, you'll need to debug the issue before you proceed.   Syntax help   Like many command-line tools, getlogs.py -h outputs help text, describing the parameters it takes: python3.11 logging/bin/getlogs.py -h The parameters fall into three main categories, query search parameters that specify what log messages you want to see, query output parameters that influence the command's output (max rows, whether to a file, CSV or JSON etc.), and connection settings used when you don't set environment variables to provide those values. The start and end time parameters ( -st | --start [DATETIME ...] and -en | --end [DATETIME ...] ) are listed under query output settings, but I consider them more query search parameters.   Time Zones   The datetime values you pass in to the --start and --end parameters (examples towards the end of this post) should be in the local time zone that your host is configured to use. So for example if your host Linux machine is set to Eastern Standard Time (EST), you would specify the start and end times for the period you want to get log messages in the same time zone - EST.   However, the datetime values in the @timestamp column in getlogs.py's CSV output are in UTC (Universal Coordinated Time). So for example if you run getlogs.py on a host machine whose local time is EST to request log messages from between 13:00 and 14:00 EST, you should expect results showing log messages with timestamp values between 18:00 and 19:00 UTC time (since EST is 5 hours earlier than UTC). Remember to take this into account when specifying start and end time filters, and when viewing/storing log message output that contains a timestamp column from getlogs.py - it is a potential source of slight confusion.   Using getlogs.py with filter and search parameters   Namespace The first thing we will usually do is add a namespace parameter, to get log messages from the SAS Viya platform and any solutions deployed in it. My SAS Viya namespace is gelcorp (and I've set up an ingress and the environment variables to use it and authenticate as 'admin') so for me the command becomes: python3.11 logging/bin/getlogs.py -n gelcorp I noticed that the response time of queries was significantly longer with this parameter, but otherwise it works as expected.   Specify Output Fields (_id is always appended)   By default, CSV output from getlogs.py has the following fields: @timestamp,level,kube.pod,message,_id - the actual fields output for any particular results are printed in a header row before the results. I'm not sure why kube.pod was chosen instead of logsource. The _id field is always output, and it is always appended to the end of each CSV result.   Note: If you specify the _id field as one of the values of the --fields parameter, it is output in the results both in the position you specify, and also at the end of each row. There is thus little point in specifying the _id field as one of the values to the --fields parameter, unless for some reason you MUST have it at a particular position. You'll get it anyway at the end of reach row, regardless.   The saved search I usually open first on the Discover page in OpenSearch Dashboards is called Log Messages. We can imitate it in getlogs.py with --fields @timestamp level logsource message . (Again, the log document _id will be appended to the end of each results row without us asking for it, and we can't suppress it.): python3.11 logging/bin/getlogs.py -n gelcorp --fields @timestamp level logsource message Example results (just showing the first row, for the format - there were 10 rows of results): Searching index: Search complete @timestamp,level,logsource,message,_id 2024-02-01T15:27:36.583Z,INFO,workload-orchestrator,"The job ""1832"" has finished with exit code 0.",37FD93EA-33B6-8986-8AAD-9ABAB4114594 Search for a string   To create some log messages with a distinctive message in them, I opened SAS Studio, and ran the following line of SAS code, once to begin with: %put The quick brown fox jumped over the lazy dog; Having run that code in a compute session in SAS Studio, the compute server process writes out at least one line of log message containing that string to its container (and thus pod) logs. We should be able to find it with getlogs.py, like this: python3.11 logging/bin/getlogs.py -n gelcorp --fields @timestamp level logsource message --search 'The quick brown fox jumped over the lazy dog' Here is the same command, split over several lines with backslash line-continuation characters make it a little easier to read: python3.11 logging/bin/getlogs.py \ -n gelcorp \ --fields @timestamp level logsource message \ --search 'The quick brown fox jumped over the lazy dog' Here's the output from running that command (in either the single-line or multi-line form above - they are identical) on my environment. There are two lines of results - two matching log messages in the gelcorp namespace: Searching index: Search complete @timestamp,level,logsource,message,_id 2024-02-01T15:37:14.678Z,INFO,compsrv,80 %put The quick brown fox jumped over the lazy dog;,ABF69779-B0DE-61B7-8ED8-A287D0395576 2024-02-01T15:37:14.678Z,INFO,compsrv,The quick brown fox jumped over the lazy dog,2CD44B04-7E74-7DD1-4A31-8AD54230426F One log message is the SAS log output echoing the line it is running. The second is the result of running it - the text we asked SAS to '%put' into the program log.   Tip: If you want to check the @timestamp values in the results you see are for the correct time period, even though they are given in UTC time, you may wish to check the abbreviated name of the time zone that your host machine is set to use, and the offset that time zone has from UTC, which is used for the timestamps in the results. From a bash prompt, run date +%Z (with a capital Z ) to report your host machine's time zone's abbreviation, e.g. EST , according to the notation used by your host OS. Also, you can run date +%:z (with a lowercase z ) to report your host machine's time zone offset from UTC, e.g. -05:00 , which means this host's time zone is five hours behind UTC.   Time period   getlogs.py outputs messages from the last 1 hour by default. It doesn't (yet) have parameters to specify other relative time spans, like 'last 15 minutes' or 'last 24 hours', but bash has a date tool can do date calculations and format dates as we require them. This article was very helpful in writing the examples which follow below: https://www.unix.com/tips-and-tutorials/31944-simple-date-time-calulation-bash.html   Using the --start and --end parameters to getlogs.py, you can specify a custom relative time period fairly easily. Both parameters take a date time string in the format Y-M-D H:M:S , for example: 2024-02-01 15:00:00 .   Results for the last 15 minutes   We add some bash statements to calculate the time now and 15 minutes ago, and format these two times as getlogs.py expects: datetime_now=$(date "+%Y-%m-%d %T") echo ${datetime_now} datetime_15mins_ago=$(date --date "${datetime_now} 15 minutes ago" "+%Y-%m-%d %T") echo ${datetime_15mins_ago} # Log messages containing a specific string from gelcorp namespace in the last 15 minutes python3.11 logging/bin/getlogs.py \ -n gelcorp \ --fields @timestamp level logsource message \ --search 'The quick brown fox jumped over the lazy dog' \ --start ${datetime_15mins_ago} --end ${datetime_now}   Because more than 15 minutes (but less than 1 hour) had passed between the last time I ran my one-line SAS program to put that distinctive message in the logs, and when I first ran the code above, this output was correct:   Searching index: No results found for submitted query.   If you include the --search parameter to look for messages containing a specific string, and filter to e.g. the last 15 minutes, you won't see any results if the string has not appeared in any log messages in the last 15 minutes! That's correct.   We could either fix that by increasing the time period, or running the code again. I chose to try the latter first, and ran the same one-line SAS program again to have another, more recent log message containing that distinctive string. Then, I re-ran the same block of bash code above, and with more interesting results - the rows are similar to ones we saw in earlier output, but the timestamps and IDs are different:   Searching index: Search complete @timestamp,level,logsource,message,_id 2024-02-01T16:17:27.010Z,INFO,compsrv,80 %put The quick brown fox jumped over the lazy dog;,AD8056A4-81E2-97D6-3CCA-875A04B0E0A8 2024-02-01T16:17:27.010Z,INFO,compsrv,The quick brown fox jumped over the lazy dog,124E81F5-7BDC-8DB4-FB92-3EBD91A7E6F3   Results for the last 2 hours   Increasing the time period we search for to the past 2 hours, by modifing the bits of bash script before the call to getlogs.py, we expect to see both sets of results: datetime_now=$(date "+%Y-%m-%d %T") echo ${datetime_now} datetime_2hrs_ago=$(date --date "${datetime_now} 2 hours ago" "+%Y-%m-%d %T") echo ${datetime_2hrs_ago} # Log messages containing a specific string from gelcorp namespace in the last 2 hours python3.11 logging/bin/getlogs.py \ -n gelcorp \ --fields @timestamp level logsource message \ --search 'The quick brown fox jumped over the lazy dog' \ --start ${datetime_2hrs_ago} --end ${datetime_now} Results as expected - two pairs of rows matching our search string, one pair from within the last 15 minutes, and a pair from about 40 minutes earlier: Searching index: Search complete @timestamp,level,logsource,message,_id 2024-02-01T16:17:27.010Z,INFO,compsrv,80 %put The quick brown fox jumped over the lazy dog;,AD8056A4-81E2-97D6-3CCA-875A04B0E0A8 2024-02-01T16:17:27.010Z,INFO,compsrv,The quick brown fox jumped over the lazy dog,124E81F5-7BDC-8DB4-FB92-3EBD91A7E6F3 2024-02-01T15:37:14.678Z,INFO,compsrv,80 %put The quick brown fox jumped over the lazy dog;,ABF69779-B0DE-61B7-8ED8-A287D0395576 2024-02-01T15:37:14.678Z,INFO,compsrv,The quick brown fox jumped over the lazy dog,2CD44B04-7E74-7DD1-4A31-8AD54230426F   I think this is a good point to wrap up this post - we have not explored all of the filters that getlogs.py offers, so I'd encourage you to look at the output of getlogs,py -h, or explore the great usage examples in the getlogs.py documentation.   I am looking forward to seeing the applications we can put this valuable tool to, with scheduled scripts to extract log data for auditing and monitoring purposes. In a follow-up post, I intend to explore what we can do with the OpenSearch domain-specific query language that getlogs.py can use. There's a lot of potential value in this tool, and I hope you find it as useful as I think it is going to be.   See you next time!   Find more articles from SAS Global Enablement and Learning here. ... View more

Last time, in the first part of this two-part post I showed how to (mostly) manually create a new group-specific compute context, with permissions set up so that users only see group- or user-specific compute contexts they can use. We ran a one-time preparatory script that ensured all users could still see the original 'out-of-the-box' compute contexts.   This time, we will automate the steps and iterate through lists of groups and users to perform them, so you can scale up and create a larger number of group- and user-specific contexts. This would be tedious to do manually.   As we will seen, this makes it easy to create contexts which the SAS Administrator can then customize per group, or per user, to configure each with their own group-specific set of SAS options and autoexec statements. Yet users won't find their compute contexts menu in SAS Studio or SAS Model Studio cluttered with contexts they cannot (and are not supposed to be able to) use.   As before, we are going to use bash scripting and the sas-viya CLI. For this task you will again need the sas-viya CLI and its plugins, configured with a connection profile and certificates to connect to your SAS Viya cluster, and you must authenticate the sas-viya CLI as a member of the SAS Administrators custom group before proceeding.   Preparatory script already presented in part 1   In part 1, we already saw how to run an example bash script which uses the sas-viya CLI to:   Disable the rule granting Authenticated Users read access to all compute contexts ( /compute/contexts/* ), if it is not already disabled List all existing compute contexts, and store the list in a file Get the existing compute context IDs from that file, and iterate through them For each existing compute context, create a new authorization rule to grant all Authenticated Users read access to it   I won't duplicate that script here. Before continuing, if you have not done so in your SAS Viya environment already, please review, adapt and run that script as a one-time task.   In the results section of this post, I will also assume that you have been through the manual steps in part 1 to create a group-specific compute context for HR, and will include that in the expected results where appropriate.   Bulk-create group-specific and user-specific compute contexts   In part 1, we also manually created one new compute context, for the HR group in our example environment. We named it "SAS Studio compute context for HR group".   Now we can scale this up a bit. It is much quicker to use a bash script and the sas-viya CLI signed in as a SAS Administrator if you need to make a set of group- (or user-) specific compute contexts.   The create_contexts.sh script shown below is an example, but you will need to adapt it to your own needs, in at least these ways: You can choose which compute context you will use as your template – here I have chosen the SAS Studio compute context, but you can use a different one. Here I deliberately did not choose a context with a limitation already set on which identities – which users and groups – can create a compute session under that context. A reader comfortable with the process could quite easily modify the code to be based on a template which does add this restriction. Keep or delete whichever parts of the group-specific or user-specific context creation you need. The sample script below has both, but feel free to delete one  or the other. (Suggestion: follow better practices and only use the group-specific part!) Obviously, you will need to substitute the values in group_list and/or user_list with lists of IDs (rather than the names) of groups and users in your environment, for whom you wish to create specific compute contexts: group_list='Finance Sales' user_list='Henrik Fiona Sean' Uncomment the ls and rm statements in the last two lines if you want to have a record of, and then clean up the temporary files this script creates in the /tmp directory. I like to be able to inspect the temporary files, so I commented those lines out.   Do this in a non-production environment first. There is no 'undo' script, so reversing these changes could take some effort.   Copy the following code, and save it as a new script file called ~/create_contexts.sh . The comments in the code below explain what each bit does: #!/bin/bash # Download the JSON definition for the original SAS Studio Compute Context # and use jq to remove everything except the fields specified below. # The fields we select in jq should be the only fields we need. rm -f /tmp/sas-studio-context-template.json sas-viya --output fulljson compute contexts show -n "SAS Studio compute context" | \ jq 'with_entries(select(.key | in({"attributes":1, "description":1, "environment":1, "launchContext":1, "launchType":1, "name":1, "version":1})))' > /tmp/sas-studio-context-template.json cat /tmp/sas-studio-context-template.json # Set up the lists of users and groups we will create contexts for group_list='Finance Sales' user_list='Henrik Fiona Sean' for group in ${group_list} do rm -f "/tmp/sas-studio-context-${group}.json" cp "/tmp/sas-studio-context-template.json" "/tmp/sas-studio-context-group-${group}.json" sed -i -e 's/"name":.*,$/"name": "SAS Studio Compute Context for '${group}' group",/g' "/tmp/sas-studio-context-group-${group}.json" sed -i -e 's/"description":.*,$/"name": "Compute context to be used for the SAS Studio service by '${group}' group",/g' "/tmp/sas-studio-context-group-${group}.json" # Use the template to create a new context for this group sas-viya compute contexts create -r -d @/tmp/sas-studio-context-group-${group}.json > /tmp/new-context-created.json id=$(cat /tmp/new-context-created.json | jq -r '.id') # Grant the group permission to see their new context sas-viya authorization grant --group ${group} --permissions read --reason "${group} can read their own compute context" --object-uri "/compute/contexts/${id}" # Grant the group permission to create sessions under their new context sas-viya authorization grant --group ${group} --permissions create --reason "${group} can create sessions under their own compute context" --object-uri "/compute/contexts/${id}/sessions" done for user in ${user_list} do rm -f "/tmp/sas-studio-context-${user}.json" cp "/tmp/sas-studio-context-template.json" "/tmp/sas-studio-context-${user}.json" sed -i -e 's/"name":.*,$/"name": "SAS Studio Compute Context for '${user}'",/g' "/tmp/sas-studio-context-${user}.json" sed -i -e 's/"description":.*,$/"name": "Compute context to be used for the SAS Studio service by user '${user}'",/g' "/tmp/sas-studio-context-${user}.json" # Use the template to create a new context for this user sas-viya compute contexts create -r -d @/tmp/sas-studio-context-${user}.json > /tmp/new-context-created.json id=$(cat /tmp/new-context-created.json | jq -r '.id') # Grant the user permission to see their new context sas-viya authorization grant --user ${user} --permissions read --reason "${user} can read their own compute context" --object-uri "/compute/contexts/${id}" # Grant the user permission to create sessions under their new context sas-viya authorization grant --user ${user} --permissions create --reason "${user} can create sessions under their own compute context" --object-uri "/compute/contexts/${id}/sessions" done # ls -al /tmp/*context*.json # rm -f /tmp/*context*.json   For demonstration purposes, the example user IDs in user_list in the create_contexts.sh script above includes Henrik (who is in the HR group in my environment, and who we used for our manual example in part 1), plus two users we have not mentioned before: Fiona (who is in Finance ), and Sean (who is in Sales ). Also the user_list intentionally does NOT include a user named Sarah who exists in my environment, and is also in Sales . We will sign into SAS Studio as each of these users later, to show the effect of running the script as below in my environment.   Once you have created it, make the script executable, e.g.:   chmod u+x ~/create_contexts.sh   Check it carefully for errors, and then (in your non-production environment first!), after authenticating against the sas-viya CLI as a member of the SAS Administrators group, run your version of the create_contexts.sh  script.   ~/create_contexts.sh   It outputs quite a bit of JSON to the console (stdout). First is the content of the /tmp/sas-studio-context-template.json file, which should look something like this: { "description": "Compute context to be used by the SAS Studio service", "environment": {}, "launchContext": { "contextId": "d929db8a-dcb0-4220-9c15-86135a432db5", "contextName": "SAS Studio launcher context" }, "launchType": "service", "name": "SAS Studio compute context", "version": 4 } This is followed by two blocks something like the following for each group-specific compute context. Here is the pair of JSON output documents in my results, for the creation of the two authorization rules allowing Finance to read (i.e. see) and create sessions under (i.e. use) their new group-specific compute context: { "acceptItemType": "", "acceptType": "", "contentType": "", "createdBy": "geladm", "creationTimestamp": "2023-12-19T18:07:13.178Z", "description": "", "enabled": true, "id": "b3ba3d8b-541a-47dd-aa69-2b5cd2b5b257", "mediaType": "", "modifiedBy": "geladm", "modifiedTimestamp": "2023-12-19T18:07:13.178Z", "objectUri": "/compute/contexts/437ac37a-c7d4-41ac-9683-ae98f8c2c300", "permissions": [ "read" ], "principal": "Finance", "principalType": "group", "reason": "Finance can read their own compute context", "type": "grant", "version": 10 } The authorization rule has been created. { "acceptItemType": "", "acceptType": "", "contentType": "", "createdBy": "geladm", "creationTimestamp": "2023-12-19T18:07:13.433Z", "description": "", "enabled": true, "id": "2488cb29-e094-4eec-9632-bf803cf9a2f1", "mediaType": "", "modifiedBy": "geladm", "modifiedTimestamp": "2023-12-19T18:07:13.433Z", "objectUri": "/compute/contexts/437ac37a-c7d4-41ac-9683-ae98f8c2c300/sessions", "permissions": [ "create" ], "principal": "Finance", "principalType": "group", "reason": "Finance can create sessions under their own compute context", "type": "grant", "version": 10 } The authorization rule has been created. There should be a similar pair of blocks in the script's output for each other group, and each user.   Results   In my example environment, after manually creating a group-specific compute context for HR in part 1 and then running the script above, let's see what compute contexts are available to our selected users.   Henrik   Henrik should see all of the default compute contexts, plus ones for HR and Henrik:      Compute contexts visible to Henrik - the original default set of contexts, his own, and the one for HR Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page. Fiona   Fiona should see all of the default compute contexts, plus ones for Finance and Fiona:    Compute contexts visible to Fiona - the original default set of contexts, her own, and the one for Finance Sean   Sean should see all of the default compute contexts, plus ones for Sales and Sean:    Compute contexts visible to Sean - the original default set of contexts, his own, and the one for Sales Sarah   Sarah should see all of the default compute contexts, plus one for Sales (we did not create a personal compute context for Sarah):    Compute contexts visible to Sarah - the original default set of contexts, and the one for Sales. We did not create a personal compute context for Sarah. geladm   geladm (a SAS Administrator) should see all of the default compute contexts, plus ones for HR, Sales, Finance, Henrik, Fiona and Sean:   Compute contexts visible to geladm (a SAS Administrator). He can see the original default set of contexts, plus all the other group-specific and user-specific compute contexts. His list of compute contexts is longer than everyone else's, and has a scrollbar as a result.   This shows the script created the contexts we asked it to, they are visible to the users who need to use them, and crucially NOT visible to non-SAS Administrator users who don't need to (and should not be allowed to) use them.   Next steps   Having created all these contexts, the SAS Administrator is now able to customize each of them with, for example: group-specific SAS Workload Orchestrator queues group-specific SAS options (perhaps options which you only wish to set for some groups, and not for all) librefs and macros in the autoexec statement     Yet the list of compute contexts visible in each user's context menu in SAS Studio is not cluttered up with contexts they cannot and should not be able to use.   See you next time! Find more articles from SAS Global Enablement and Learning here. ... View more

Our team is sometimes asked how to create group-specific or user-specific compute contexts in SAS Viya, with permissions set so that users who are not in the group, or are not the user for whom the context was created, don’t see it. There are two aims for the permissions for these contexts: to avoid a user’s compute context menu in SAS Studio being so cluttered up with other users’ compute contexts that they have to look through a long list of contexts to find their own, and to avoid offering users the frustrating experience of being able to select a compute context in SAS Studio or SAS Model Studio which then fails to start. In this post we will see a how to (mostly) manually create a new group-specific compute context, with permissions set up to meet these two aims. We will: Adjust the authorization rules which make all compute contexts visible to all users by default, in e.g. the SAS Studio contexts menu. To do this we will: Disable* the rule that makes all compute contexts visible to all users Run bash commands to make new rules for each out-of-the box compute context so that users can still see them and start sessions under them Create a new compute context for an existing group Create more new rules granting the group permissions to see (and use) their new compute context, while not giving other users or other groups access to it To perform some of these steps, you will need to install the sas-viya CLI and its plugins, configure it with a connection profile and certificates to connect to your SAS Viya cluster, and authenticate the sas-viya CLI as a member of the SAS Administrators custom group. You will also see optional steps which use some of our pyviyatools, to simplify otherwise cumbersome tasks. Next time, in part 2 of this post, we will present another bash script that automates all of the steps above and iterate through lists of groups and users, so you can scale it up and script the creation of a larger number of group- and user-specific contexts.     * SAS Administrators aren’t impacted by disabling the rule that makes all compute contexts visible to all users. There is an out-of-the-box rule which grants SAS Administrators access to all URIs in the system, which means they still see all compute contexts and still be able to create new sessions under each compute context. SAS Administrators will have to scroll through all compute contexts in the dropdown contexts menu in SAS Studio and there is no sensible way to avoid this – except perhaps by not using SAS Studio as a SAS Administrator, or by not opting in to the SAS Administrators assumable group when you sign in to use SAS Studio.   What about batch contexts? It is not possible in the current version of SAS Viya to configure permissions that work they way I'd like them to for group- or user-specific batch contexts, when used from the sas-viya CLI. I will save the topic of a batch context version of this post for another time. It may be that for now, we simply create group- or user-specific batch contexts, but do not attempt to secure them - all users see all batch contexts. It is possible that in future we may get the ability to set permissions for batch contexts that work nicely with the sas-viya CLI and allow us to better manage their visibility.     User-specific or group-specific?     Making group-specific compute contexts is a better idea than making user-specific ones. It is less work to set up, less effort to maintain, and still does the job in most use cases. If users really do need their own user-specific ‘context’, but not their own job queue, it may be sufficient for them to define their own user-specific autoexec code block which runs when their compute session starts, or their own user-specific preamble and post-amble code which runs before each code submission, in SAS Studio – see SAS Studio > User's Guide > Introduction to SAS Studio > Editing the Autoexec file. In this part 1, I will create a group-specific compute context. In part 2, we will include user-specific compute contexts - they are created in much the same way as group-specific ones - no special steps are required.     Starting simple     ‘Out of the box’, SAS Viya has a rule granting Authenticated Users read access to all compute contexts. It’s neat, but it isn’t the best fit for a SAS Viya deployment with dozens of compute contexts, or more. So, we will begin by disabling that rule and adding new rules to make sure all Authenticated Users still have access to the out-of-the-box compute contexts.   We should only do this once, per deployment, and it is easier to do it before we create any user-specific compute contexts, because during the step where we create a new rule granting all Authenticated Users access to read each ‘out of the box’ compute context, we have to distinguish which contexts are ‘out of the box’ from those we created later. Before we create any new ones, that’s easy – all compute contexts that currently exist are 'out-of-the-box'. Later on, obviously you can still make rules for each of them, but it will require manual intervention to choose which contexts you want everyone to be able to see.   In this post, I am going to assume there are no extra compute contexts to begin with, and make a rule for all those that exist, granting all Authenticated Users access to read and create sessions under them, before we create any new compute contexts.   What does the contexts menu in SAS Studio look like for each user, out of the box?   Initially, all users see exactly the same set of compute contexts in SAS Studio. Note that the set of pre-defined contexts seen here depends on which SAS products and solutions are deployed, and on the version of SAS Viya, so do not be surprised if your starting set of contexts differs from the screenshot below. The screenshot below is what I see in one of our GEL workshop environments:    Compute contexts for all users in my environment, 'out-of-the-box'. Here we see them as a SAS Administrator, geladm, but all users see the same set of compute contexts.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Disable and replace rule granting all users read access to all compute contexts     We want to create new contexts without them becoming automatically visible to all users. So, in the Rules page of SAS Environment manager, while logged in as a SAS Administrator, remove (or better, disable) the general authorization rule granting Authenticated Users the Read permission on the URI /compute/contexts/*:    Disable this authorization rule to remove all users' access to see all compute contexts automatically.   It’s easy to search for the rule: type /compute/contexts/* into the search box above the rules table. The rule that matches this pattern and is for the principal Authenticated Users, granting Read permission is the one we want to disable. Right-click the rule, choose Edit, and in the Edit Rule dialog, change the ‘Rule status’ toggle button to ‘off’ (disabled):    Turn the 'Rule status' toggle button off to disable the rule.   Then click Save.   After disabling that rule, members of the SAS Administrators group, like geladm in my environment, are still able to use SAS Studio and get a compute context. They see no difference in behaviour, thanks to the rule that says they get all permissions (to perform all actions) on all URIs – in SAS Viya.   But disabling this rule creates a temporary problem for all non-administrator users. They get an error message when they open SAS Studio, saying “studio-commons-api-icu.client.compute.error.no.contexts.found.msg”:     We need to grant Authenticated Users permission to see, and use, all the out-of-the-box compute contexts again. The rules implementing those permissions will target the individual compute contexts by their IDs. Getting the compute contexts’ IDs is most easily done using the sas-viya compute contexts list command, so next we will do just that.   As a one-time task, from the command line we will list all existing compute contexts, store the results in a file, get the compute context IDs from that file, and iterate through them to create a new authorization rule for each one so to grant all Authenticated Users read access to each existing out-of-the-box context.   As mentioned above, before you can run this, you would need to install sas-viya CLI and its plugins, configure it with a connection profile to your SAS Viya cluster, and authenticate as a member of the SAS Administrators custom group. If you have done that, you can run these commands (adapted as necessary for your deployment)   As a bonus, the following also includes a scripted method of disabling the rule we just disabled above, using the getruleid.py pyviyatool, in case you prefer to do this in a script for your environment. It's no problem to attempt to disable a rule that is already disabled, so you can run it even if you did so already: ####################################################################################### # Important: Do all this once, before creating user- and/or group-specific contexts. # # This fundamentally changes out-of-the-box behaviour that by default, all users see # all compute contexts. After doing this, if you create a new compute context, you # will have to create a new authorization rule granting non-SAS Administrator users # permission to see it, otherwise they won't see it. ####################################################################################### # If you did not do it already... # Disable the rule granting Authenticated Users read access to all compute contexts (/compute/contexts/*) id=$(/opt/pyviyatools/getruleid.py -u /compute/contexts/* -p "authenticatedUsers" | jq -r '.items[0]["id"]') echo ${id} sas-viya authorization disable-rule --id ${id} # If you did this already, it does no harm to run this, and you will see a response saying something like " Rule 07633805-2c76-495a-9f38-a6c6c63eb628 is already disabled.". That is fine. COMPUTE_CONTEXTS_FILE=/tmp/compute_contexts.txt COMPUTE_CONTEXT_ID_FILE=/tmp/compute_context_ids.txt # List the compute context IDs, and store the results (which have a header row) in a text file sas-viya compute contexts list > ${COMPUTE_CONTEXTS_FILE} # Remove the header row tail -n +2 ${COMPUTE_CONTEXTS_FILE} > "${COMPUTE_CONTEXTS_FILE}.tmp" && mv "${COMPUTE_CONTEXTS_FILE}.tmp" ${COMPUTE_CONTEXTS_FILE} cat ${COMPUTE_CONTEXTS_FILE} # Make another file with just the compute context IDs (always the last field, which you can reference as $NF), in each line awk '{print $NF}' ${COMPUTE_CONTEXTS_FILE} > ${COMPUTE_CONTEXT_ID_FILE} cat ${COMPUTE_CONTEXT_ID_FILE} # Add a new authorization rule for each original compute context granting Authenticated Users read access to it while read id; do context="/compute/contexts/${id}" sas-viya authorization grant --authenticated-users --permissions read --reason "Authenticated users can read this original compute context" --object-uri ${context} done <${COMPUTE_CONTEXT_ID_FILE} ####################################################################################### #### End of section you should only run once, before creating user- and/or group-specific contexts. ####################################################################################### After you do this, all other authenticated users can again see (and start compute sessions running under) all the out-of-the-box compute contexts in SAS Studio.     Create a new compute context for a group   Now we can interactively create a new compute context for a group. We will create one manually for the HR group in my environment, based on the default SAS Studio compute context.   In SAS Environment Manager, as a SAS Administrator (geladm in my case), navigate to Contexts and choose the ‘Compute contexts’ view. Then, find the SAS Studio compute context in the list, right-click it, and choose Copy from the popup menu:       In the New Compute Context dialog: Change the name to e.g. “SAS Studio compute context for HR group” Change the description to e.g. “Compute context to be used by HR group for the SAS Studio service” Leave the Launcher context set to “SAS Studio Launcher context”   Under Identity type, click the radio button to select Identities, and at the top right of the identities area below it, click the “Choose identities” button and in the popup, select e.g. “Groups” and then your chosen group e.g. “HR”, and click OK:     The new compute context dialog looks like this just before you click Save:     Click ‘Save’ to save the new compute context for e.g. HR. You should see a brief popup message saying “Created compute context”. You should also see the new compute context appear in the list on the Contexts page in SAS Environment Manager.   Making the new context specific to your chosen group, e.g. HR, creates a new authorization rule for this context, granting members of the HR group permission to create new sessions under the context. Here is the new rule in my environment – note the ‘/sessions’ endpoint after the compute context ID:     However, because of the changes we made a moment ago, although members of HR have permission to create new compute sessions under the new compute context, they still cannot see it in e.g. SAS Studio.   At this point, Henrik’s list of available compute contexts in SAS Studio is the same as it was the last time we looked. Permission to see (Read) the new context has not yet been granted to HR, so we need to do that.   Back in SAS Environment Manager as geladm (my SAS Administrator), find the rule as shown in the screenshot above, granting HR Create permission on /compute/contexts/some-guide/sessions, right-click it, and Copy it. In the Copy Rule dialog, make the following changes: Remove the /sessions suffix from the end of the Object URI. For example the Object URI of the rule I copied was /compute/contexts/26d013e4-0a1e-4f56-9eba-c480714ee53b/sessions, so I deleted the last bit to just leave it as /compute/contexts/26d013e4-0a1e-4f56-9eba-c480714ee53b. Take care to leave the compute context ID intact – don’t accidentally delete any of that, and don't leave the trailing '/'. Leave the Principal Type as ‘Group’ and the Principal as your chosen group (in my case, ‘HR’) Click the ‘Choose’ button to change the Permissions from ‘Create’ to ‘Read’. (Your group only needs Read permission on the new compute context URI, there is no need to leave the ‘Create’ permission selected.) Edit the description to say something like “Users in group HR can see context 26d013e4-0a1e-4f56-9eba-c480714ee53b.” Leave all the other settings as unchanged – several fields are empty, which is fine. Click Save.   Now there should be two rules for HR targeting that compute context, like this:       Having done this, both geladm (a SAS Administrator) and user like Henrik (a member of the HR group) can see the new compute context and can start a compute session under it in SAS Studio. Here is Henrik’s view of the available compute contexts in SAS Studio at this point, showing that he has successfully started a compute session after switching to the new HR compute context:     However, when user Sarah (a member of Sales, and not a member of HR) signs in, she does not see the “SAS Studio compute context for HR group”, she only sees the set of compute contexts she had access to out-of-the-box:     Success!   We have created a new compute context visible and useable to only users in a specific group (plus SAS Administrators). Most importantly, the new context is not visible to (or useable by) users who are not members of that group. It does not clutter up other users’ compute context menu in SAS Studio. However, that was quite a lot of clicking in the web interface, and we have only created one group-specific compute context. That probably felt like a lot of work for a relatively small gain.   In part 2 of this post, we will see an example bash script to automate the creation of many new compute contexts, all secured similarly to be visible to and useable by only members of their intended group or individual users.     ... View more

Someone validating a SAS Viya deployment usually aims to answer some combination of these questions:   Are basic elements of my SAS Viya deployment working? Are the components of my SAS Viya deployment which will be used the most working acceptably well? Do some specific non-functional performance tests of this SAS Viya deployment meet expectations? Are access controls in SAS Viya granting and preventing access to data, content and application functionality in the intended way? There are of course other possible aims for validation beyond these, such as test of integration with data sources or other applications, usability and accessibility tests, tests of internationalization and more. There is no one 'best' way to validate a SAS Viya deployment; a validation procedure should be tailored to a specific deployment, and to answer specific questions relevant to the business' needs. Choosing to include fewer validation tests makes the procedure faster, cheaper and potentially easier to automate. Having more validation steps to a procedure may mean it takes longer and costs more to identify, design, develop and run the tests, but when run they give a more complete view of a deployment's status.   Given all that, this post gives examples of validation steps that we use in the GEL team. It also includes some example tests which I personally don't have any need to run, but which we are sometimes asked about. The examples are not exhaustive; if you have experience of validating SAS Viya deployments and you check for something not mentioned here which you think others should check too, I would love to hear from you.     Edit 02 Oct 2023: In the context of life sciences and pharmaceuticals, Computer System Validation (CSV) is a rigorous testing and documentation process required to satisfy regulators that "the computer systems and their software operate as intended, meet user requirements, and comply with regulatory standards" (to quote Computer System Validation (CSV) in Life Sciences Part 1: Introduction to CSV - Verista). This article does not try to describe such rigorous validation in a regulated industry, and is limited to a more generally applicable set of confirmatory tests which may be useful to any SAS Viya administrator.     SAS Viya Validation Resources   SAS-provided tools documented in SAS Help Center   The SAS Readiness Service checks the status of the SAS Viya platform every 30 seconds, to determine whether it is ready for use. It checks whether SAS endpoints in Kubernetes are responding (e.g. with HTTP 200: OK responses to a REST call), and also whether the SAS Infrastructure Data Server database and OAuth authentication providers are responding. Since it is part of SAS Viya 'out of the box', it offers a universally-available way to check whether SAS Viya is fundamentally operational.   The SAS® Viya® Platform: Deployment Validation section in the SAS Viya Platform Administration documentation in SAS Help Center is a useful resource. It describes how to run the SAS Viya Platform Deployment Report, which is one tool in the SAS Viya 4 Administration Resource Kit, a toolset available in GitHub and which is practically indispensable for many deployment consultants, architects and similar who work with SAS Viya. We use tools in the viya4-ark in most of our GEL workshop collections. Running the script which generates the SAS Viya Platform Deployment Report is both easy and quick.   The SAS Viya Command-line Interface (CLI) is an essential tool for validation, as it is for many other administration activities.     SAS Viya Administration Checklist   The SAS Viya Administration Checklist has a task called Validate your SAS Viya Deployment. It proposes your validation first check whether Kubernetes is fundamentally working and has the expected nodes and namespaces. Then, it suggests some tests to validate SAS Viya, such as application URLs returning a page, SAS Studio code submission working for a trivially simple SAS code statement, presence of loaded data in CAS, some authorization tests and some validation tests of the SAS Programming Run-time which can be done using the SAS Viya CLI.   It also suggests using...   The ValidateViya pyviyatool   ValidateViya is a pyviyatool that runs a series of tests on a Viya environment, validating that it is running as expected. validateviya has a modular design, allowing for the creation of custom tests, the alteration of existing tests, and the removal of unneeded tests. See the vaildateviya User Guide in the pyviyatools project in GitHub.     Basic validation   *Taps microphone* "Is this thing on?"   The aim of basic validation is to run a quick set of tests which will reveal fundamental issues with your deployment fast. We check for things like Kubernetes not working, SAS Viya not being deployed successfully, pods not running, or users being unable to sign in. If major issues prevent a SAS Viya deployment from working at all, you will want to know about it early.   Validate the right one   If you have more than one SAS Viya deployment, a possible pre-requisite is to determine which one to validate. Which hosts, which Kubernetes cluster, which is the URL for the web applications in the deployment to be validated? It is of no use to test the health of the wrong environment, and allow that mistake to give you a false sense of security. Confirm the hostname or IP address for your Kubernetes ingress host and any other hosts you will interact with directly. If you have front-end load balancers, reverse proxies or similar, bypassing these during basic validation will simplify your testing, especially if there is any ambiguity about which deployment will really respond to requests sent to an alias.   Examples of steps in a basic 'is it on?' validation procedure   To give some examples, here are descriptions of some tests in a basic validation procedure for an environment I regularly rebuild - these tests are likely to be valid for nearly any SAS Viya deployment:   Can we make an SSH connection to a node in the Kubernetes cluster (the node we use to run kubectl and other administration tools)? Is kubectl using the correct kube config file for the cluster on which the SAS Viya deployment is running? Do we get the expected number of nodes, and are they all in the expected Ready state, when we run kubectl get nodes? Are the Kubernetes namespaces for SAS Viya, and for supporting applications such as our observability toolset present, in the results of kubectl get ns? How many pods are running in the Viya namespace? Is the number of running within an expected range (e.g. 170-190 pods for the SAS Viya software order I deployed)? How many pods are pending in the Viya namespace? Is the number of pending pods larger than some acceptable minimum? (E.g. from past experience with this environment, I know that there are sometimes 2-3 pending pods out of 180 or so, and this does not necessarily mean there is a problem. But in this environment, more than this number of pending pods usually does indicate a problem.) Is the sas-readiness pod itself reporting as being ready, indicating that its three types of check are all passing? See the SAS Readiness Service for more on this. Can you sign in to SAS Environment Manager as an administrator account? Does the SAS Viya license for this deployment expire on a date sufficiently far into the future? Can you authenticate successfully against the SAS Viya Command-line interface?     Validate frequently-used functional components   If basic validation passes, we generally want to look just a little bit more closely at some applications, to check if the components of SAS Viya that end users will use the most are working. This next stage of validation still needs to be fast, and reveal commonly-occurring issues which might not be revealed by the basic validation tests above.   Examples of steps in a functional validation procedure   Your basic functional validation tests, in your environment, may differ significantly from the following list depending on what your users do most in SAS Viya. The following descriptions are the gist of what is tested, not how I test those things. They would typically be a mix of manual and scriptable tests. For the environment I look after, basic functional validation includes steps like these:   In SAS Environment Manager's Data page, or using the sas-viya CLI's cas plugin, are any CAS tables are loaded into memory, and are they the tables we expect to be loaded into memory in CAS for this environment? Open SAS Studio. Does a compute session under the SAS Studio compute context start successfully? Can we run a trivially simple SAS statement such as proc options; run; , and does it produce normal log output without errors? Can we submit the same program successfully in SAS Batch, using the sas-viya CLI's batch plugin? Does the SAS batch job execute, and return sensible-looking SAS logs with no errors? From SAS Drive, can we open the User Activity report? This is efficient in the sense that it tests several things at once: SAS Drive is working, and we can navigate SAS Viya folders for their contents SAS Visual Analytics is working and able to render charts SAS Cloud Analytic Services (CAS) is working and able to provide data to SAS Visual Analytics The Audit service is running. By default it only loads data into the AUDIT table in CAS once per hour, so we may have to wait for it to run before we see data in the User Activity report. Can a simple predictive model be built, trained, published and validated using tools such as SAS Visual Analytics, SAS Model Studio and SAS Model Manager? A scripted process which passes through key functional steps in these applications should be completed successfully. Can we open and sign in to our chosen log monitoring application (such as OpenSearch Dashboards), and see log messages and their contextual data flowing in from the SAS Viya deployment? Are there an unusual volume of ERROR-level log messages being produced? Can we open and sign in to your metric monitoring application (such as Grafana), and see metric data flowing in from the SAS Viya deployment and its host Kubernetes cluster? Do a few example charts of metrics appear to display normal patterns of metric data, compared to what we would usually expect to see in those charts? If there are any other supporting applications deployed in your Kubernetes cluster alongside your SAS Viya deployment, are they healthy and working?     Validate non-functional performance   Unless something unusual has gone wrong, the same specification of physical and virtual compute and storage resources, with the same versions of Kubernetes and its supporting components running the same release of SAS Viya which has been configured the same way will typically perform about the same every time you deploy it. Non-functional performance validation aims to demonstrate that an environment performs adequately in a series of workload or stability tests, compared either to some benchmark result from a similar environment in the past, or compared to a business objective.   This kind of validation likely to be performed less frequently; it may only need to be done once, or a handful of times, per environment. Therefore, administrators may have less need for this type of validation to be fast or automated. Non-functional testing for processing performance, responsiveness, resilience etc. certainly takes longer to design, and also typically takes longer to perform than basic validation.   This is the aspect of validation I have least need for with the classroom environments I support, so perhaps you would like to reply to this post in the comments below to describe what you need to cover with this type of validation. From my experience of consulting roles in SAS, the following test ideas could be a good starting point:   Can I load a specific-size data set into CAS in an acceptable amount of time? How long does a specific typical program take to run? How long does a data processing job flow take to run? Does it finish successfully within an acceptable time? Can the same data load test be performed at any of the usual times it might need to run, including when the system is under user load, and still complete within an acceptable time? The 'acceptable time' here may be defined by a contract or service level agreement, or may be in comparison with some benchmark result from a previous test. How long does it take a user to sign in and open each of the applications they use most, be that a report, a programming session, a modelling tool etc.? How long does a specific typical report take to open? How long does a specific model flow take to complete? How does responsiveness vary when the system is under high real or simulated end-user workload? (Can this testing be used to define what 'high end-user workload' is, for this environment, and is that enough capacity for the organization who owns it?) Does a backup job complete successfully? Does running a backup have an unacceptable impact on the rest of the system's performance? Does a restore from backup complete successfully? For components of the deployment which are highly available, does the system react in the correct way if I intentionally stop/delete/remove e.g. one pod in the replica set or equivalent. For example. does Kubernetes successfully re-start the failed pod and resume sending traffic to it when it is running again?   I expect I missed some things that people will consider important here. If your SAS environment is subject to a service level agreement (SLA), that should define metrics that can be objectively tested to validate whether the environment meets the SLA or not. So, define performance validation tests that measure those metrics, and can be automated.   Let me know in the comments below what other types of non-functional testing you think a validation procedure should include.     Validate access controls   The Security Policy and Authorization Model tasks in the SAS Viya Administration Checklist describe how access controls should be defined and documented for a SAS Viya deployment. Follow these to an extent that is proportionate in the context of how tightly or loosely your SAS Viya environment and the data it contains need to be protected from unauthorized access.   Then, again as appropriate for the degree of rigor required, you can define a series of validation tests to perform once, occasionally or regularly to prove that users who should have access to data, content and application functionality do have that access, and that users who should not, do not.   You may find some value in tools to help you automate this. pyviyatools that might help include:   explainaccess.py - a flexible tool that can explain access controls on a SAS Viya folder, report, or for another object or a service URI, for any specific user or group, or for all users and groups who have applicable access controls getruleid.py - pass in a SAS Viya object or service URI, and a user or group, and get back the ID of a SAS Viya general authorization rule that applies to that object for that user listcaslibsandeffectiveaccess.py - for a specific caslib, or for all caslibs on all CAS servers, return a list of all effective access controls in the CAS authorization system listcastablesandeffectiveaccess.py - a somewhat flexible variation of the above for CAS tables: return a list of all effective access on all CAS tables (or a specific table) in all CAS libraries (or a specific CAS library) on all servers. Can optionally include row-level permissions and permissions on source tables. listgroupsandmembers.py - return list of all groups and all their members, optionally including their email addresses (if available in the identity service's data) listrules.py - list either all general authorization rules (typically for further processing) or rules that target a specific URI and/or mention a specific user or group testfolderaccess.py - assert whether a folder is accessible to a user or not. This tool is intended to be called with a specific folder path, principal, permission and a sense (whether access with this permission is expected to be granted or not). It will respond 'TEST PASSED' or 'TEST FAILED' with the specifics of what was tested. We run a series of tests using this tool in one of our GEL workshops, to validate folder permissions for a set of folders for a set of users and groups, and show how one folder is 'incorrectly' protected (intentionally so) and causes one test in the suite to fail. As an aside, the simpler and more regular your authorization model design is, the more easily validated it will be. If validating access controls is important in your organization, time spent in carefully designing and documenting the authorization model so that it is easily understood, clearly described and simple will be much more cost-effective to the business than a haphazardly designed and carelessly implemented authorization model. It will also be far easier to validate.   Between the four general types of validation tests described above, you should be able to get a good sense of whether a SAS Viya deployment is working, useable for the purpose it was intended to be used for, performant and correctly secured. There are certainly other kinds of validation that could be performed, but I think those are the main and most common ones. But what do you think - did I miss a kind of test that everyone ought to include when they validate SAS Viya? Let me know in the comments below.     Find more articles from SAS Global Enablement and Learning here. ... View more

In this Part 2 of a two-part series, we will install and use the pyviyatools on Windows.   The pyviyatools require the SAS Viya CLI and the trusted certificates file it requires, and of course Python - preferably python3. In this guide I chose to install pyviyatools using git from a command line, though like most of the things featured in this guide, there are other ways to get it. If you followed Part 1 of this guide, Install and use the SAS Viya CLI on Windows, much of the hard work is already done.   If you have not already read and followed Part 1, I would suggest you glance at this guide to get an idea of what it covers, and then go and follow the steps in Part 1 first.   This guide documents the concluding part of one possible ‘happy path’ for setting the SAS Viya CLI and pyviyatools up on Windows from scratch. If you have some of the components already, you may find you can skip the corresponding section. But between Part 1 of this guide and the steps below, below you can find the complete process.   Contents   In Part 2 of this guide, we will cover: Dependencies Install pyviyatools and the packages it requires Python3 Upgrade pip Python3 requests module Python3 configobj module git pyviyatools Use pyviyatools from a Windows command prompt Create a .authinfo file Authenticate using loginviauthinfo.py and your .authinfo file pyviyatools Examples   No doubt this guide could be improved. If you see areas you think are overcomplicated, wrong or unnecessary, or if you have questions about why I chose a particular command or installation method, I would love to hear from you. Leave a comment below or get in touch!   Dependencies   In this Part 2, we assume all the components from Part 1 are already present, so we only need to install the things in the 'Part 2' box in the dependency diagram. We will assume that everything outside that box (the Windows client machine, chocolatey, the SAS Viya CLI and the trustedcerts.pem certificates file which the pyviyatools also requires) are already set up and validated:  Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Install pyviyatools and the packages it requires Before proceeding with these steps, ensure you have followed the steps in Part 1 of this guide, and that the SAS Viya CLI is working from a Windows Command Prompt on your Windows machine, that it is connected to your SAS Viya deployment, and that you can authenticate successfully with a SAS Viya username and password and can run SAS Viya CLI commands successfully. To set up pyviyatools and the things it requires, we return to using PowerShell.   Python3 There are many ways to install Python on a Windows machine, and any of them should be okay if you can run python --version , from both PowerShell and Windows Command Prompt and get a Python 3.x.x version number in response. For the sake of consistency, we will install it using chocolatey here. Open a new PowerShell terminal window, and see if Python3 is already installed: python --version If Python3 is installed, you should see something like this, and you can continue to the next section, to upgrade pip: Python 3.11.4 If Python3 is not installed, you should see something like this (in red): python3 : The term 'python3' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + python3 --version + ~~~~~~~ + CategoryInfo : ObjectNotFound: (python3:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException If Python3 is not installed, run this command to install Python3 using chocolatey, which takes a few minutes: choco install python3 -y After installing python, close the PowerShell terminal, and open a new one. Then, run python --version again to verify that Python3 is installed and in your path. You should see something like this: Python 3.11.4 Upgrade pip   From a PowerShell terminal, run this to upgrade the Python package manager, pip: python.exe -m pip install --upgrade pip   Python3 requests module   From a PowerShell terminal, run this to install the Python3 requests module, a rich set of tools for making HTTP requests, e.g. for calling REST APIs like those exposed by SAS Viya: python -m pip install requests   Python3 configobj module   From a PowerShell terminal, run this to install the Python3 configobj module, a config file reader and writer: python -m pip install configobj   git Install git if it is not already installed. Git can be installed many ways; any method is probably fine so long as you end up getting a response similar to that shown below when you run git version . Since we are using chocolatey to install other packages in these instructions, we may as well pick that method for this step. See whether git is already installed. In the PowerShell terminal window, run this: git version If you see something like this, git is already installed: git version 2.41.0.windows.1 If you see something like this, git is not installed: git : The term 'git' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + git + ~~~ + CategoryInfo : ObjectNotFound: (git:String) [], CommandNotFoundException If git is not already installed, run this to install it: choco install git.install -y After installing git, close the PowerShell terminal, and open a new one. Then, run git version again to verify that git is installed and in your path. You should see something like this: git version 2.41.0.windows.1 pyviyatools We are finally ready to deploy pyviyatools. Clone the pyviyatools project from GitHub into C:\ViyaHome, using git. pyviyatools is a public project, so you do not need to authenticate to GitHub. Run this from the PowerShell terminal: Push-Location Set-Location Env: cd C:\ViyaHome git clone https://github.com/sassoftware/pyviyatools.git Pop-Location Verify that the pyviyatools project was cloned to C:\ViyaHome\pyviyatools: dir C:\ViyaHome\pyviyatools Partial expected output (with some files omitted): PS C:\Users\student> dir C:\ViyaHome\pyviyatools Directory: C:\ViyaHome\pyviyatools Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 7/14/2023 6:24 AM templates -a---- 7/14/2023 6:24 AM 57 .gitattributes -a---- 7/14/2023 6:24 AM 153 .gitignore -a---- 7/14/2023 6:24 AM 70 application.properties -a---- 7/14/2023 6:24 AM 6521 applyauthmodel.py -a---- 7/14/2023 6:24 AM 4857 applyfolderauthorization.py -a---- 7/14/2023 6:24 AM 4308 applyviyarules.py -a---- 7/14/2023 6:24 AM 7899 archivefiles.py -a---- 7/14/2023 6:24 AM 3656 callrestapi.py ... Some files omitted ... -a---- 7/14/2023 6:24 AM 3987 toggleviyarules.py -a---- 7/14/2023 6:24 AM 5327 unittestsadm33.sh -a---- 7/14/2023 6:24 AM 8687 unittestsadm34.sh -a---- 7/14/2023 6:24 AM 4563 unittestviya4.sh -a---- 7/14/2023 6:24 AM 3150 updatedomain.py -a---- 7/14/2023 6:24 AM 4731 updatepreferences.py -a---- 7/14/2023 6:24 AM 7843 validateviya-manual.md -a---- 7/14/2023 6:24 AM 23618 validateviya.py PS C:\Users\student> Run the pyviyatools setup.py script. This tool uses the Python3 configobj module we installed earlier to set values in a pyviyatools configuration file called application.properties . In the PowerShell terminal window, run this, substituting the location where you installed the sas-viya CLI executable for C:\ViyaHome\CLI , if it is somewhere else on your Windows machine. Recall that we installed and configured the SAS Viya CLI in Part 1 of this guide. cd C:\ViyaHome\pyviyatools ./setup.py --clilocation C:\ViyaHome\CLI --cliexecutable sas-viya Expected output: Note: updating C:\ViyaHome\pyviyatools\application.properties NOTE: configuration values set to {'sascli.location': 'C:\\ViyaHome\\CLI', 'sascli.executable': 'sas-viya'} Optional: If you want to be able to run pyviyatools without specifying the path, add the pyviyatools directory to your path. In the PowerShell terminal window, run this: [Environment]::SetEnvironmentVariable("Path",[Environment]::GetEnvironmentVariable("Path", [EnvironmentVariableTarget]::Machine) + ";C:\ViyaHome\pyviyatools", [EnvironmentVariableTarget]::Machine) Close the PowerShell terminal window, and open a new one, to pick up the change to the machine’s path environment variable. Use pyviyatools from a Windows command prompt   Create a .authinfo file   Create a .authinfo file. In the following command, I have used the username and password of a SAS Viya administrator account: user geladm , password lnxsas . Substitute the username and password of the account you wish to use by default for these values in the command below. In the PowerShell terminal window, run this $authinfo_file=$HOME+'\.authinfo' [IO.File]::WriteAllLines($authinfo_file, 'default user geladm password lnxsas') type $authinfo_file Note: We use WriteAllLines here to write the line to the .authinfo file, because when I used echo , the character encoding ended up being UTF-16, which was not understood by python3’s configObj module.   Authenticate using loginviauthinfo.py and your .authinfo file I have not had success getting this working from a PowerShell prompt yet, so here we switch to a Windows command prompt. Open a new Windows Command Prompt window, to pick up any changes we made to your path environment variable. In the command prompt, run this. (If you did not add the pyviyatools path to your path environment variable, you will need to specify the full path to loginviauthinfo.py and any other pyviyatools you run, e.g. C:\ViyaHome\pyviyatools\loginviauthinfo.py 😞 set current_namespace=gelcorp set SAS_CLI_PROFILE=%current_namespace% set SSL_CERT_FILE=%USERPROFILE%\.certs\%current_namespace%_trustedcerts.pem set REQUESTS_CA_BUNDLE=%SSL_CERT_FILE% loginviauthinfo.py Expected result (showing your profile name instead of ‘ gelcorp ’, your ingress host instead of ‘ gelcorp.rext03-0175.race.sas.com ’ and your SAS Viya user – ideally an administrator – instead of ‘ geladm ’): C:\Users\student>loginviauthinfo.py Logging in with profile: gelcorp Getting Credentials for: gelcorp.rext03-0175.race.sas.com Logging in as user: geladm Enter credentials for https://gelcorp.rext03-0175.race.sas.com: Login succeeded. Token saved. C:\Users\student> Pyviyatools Examples The results of each of the following examples is from one of the GEL workshop environments. Obviously the caslibs, members of SAS Administrators group, folder ids, launcher context details and so on will vary between SAS Viya deployments. List caslibs in your default CAS server   In the command prompt, run this (prefixed with C:\ViyaHome\pyviyatools\ or the path you to your copy of the pyviyatools, if you did not add the pyviyatools directory to your path): listcaslibs.py Expected output (caslibs shown depend on the caslibs visible to your authenticated user in your SAS Viya deployment – caslibs visible to my administrative user, geladm , in my SAS Viya deployment are shown in the output below): C:\Users\student>listcaslibs.py server,caslib cas-shared-default,CASUSER(geladm) cas-shared-default,Financial Data cas-shared-default,Formats cas-shared-default,hrdl cas-shared-default,ModelPerformanceData cas-shared-default,Models cas-shared-default,Public cas-shared-default,salesdl cas-shared-default,Samples cas-shared-default,SystemData C:\Users\student> List members of the SAS Administrators group   In the command prompt, run this: listgroupsandmembers.py --id SASAdministrators Expected output: groupid,groupname,grouptype,groupproviderid,memberid,membername,membertype,memberproviderid SASAdministrators,SAS Administrators,group,local,geladm,"geladm",user,ldap SASAdministrators,SAS Administrators,group,local,GELCorpSystemAdmins,"GELCorp System Admins",group,ldap Get the folderid of the /Public folder   In the command prompt, run this: getfolderid.py --f /Public Expected output: creationTimeStamp ,createdBy ,modifiedTimeStamp ,modifiedBy ,version ,id ,name ,description ,type ,memberCount ,properties , "2023-07-13T08:08:51.478982Z","anonymous","2023-07-13T08:08:51.478982Z","anonymous","1","fef7a224-d3fd-4c03-8a51-fdd05b0cbfe0","Public","Public folder for general access.","folder","0","{'allowMove': 'false', 'uuid': '935842da-9ba0-479c-99e3-6a4e489322fc'}", Compare this output with that from the sas-viya folders show command: sas-viya --output text folders show --path /Public Explain the access controls on the /Public folder   In the command prompt, run this: explainaccess.py -f /Public --header Expected output: principal,read,update,delete,secure,add,remove,read(convey),update(convey),delete(convey),secure(convey),add(convey),remove(convey) authenticatedUsers,grant*,prohibit,prohibit,prohibit,grant*,grant*,grant*,grant*,grant*,prohibit,grant*,grant* SASAdministrators,grant,grant,grant,grant,grant,grant,grant,grant,grant,prohibit,grant,grant Validate your SAS Viya platform is working   In the command prompt, run this: validateviya.py Expected output: Data Collection Test Started: Logged in User Data Collection Test Started: List Users Data Collection Test Started: List Base Folders Data Collection Test Started: List CAS Servers Data Collection Test Started: List CAS Server Metrics Data Collection Test Started: List CAS Server Caslibs Data Collection Test Started: List CASLib Tables Computation Test Started: Run Test SAS Code name ,id "geladm","geladm" name ,id "SAS LDAP Service Account","sasldap" "SAS System Account","sas" "CAS System Account","cas" "SAS Administrator","sasadm" "SAS Test User 1","sastest1" "SAS Test User 2","sastest2" "geladm","geladm" "Douglas","Douglas" "Delilah","Delilah" "Alex","Alex" "Amanda","Amanda" "Ahmed","Ahmed" "Fay","Fay" "Fernanda","Fernanda" "Fiona","Fiona" "Frank","Frank" "Fred","Fred" "Hamish","Hamish" "Hazel","Hazel" "Heather","Heather" "Helena","Helena" "Henrik","Henrik" "Hugh","Hugh" "Santiago","Santiago" "Sarah","Sarah" "Sasha","Sasha" "Sean","Sean" "Sebastian","Sebastian" "Shannon","Shannon" "Sheldon","Sheldon" "Sophia","Sophia" "hrservice","hrservice" "salesservice","salesservice" "financeservice","financeservice" name ,description "Users","Base Folder for all user folders." "Public","Public folder for general access." "Products","Products folder for samples, canned objects and other SAS-provided content." "gelcontent","Base folder" "Conversational Flows","Conversational Flows Folder" "Model Repositories","None" name ,host ,port ,description "cas-shared-default","sas-cas-server-default-client","5570","controller" serverName ,systemNodes ,systemCores ,cpuSystemTime ,memory "cas-shared-default","4","32","0.013651","1319040" name ,scope ,description "CASUSER(geladm)","global","Personal File System Caslib" "Financial Data","global","gelcontent finance" "Formats","global","Stores user defined formats." "hrdl","global","gelcontent hrdl" "ModelPerformanceData","global","Stores performance data output for the Model Management service." "Models","global","Stores models created by Visual Analytics for use in other analytics or SAS Studio." "Public","global","Shared and writeable caslib, accessible to all users." "salesdl","global","gelcontent salesdl" "Samples","global","Stores sample data, supplied by SAS." "SystemData","global","Stores application generated data, used for general reporting." serverName ,caslibName ,name "cas-shared-default","systemData","AUDIT" "cas-shared-default","systemData","AUDIT_ACTIVITIES" "cas-shared-default","systemData","AUDIT_ACTIVITIES_PROPERTIES" "cas-shared-default","systemData","AUDIT_ACTIVITIES_URIS" "cas-shared-default","systemData","SASVIYATYPES" runSuccessful ,jobState "True","completed" From here on, you should be able to run sas-viya commands and run any of the pyviyatools as permitted by the versions of the software you have available, and the permissions of the user you defined in your .authinfo file. The SAS Viya CLI has an extensive set of plugins, documented in SAS Help Center here: https://go.documentation.sas.com/doc/en/sasadmincdc/default/calcli/n1vth8mtb8ipprn1prz5j26p3nvc.htm.   pyviyatools provides many convenient tools/scripts which my GEL colleague Gerry Nelson and I, and a number of other contributors have written to enable or simplify certain tasks in SAS Viya. It is documented in markdown files in the pyviyatools project in GitHub, particularly in: README.md: https://github.com/sassoftware/pyviyatools/blob/master/README.md INSTALL.md: https://github.com/sassoftware/pyviyatools/blob/master/INSTALL.md loginviauthinfo.md describes how to use loginviauthinfo.py, one of our most useful tools, to authenticate to SAS Viya before running either pyviyatools or SAS Viya CLI commands: https://github.com/sassoftware/pyviyatools/blob/master/loginviauthinfo.md EXAMPLES.md: https://github.com/sassoftware/pyviyatools/blob/master/EXAMPLES.md SUPPORT.md: https://github.com/sassoftware/pyviyatools/blob/master/SUPPORT.md CONTRIBUTING.md: https://github.com/sassoftware/pyviyatools/blob/master/CONTRIBUTING.md All the tools I have tried in the course of writing this guide worked well on Windows, as they are supposed to. However, due to the nature of our work, my fellow pyviyatools developers and I use them in LINUX more than in Windows. The tools are supposed to work the same on both but it is possible that you may find a tool that does not work as well on Windows as it does in LINUX. Please let us know about any issues that you come across while using the pyviyatools, by raising an issue in the pyviyatools project or by emailing one of us. It would help if you mention that you are using it in Windows, if you are. My thanks to Gerry Nelson and Allan Tham for their help in discussing and refining some of the things I included in this guide, and to Gerry in particular for his work in developing and publishing the pyviyatools.   See you next time!   Find more articles from SAS Global Enablement and Learning here. ... View more

In this Part 1 of a two-part series, we will go through a beginning-to-end process to install, configure and use the SAS Viya Command-Line interface on Windows. In Part 2, we will install and use the pyviyatools on Windows, which will be a little simpler, once we have done the hard work of completing Part 1.   Why do we need guides like this? Is it not all documented already? Well, yes... but...   In the SAS Global Enablement and Learning team, we (and people attending our workshops) normally install and use both the SAS Viya CLI and pyviyatools on Linux machines. Even if we want to run these tools from our own Windows laptop or desktop, we generally find it convenient to do so from a Bash shell running in Windows Subsystem for Linux. If this is an option for you, it is really nice. Installation of these tools in Linux is comparatively straightforward, and seems much easier to script than it is on Windows.   However, customers whose end users have Windows machines often want to install the SAS Viya CLI and pyviyatools on those Windows machines. Both tool sets do run on Windows, but beginning-to-end instructions for how to set up all the various components and dependencies are hard to find. It seems you have to piece them together from documentation in several different places, which is tedious.   This guide is therefore one possible ‘happy path’ for setting these tools up on Windows from scratch. There are a LOT of steps, which may be part of the reason why there are few other guides to the whole procedure. If you have some of the components already, you may find you can skip the corresponding section. But below you can find the complete process. I hope it turns out to be useful.   Contents   In Part 1 of this guide, we will cover: Dependencies Prerequisites Windows Client Machine PowerShell and Windows Command Prompt are both required Installation directories Install the SAS Viya CLI Installing the SAS Viya CLI is difficult to automate Download SAS Viya CLI using a web browser Install SAS Viya CLI and its plugins Enable SAS Viya CLI to communicate with SAS Viya Chocolatey curl kubectl kubeconfig file Certificates file Define SAS Viya CLI profiles Validate that sas-viya CLI can access your SAS Viya deployment Use the SAS Viya CLI from a Windows command prompt SAS Viya CLI Examples No doubt this guide could be improved. If you see areas you think are overcomplicated, wrong or unnecessary, or if you have questions about why I chose a particular command or installation method, I would love to hear from you. Leave a comment below or get in touch!   Dependencies   The following diagram shows how the packages required to use the SAS Viya CLI and pyviyatools depend on each other, for installation and at run time, and how some of them depend on prerequisites.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   The green boxes are things that we will install if they are not already installed. Really, all the things in green boxes require a Windows client machine, but showing that would not make the diagram any more clear.   The SAS Viya CLI has been carefully designed not to have much in the way of dependencies. However, if you have enabled Transport Layer Security for your SAS Viya platform, the Windows machine where the SAS Viya CLI runs must trust the certificates presented by the SAS Viya server in order to communicate with it. This is achieved by providing it with a bundle of trusted CA certificates, shown as ‘certificates file’ in the diagram. SAS Help Center's Command-Line Interface: Preliminary Instructions explain this in more detail. They also explain how to obtain that file using kubectl and a kubeconfig file, steps which are a part of this guide.   Since our goal is to install both the SAS Viya CLI and pyviyatools, we may as well use kubectl (a pre-requisite of pyviyatools) to get the necessary certificate file ourselves, rather than just having you provide it as a prerequisite.   Your Windows machine may already have some of these tools installed. If you find you already have a component like python3 or git, or you prefer to install it some other way, that is fine. You may need to adapt some of the installation instructions below to adapt for differences between your machine and the more-or-less new Windows VM I used to write the instructions.   Prerequisites   Pre-requisites are shown as grey boxes in the dependency diagram. This article does not cover how to create: A SAS Viya deployment, in a Kubernetes cluster. Your Kubernetes administrator, SAS Administrator, deployment consultant or service provider sets this up. A kubeconfig file is required to deploy SAS Viya. You could use this kubeconfig file, or another one that your Kubernetes administrator provides, whichever they prefer. When SAS Viya is deployed, a trustedcerts.pem certificates file is created automatically as part of that process, and is stored by the SAS Logon service. No additional steps are required to create this, and we will get a copy of it during the process described in this guide. A username and password that allow you to authenticate to your SAS Viya deployment, preferably as a SAS Administrator. Get this from your SAS Administrator. A Windows client machine on which you can install the chocolatey package manager, curl, kubectl and the sas-viya CLI, and if you continue to part2 (coming soon), python3 and its requests and configobj modules, git and finally pyviyatools. Windows Client Machine   You will need a Windows machine to try installing SAS Viya CLI and pyviyatools. Use your own Windows desktop/laptop if you like and have sufficient permissions.     PowerShell and Windows Command Prompt are both required   I have chosen to use both PowerShell and Windows Command Prompt for this guide, since each is required for certain tasks.   PowerShell has better commands (cmdlets) for things like setting environment variables and unzipping .zip archives, and it is likely the shell a modern Windows administrator will be more familiar with. However, I have not yet discovered how to (or if you can) run the sas-viya CLI in PowerShell.   I found fewer examples showing how to install packages we need using Windows Command Prompt, so it would take more work to convert these instructions to run solely in a Command Prompt, though I think you could. The SAS Viya CLI and pyviyatools both work in a Command Prompt, and I think it is arguably more familiar to non-Windows administrators.   I would love to hear from you if: you know how to get the SAS Viya CLI working in PowerShell (or if you know for sure that you can’t) you can convert all steps in this guide to work in Windows Command Prompt without too much additional complexity   Installation directories   These instructions put kubectl, a kubeconfig file, the sas-viya CLI executable, and pyviyatools in the following directories: Tool or file Directory Kubectl C:\Program Files\kubectl Kubeconfig file $HOME\.kube\config SAS Viya certificates $HOME\.certs SAS Viya CLI executable C:\ViyaHome\CLI pyviyatools C:\ViyaHome\pyviyatools But none of them have to be in those directories. You are free to put any of these things in a different directory, as required by your Windows machine’s disk space or permission constraints, or to suit your preferences. Modify references to the path for each component in e.g. environment variables accordingly.   Install the SAS Viya CLI   In this Part 1 of the guide, we will install the SAS Viya CLI, but also install chocolatey, curl and kubectl, and provide a kubeconfig file so that we can get the certificates file that the SAS Viya CLI needs to trust TLS certificates presented by SAS Viya. If your goal is to set up the SAS Viya CLI only, and not pyviyatools, you can stop at the end of part 1.   Other readers may want to continue on to part 2, to install pyviyatools on Windows. Since pyviyatools depends on the SAS Viya CLI, and because in part 2. I chose to use the chocolatey package manager to install python and git, you should complete part 1 of this guide first even if your main aim is to install pyviyatools.   Preliminary set-up instructions for the SAS Viya CLI can be found in the SAS Help Center documentation at: https://go.documentation.sas.com/doc/en/sasadmincdc/default/calcli/n1e2dehluji7jon1gk69yggc6i28.htm   Installing the SAS Viya CLI is difficult to automate   Unless you have a tool that can navigate to a web page in a browser and click a button in that web page automatically, you cannot fully automate installation of the SAS Viya CLI. Such tools are commonly used to functionally test web pages (among other things), but most of us don’t have one, and it doesn’t make sense to spend the money or effort setting one up just to script this one step.   Without such a tool, you must either: click a button on a web page popup dialog in your browser, in order to accept the ‘SAS License Agreement for Download’, or download the SAS Viya CLI executable ahead of time, and provide it e.g. in a volume accessible to scripts which you can run on your Windows client machine. We prefer option '2' above for our workshop environments. For these instructions, option '1' above is simpler.     Download SAS Viya CLI using a web browser   In a web browser in your Windows client machine, search the web for "SAS Viya CLI download" or browse to https://support.sas.com/downloads/package.htm?pid=2512. I used Chrome on my machine, but any browser should work fine. Sign in to sas.com. In the web page that opens once you have signed in, find the download link for ‘sas-viya for Windows’:   At the time of writing this was sas-viya-cli-1.21.10-windows.zip, but this is updated quite regularly; you should choose the current version. Click the link to download the .zip file.   Read the ‘SAS License Agreement for Download’ and click the ‘Accept’ button if you accept it:   Note: This step cannot currently be automated without software which I think is too expensive or complex to recommend for this use case alone.   Since I used Chrome as my browser, the .zip file was automatically downloaded to $HOME\Downloads (aliased as %USERPROFILE%\Downloads if you are using Windows Command Prompt). Other browsers may place the .zip file in another location by default. If they do not save it to your Downloads directory by default, Save As, move or copy it there yourself.   Install SAS Viya CLI and its plugins   Open a new PowerShell terminal window. It may be convenient to pin it to the Windows Task Bar or Start Menu. In your PowerShell terminal window, and run this to create a directory to contain the extracted SAS Viya CLI executable, unzip the downloaded file to $HOME\Downloads\sas-viya-cli, and to then copy the sas-viya.exe executable to C:\ViyaHome\CLI: mkdir C:\ViyaHome\CLI $files = Get-ChildItem $HOME\Downloads\sas-viya-cli*.zip | select-object -first 1 foreach($f in $files){Expand-Archive $f -DestinationPath C:\ViyaHome\CLI} Get-ChildItem C:\ViyaHome\CLI Tip: Scroll the textbox above to the right if necessary.   Run this to install the sas-viya CLI plugins – they are automatically installed to a new directory, at $HOME\.sas: cd C:\ViyaHome\CLI .\sas-viya plugins install --repo SAS all Add the sas-viya CLI directory path to your machine’s Path environment variable. In the PowerShell terminal window, run this: [Environment]::SetEnvironmentVariable("Path",[Environment]::GetEnvironmentVariable("Path", [EnvironmentVariableTarget]::Machine) + ";C:\ViyaHome\CLI", [EnvironmentVariableTarget]::Machine) Tip: Scroll the textbox above to the right if necessary, to see the whole command.   Close the PowerShell terminal window. We will open a new one in the next step, to pick up the change to the machine’s path environment variable.   Enable SAS Viya CLI to communicate with SAS Viya   We will need to provide a certificates file and set some environment variables before we can use the SAS Viya CLI to connect to our SAS Viya deployment. To get the certificates file, we will set up kubectl and provide a kubeconfig file (see Prerequisites  above) for the Kubernetes cluster where the SAS Viya platform is running. This set of steps is performed in PowerShell.   Chocolatey   Chocolatey is an open-source command-line package manager for Windows. We will use it to install packages in both Part 1 and part 2 of this guide.   The following instructions are based on Chocolatey Software Docs | Setup / Install (https://docs.chocolatey.org/en-us/choco/setup). With the Windows VM I used to develop these instructions, the first attempt at installation results in an error message asking you to restart the machine, and the second attempt at installation succeeds. Open a new Windows PowerShell terminal window. Run this command: Get-ExecutionPolicy If the response is Unrestricted , continue to next step. If the response is Restricted , then run one of these commands: Set-ExecutionPolicy AllSigned or Set-ExecutionPolicy Bypass -Scope Process Run this to install Chocolatey. Installation takes several minutes, and at one stage there will be no new console output for several (5-10) minutes: Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1')) Tip: Scroll the textbox above to the right if necessary, to see the whole command. If the previous command finishes by showing the message below (in red – but don’t panic, it’s okay!), do what the message says and reboot your Windows machine: .NET Framework 4.8 was installed, but a reboot is required. Please reboot the system and try to install/upgrade Chocolatey again. At C:\Users\student\AppData\Local\Temp\2\chocolatey\chocoInstall\tools\chocolateysetup.psm1:815 char:11 + throw ".NET Framework 4.8 was installed, but a reboot is re ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (.NET Framework ...ocolatey again.:String) [], RuntimeException + FullyQualifiedErrorId : .NET Framework 4.8 was installed, but a reboot is required. Please reboot the system and try to install/upgrade Chocolatey again. Once your Windows machine has restarted, sign in again, and open a PowerShell terminal window again. Re-run the command above to try installing Chocolatey again. This time it should complete in a few seconds, and be successful:   curl   Run this command in the same PowerShell window to install curl: choco install curl -y kubectl See Install and Set Up kubectl on Windows | Kubernetes for the latest instructions. Create a directory for the kubectl executable. It does not have to be in C:\Program Files\kubectl, but that path seems logical to me. In the PowerShell terminal window, run this: mkdir "C:\Program Files\kubectl" Install kubectl. In the PowerShell terminal window, run this. You should cd to the directory you created in the previous step. And this curl command fetches the current version of kubectl (1.27.2) at the time I wrote this guide. See Install and Set Up kubectl on Windows | Kubernetes for the latest version, as new versions are released frequently. You may need to find the version of Kubernetes your cluster is running, and use a compatible version of kubectl. cd "C:\Program Files\kubectl" curl.exe -LO https://dl.k8s.io/release/v1.27.2/bin/windows/amd64/kubectl.exe Validate kubectl. In the PowerShell terminal window, run this: & "C:\Program Files\kubectl\kubectl.exe" version --client --output=yaml Expected output, showing the version of kubectl you just installed: PS C:\Program Files\kubectl> & "C:\Program Files\kubectl\kubectl.exe" version --client --output=yaml clientVersion: buildDate: "2023-05-17T14:20:07Z" compiler: gc gitCommit: 7f6f68fdabc4df88cfea2dcf9a19b2b830f1e647 gitTreeState: clean gitVersion: v1.27.2 goVersion: go1.20.4 major: "1" minor: "27" platform: windows/amd64 kustomizeVersion: v5.0.1 PS C:\Program Files\kubectl> Add the kubectl directory path to your machine’s Path environment variable. In the PowerShell terminal window, run this, if necessary substituting the full path to the directory where you installed kubectl for C:\Program Files\kubectl if you installed it somewhere else: [Environment]::SetEnvironmentVariable("Path",[Environment]::GetEnvironmentVariable("Path", [EnvironmentVariableTarget]::Machine) + ";C:\Program Files\kubectl", [EnvironmentVariableTarget]::Machine) Tip: Scroll the textbox above to the right if necessary, to see the whole command. Close the PowerShell terminal window and open a new one, to pick up the change to the machine’s path environment variable. Test that kubectl is now in your path. Run this from any directory in the PowerShell command window (it should also work from a Windows command prompt): kubectl version --client --output=yaml Expected output, showing the version of kubectl you just installed: PS C:\Users\student> kubectl version --client --output=yaml clientVersion: buildDate: "2023-05-17T14:20:07Z" compiler: gc gitCommit: 7f6f68fdabc4df88cfea2dcf9a19b2b830f1e647 gitTreeState: clean gitVersion: v1.27.2 goVersion: go1.20.4 major: "1" minor: "27" platform: windows/amd64 kustomizeVersion: v5.0.1 PS C:\Users\student> kubeconfig file   Create a directory for the kubeconfig file. In the PowerShell terminal window, run this: mkdir $HOME\.kube Copy your kubeconfig file (see Prerequisites above) to the file path and filename $HOME\.kube\config . Make sure the file does not have a filename extension such as .txt . The kubeconfig file should be named simply config . Tips:   Get a kubeconfig file from the Kubernetes cluster administrator who maintains the Kubernetes cluster that SAS Viya is deployed into. If you want to give it another name, or put it in another directory, you can define an environment variable called KUBECONFIG and give it the value of the path to the kubeconfig file you want to use, and then kubectl will use that config file. This is useful if you have more than one kubeconfig file and wish to switch between them. You can specify a kubeconfig file on the kubectl command line ( kubectl --kubeconfig path ), but if becomes a bit cumbersome and clutters up the command, so I prefer not to do that. Run this from the PowerShell terminal prompt to view the contents of the kubeconfig ( config ) file to verify it is in the expected location: type $HOME\.kube\config Here is a screenshot showing the content of a config file (with the certificate data obscured). Yours should resemble this, though the server, cluster, user and context names will differ:       Validate that you now have access to your Kubernetes cluster using kubectl and your kubeconfig file. Run this from any directory in the PowerShell command window (it should also work from a Windows command prompt): kubectl get ns Expected output is a list of the namespaces in your Kubernetes cluster, e.g. here in PowerShell, but the output is almost identical from a command prompt. We will switch to using a command prompt later, when we use the sas-viya CLI: PS C:\Users\student> kubectl get ns NAME STATUS AGE argo Active 10d cert-manager Active 10d default Active 10d gelcorp Active 10d kube-node-lease Active 10d kube-public Active 10d kube-system Active 10d nfs Active 10d nginx Active 10d v4mlog Active 10d v4mmon Active 10d PS C:\Users\student> One of the Kubernetes namespaces should be the namespace where SAS Viya is deployed – in the example above, that namespace is gelcorp .   Note: It is useful to be able to connect to more than one SAS Viya deployment. So, I prefer to include the namespace name in any configuration variables or file names which refer to that SAS Viya deployment. Therefore, from here on in this guide, wherever you see the string gelcorp in a variable or file name, you should substitute the name of your SAS Viya namespace into that variable or filename, instead of gelcorp .   Certificates file   In this step, we copy a trustedcerts.pem certificates file from the SAS Logon service in your SAS Viya deployment to allow the SAS Viya CLI to trust the TLS certificates that SAS Viya will present to it. If you have not enabled TLS for communication between your SAS Viya deployment and external clients (browsers and the CLI), and you access SAS Viya using http, not https, you may be able to skip this step. Create a directory for the certificates. In the PowerShell terminal window, run this: mkdir $HOME\.certs Optional: See the name of your SAS Viya deployment's sas-logon-app pod. Remember to replace gelcorp in the command which follows with the name of your SAS Viya deployment’s namespace. In the PowerShell terminal window, run this: kubectl -n gelcorp get pod -l 'app=sas-logon-app' Store the sas-logon-app pod name in a variable: $SAS_LOGON_APP_POD_NAME=$(kubectl -n gelcorp get pod -l 'app=sas-logon-app' | select-string sas-logon-app | Foreach-Object { $_.ToString() -split '\s+'} | select-object -first 1) echo $SAS_LOGON_APP_POD_NAME Copy the trustedcerts.pem file from the sas-logon-app container in the sas-logon-app pod to a file named gelcorp_trustedcerts.pem in the .certs directory you just created. Run this in PowerShell, substituting all occurrences of gelcorp for your namespace name: Push-Location Set-Location Env: cd $HOME kubectl -n gelcorp cp $SAS_LOGON_APP_POD_NAME":security/trustedcerts.pem" .certs\gelcorp_trustedcerts.pem -c sas-logon-app Pop-Location Note: The code above can surely be improved. I had trouble concatenating the destination path $HOME\.certs\gelcorp_trustedcerts.pem in the command, so I had to change directory instead, and for neatness change back afterwards. Let me know if you see a neater way to do that! Verify you got the certs file, again substituting gelcorp for your namespace name: type $HOME\.certs\gelcorp_trustedcerts.pem Expected results – LOTS of output!     Define SAS Viya CLI profiles   Optional: see details of the ingress defined for your Viya deployment’s sas-logon-app service. Remember to replace gelcorp in the command which follows with the name of your SAS Viya deployment’s namespace. In the PowerShell terminal window, run this: kubectl -n gelcorp get ing | findstr sas-logon-app Expected output is something resembling this, showing in this example that the ingress hostname is gelcorp.pdcesx03038.race.sas.com : PS C:\Users\student> kubectl -n gelcorp get ing | findstr sas-logon-app sas-logon-app nginx gelcorp.pdcesx03038.race.sas.com,*.gelcorp.pdcesx03038.race.sas.com 10.43.17.23 80, 443 10d Get the ingress URL and store it in a shell variable. In the PowerShell terminal window, run this – you might need to modify it to fit the string returned from kubectl get ing on your environment, and again, remember to replace both occurrences of gelcorp in the command which follows with the name of your SAS Viya deployment’s namespace: $INGRESS_URL=$(kubectl -n gelcorp get ing | select-string sas-logon-app | Foreach-Object { $_.ToString() -split '\s+'} | select-string gelcorp |%{$_ -split ','} | select-object -first 1) echo $INGRESS_URL In your PowerShell terminal window, create a default sas-viya CLI profile which will be used if you don't specify which profile to use when calling the sas-viya executable, and one for your SAS Viya namespace, e.g. mine is called gelcorp , but you should name yours for your SAS Viya namespace. Specify http or https as appropriate for the endpoint: sas-viya.exe --profile Default profile set-endpoint https://$INGRESS_URL sas-viya.exe --profile Default profile toggle-color off sas-viya.exe --profile Default profile set-output fulljson sas-viya.exe --profile gelcorp profile set-endpoint https://$INGRESS_URL sas-viya.exe --profile gelcorp profile toggle-color off sas-viya.exe --profile gelcorp profile set-output fulljson Validate that sas-viya CLI can access your SAS Viya deployment   Now you have everything you need to access a SAS Viya deployment using the SAS Viya CLI. Let’s validate that we can, using the Windows Command Prompt.   Note: This step uses Windows Command Prompt, not PowerShell! Open a Windows Command Prompt terminal window. It may be convenient to pin it to the Windows Task Bar or Start Menu. In your Windows Command Prompt set environment variables for using the sas-viya CLI. As before, substitute the name of your SAS Viya deployment's namespace for gelcorp : set current_namespace=gelcorp set SAS_CLI_PROFILE=%current_namespace% set SSL_CERT_FILE=%USERPROFILE%\.certs\%current_namespace%_trustedcerts.pem set REQUESTS_CA_BUNDLE=%SSL_CERT_FILE% Run this (from any directory) in your Windows Command Prompt to log in to your SAS Viya deployment from the SAS Viya CLI. Provide the username and password of the account you will use to login to SAS Viya (see Prerequisites above), in place of username geladm password lnxsas in the example below: sas-viya auth login -u geladm -p lnxsas Expected output is something like this: C:\Users\student>sas-viya auth login -u geladm -p lnxsas Enter credentials for https://gelcorp.pdcesx03038.race.sas.com: Login succeeded. Token saved. C:\Users\student> You should now be able to run sas-viya commands to do anything that username is authorized to do. Try using the SAS Viya CLI to get information about the SAS Administrators group: sas-viya identities list-groups --id SASAdministrators Expected output is something like this (with some lines omitted): C:\Users\student>sas-viya identities list-groups --id SASAdministrators { "items": [ { "creationTimeStamp": "2023-07-13T08:15:30.881Z", "description": "Provides assumable access throughout the general authorization system.", "id": "SASAdministrators", "links": [ --- some lines omitted--- ], "modifiedTimeStamp": "2023-07-13T08:15:30.881Z", "name": "SAS Administrators", "providerId": "local", "state": "active", "type": "group", "version": 1 } ] } If you see JSON output similar to that above, your SAS Viya CLI has successfully authenticated and run a command against your SAS Viya deployment. Let’s try a few more examples.   Use the SAS Viya CLI from a Windows command prompt   Note: This step uses Windows Command Prompt, not PowerShell!   SAS Viya CLI Examples   There are lots of other videos and blog posts describing use of the sas-viya CLI. A search here, or using your favorite web search engine will produce many results, and I'd encourage you to explore topics, tasks and plugins that seem interesting to you. It is a fantastic set of tools! But here, I'll pick some examples that seem interesting to me - and I hope to you.   The results of each of the following examples is from one of the GEL workshop environments. Obviously the values returned will vary between SAS Viya deployments, so expect your results to differ from mine, and go explore what you can do!   See the usage help text for the sas-viya compute contexts command All sas-viya plug-ins, including the compute plug-in are designed to be self-documenting. Add a -h at the end of any partial command to see what sub-commands, command options and arguments it can take. This is a great way to discover what they can do. In the command prompt, run this to see usage for the sas-viya compute contexts command: sas-viya compute contexts -h Expected output (other versions of the plugin may offer different options and arguments to these): NAME: sas-compute-cli contexts - Manages the compute contexts. USAGE: sas-compute-cli contexts command [command options] [arguments...] VERSION: 1.37.8 COMMANDS: create Creates a compute context. delete, del Deletes a compute context by name, ID, or ordinal. generate-template, gen Generates a template to create a compute context. help, h Shows a list of commands or help for one command. list Lists the compute contexts' names and IDs. show Shows a compute context by name, ID, or ordinal. show-template, show-t Shows a template that is used to create a compute context. validate, val Validates the compute context session. OPTIONS: --help, -h Shows help. List compute contexts In the command prompt, run this to list compute contexts currently defined in your SAS Viya deployment (and that your current user is authorized to see): sas-viya compute contexts list Expected output (your compute contexts may differ to these, and the IDs will be different): 1. SAS Studio compute context c4eeed2e-2c5e-48ee-ac69-9c82889a4081 2. SAS Job Execution compute context 14f5cc90-bd7c-4306-bee2-830cd6c34bee 3. CAS Formats service compute context 4c786325-25d0-46e6-81d7-038d3bc9efa7 4. CAS Management service compute context 989ba5c6-2ede-4011-90e2-d69110aa2d6d 5. SAS Model Manager compute context d731a2dd-249b-4301-9296-31ef8364049e 6. Import 9 service compute context 695b9e48-c0cf-4be5-bd4b-be1e8d3c5cb4 7. Natural Language Conversations service compute context f23a7bc4-78b4-48a8-bfab-f6ee184edc97 8. Data Mining compute context f3ec8041-bf8b-46a0-9805-2ab9c1f50a76 9. SAS Backup job compute context e436717f-cd5c-43fe-9231-c2d805692b62 List the details of the SAS Studio Compute Context In the command prompt, run this to view details of the SAS Studio Compute Context. You can indicate which compute context you want to see by ordinal number, name or id - here I chose to identify it by name: sas-viya compute contexts show --name "SAS Studio compute context" Expected output (some lines omitted for brevity): { "createdBy": "sas.studio", "creationTimeStamp": "2023-07-13T08:18:09.70045Z", "description": "Compute context to be used by the SAS Studio service", "environment": {}, "id": "c4eeed2e-2c5e-48ee-ac69-9c82889a4081", "launchContext": { "contextName": "SAS Studio launcher context" }, "launchType": "service", "links": [ --- some lines omitted --- ], "modifiedBy": "sas.studio", "modifiedTimeStamp": "2023-07-13T08:18:09.70045Z", "name": "SAS Studio compute context", "version": 4 } If your objective was only to set up the SAS Viya CLI, and not pyviyatools, you are finished, and I hope this process has been useful.   No doubt this guide could be improved. If you see areas you think are overcomplicated, wrong or unnecessary, or if you have questions about why I chose a particular command or installation method, I would love to hear from you. Please leave a comment below or get in touch.   If you want to continue to set up pyviyatools, look no further than part 2 Install and use the pyviyatools on Windows.    My thanks to my colleagues Gerry Nelson and Allan Tham for their help in discussing and refining some of the things I included in this guide.   See you next time!   Find more articles from SAS Global Enablement and Learning here. ... View more

In this post I would like to highlight a neat way to set a useful bit of SAS Viya Programming Run-time Environment configuration from the command-line, and in the process remind you that pre-started (and reusable) compute servers are a good thing for SAS administrators to know about.   SAS Viya's Programming Run-time Environment has the ability to pre-start a pool of available compute servers. The idea is that when users request a compute session in a specific compute context in e.g. SAS Model Studio or SAS Studio, the compute session starts in a few seconds rather than a few tens of seconds because the compute session runs in a compute server that is already started. The user doesn't need to wait for the SAS Compute Service to ask SAS Launcher Service to launch a new Compute Server pod, wait for the pod to start up, and wait for all the containers in it to initialize. Those things still have to happen, but they happen before the user requests their compute session.   The apparent improvement in session start time is especially noticeable when you run something like a model pipeline which starts several compute sessions in quick succession.   The necessary steps to create a compute context which pre-starts compute servers are documented in: Configure Compute Servers to Run under a Shared Account Configure Reusable Compute Servers Configure a Pool of Available Compute Servers However, if you like to script things so that e.g. your environment creation can be automated, read on. We're going to look at a way to enable a pool of pre-started compute servers with just three commands. Plus, the method we'll use can easily be modified to create other compute contexts with attributes and restricted access.   We have covered pre-started compute servers before. 18 months ago my GEL colleague Rob Collum wrote here about improving concurrency performance in SAS Viya. One of the things he covered was how to create a pool of reusable compute servers, and he showed how to do it using the SAS Environment Manager's web interface. And 14 months ago I used the settings we'll review today as examples in my post Add, update and remove compute context attributes with new pyviyatools. But it is a while since we've written about pre-started compute servers here, so perhaps they are worth mentioning again.   First, let's refresh our memories with a few reminders about pre-started compute contexts: A compute context you configure to have pre-started available compute servers must run those compute servers under a shared service account You must store credentials for that shared service account in advance using the compute service's plugin to the sas-viya CLI If you are running a version of SAS Viya earlier than version 2023.03 (Stable or LTS), then as Rob mentioned in his post, you cannot do this if your users identities are provided to SAS Viya by SCIM, you can only do this if they are provided by LDAP. However, once you have upgraded to SAS Viya version 2023.03 (stable or LTS) or later, deployments using SCIM can now also use shared service accounts to run sessions for SAS Compute Server (and other things). Only compute servers can be pre-started, you cannot pre-start batch or connect servers Each pre-started compute server pod consumes a bit of CPU and memory on the host nodes in your Kubernetes compute node pool, even when it is idle. Not only that, even when those pods are idle and not actually using much CPU and memory, Kubernetes effectively reserves an amount of CPU and memory for their use as specified by their container's CPU and memory 'requests' values. Having pre-started compute servers may result in Kubernetes being unable to run as many - or any - new pods on the nodes where those compute servers run, if doing so would overcommit the total CPU or memory available to Kubernetes for running pods on the node beyond the total cumulative amount of CPU or memory requested by all the containers in all the pods currently running on the node. So pre-starting compute pods effectively reserves a chunk of your total compute (or other pod-running) capacity, whether it is being used or not. TL;DR: The presence of pre-started compute server pods may prevent new compute pods from being started, even when those pre-started compute pods are idle. But with all that taken into consideration, if your users need to run a model pipeline - i.e. a series of model steps - in SAS Model Manager, or start SAS programs in Studio, and much quicker session startup time is worth the tradeoff of running the compute session as a shared account, then creating a pool of pre-started available compute servers might be for you!   Here's how.   Step 1: Store a credential for a shared service account   You must store a credential for a shared service account whether your identities are provided by LDAP or SCIM. However, I have only had a chance to try it with LDAP so far, so the steps below are specific to shared service accounts provided by LDAP. Consult Stuart's post for how to do the equivalent when your identities are provided by SCIM.   If you are using password authentication, and your users are provided by an LDAP provider such as Microsoft Active Directory (AD) or Azure Active Directory Services (AADS), read on.   First, authenticate to the sas-viya CLI as an administrator using e.g. sas-viya auth logon, or the pyviyatool loginviauthinfo.py (described in loginviauthinfo.md).   Then optionally, run this to list existing compute credentials:   sas-viya compute credentials list   If you have not created any compute credentials yet, the response will be:   There are no shared service account credentials.   Then run this to save a compute credential for a service account called modelservice , who has password mySecretPassword123 . Obviously, substitute the username and password of the service account your pre-started compute servers should actually run as for these example values:   sas-viya compute credentials create -u modelservice -p mySecretPassword123 -d "Shared service account called modelservice" The expected response is something like:   2023/06/07 12:34:56 The shared service account credential for modelservice was created successfully.   If you like, confirm it was created by listing compute credentials again:   sas-viya compute credentials list   If the credential was created successfully, the response will be something like:   Shared Service Account Credentials: 1. modelservice - compute-password - Shared service account called modelservice   Step  2: Create JSON file that defines the new compute context   The file below is based on the example in SAS Viya Platform Administration > Servers and Services > Programming Run-Time Environment > Programming Run-Time Servers > SAS Compute Server and Compute Service > CLI Examples. Save it somewhere which I will refer to as /path/to/file/prestarted_reusable_modelservice_cc.json .   { "name": "Data Mining compute context as modelservice", "description": "A compute context for the SAS Visual Data Mining and Machine Learning application as modelservice.", "attributes": { "runServerAs": "modelservice", "reuseServerProcesses": "true", "serverMinAvailable": "1" }, "launchContext": { "contextName": "Data Mining launcher context" }, "launchType": "service", "authorizedGroups": [ "Modellers" ] }   Adapt the JSON compute context template to your needs:   Change /path/to/file/prestarted_reusable_modelservice_cc.json to whatever file path and file name you wish to contain your JSON compute context definition Set our preferred name and description for this new compute context Provide the name of the service account you created in place of modelservice in the runServerAs attribute Optionally, you may wish to add further attributes: One that is quite useful is "serverInactiveTimeout": "900" . From the documentation reference in the next bullet: "Is used only when the reuseServerProcesses attribute is set. The value is the time in seconds that an inactive server remains running before being terminated. An inactive server is defined as a server without an active compute session.". When idle, you will see the pre-started compute servers terminate at the end of such an inactive period - and new ones are restarted if this brings the total of compute servers in the context below the number specified by serverMinAvailable . The Server Contexts section in SAS Help Center has a list of compute server attributes Set the value of the serverMinAvailable attribute to the initial number of compute servers you wish to have pre-started. See note below. Choose the most appropriate launcher context for the value of the contextName attribute: For SAS Model Studio use, leave it set to "Data Mining launcher context" For SAS Studio use, change it to "SAS Studio launcher context" Either change the group name in the authorizedGroups section from Modellers  to the groupID of the group you want to have access to this compute context, or if you do not want to restrict access to this compute context, remove the authorizedGroups section - and the comma at the end of  "launchType": "service" - to make this compute context available to all authenticated users.   Note: Remember that pre-started compute servers will consume some resources on your Kubernetes cluster's compute nodes, and as explained above will also reserve resources for potential use, so that they cannot be used for running other pods. The optimal serverMinAvailable number for the workload your users are running is something you may need to find by trial-and-error. I have seen a use case of a small environment with a couple of users who ran relatively small model pipelines, where 4 was a good value for serverMinAvailable . I have also seen another use case of a large shared classroom server used for teaching classes of students how to design models in SAS Model Studio, where 25 was was the chosen value for serverMinAvailable . This was the use case Rob used for the example values in his post. It is a value that you should tune, over time and with experience of what works best for your organization's workload.   Save your changes to /path/to/file/prestarted_reusable_modelservice_cc.json .   Step 3: Create the new compute context with pre-started compute servers   To create the new compute context, use the sas-viya command-line interface, still authenticated as an administrator, to run this command:   sas-viya compute contexts create -r -d @/path/to/file/prestarted_reusable_modelservice_cc.json   Note: the @ symbol in front of the file path is correct and required. You can of course create - and update, and delete - a new compute context interactively in SAS Environment Manager. My aim in this post is to show how to do it from the command line.   Step 4: See if compute servers have been pre-started   If you have access to a visual interface which shows pods running in your SAS Viya namespace in your cluster, you should see the number of sas-compute pods increase. However, depending on the interface, it may be difficult to distinguish the sas-compute pods started under this compute context (and running as the modelservice account) from other compute pods.   If you have access to the kubectl command-line interface for Kubernetes and a kube config file that lets you access your SAS Viya deployment's cluster, this command can show sas-compute pods launched specifically by the SAS Compute service (as opposed to by a user in SAS Model Studio or SAS Studio), and running as the modelservice account:   kubectl get pod -l launcher.sas.com/requested-by-client=sas.compute,launcher.sas.com/username=modelservice   Tip: Scroll the textbox above to the right if necessary, to see how the username who requested the pod is specified as a filter to kubectl get pods.   Here are some example results, when my new compute context's serverMinAvailable value was set to "1" , and I had no other SAS Compute sessions running in this compute context or as modelservice :   NAME READY STATUS RESTARTS AGE sas-compute-server-b91b1b9f-8827-4b57-9535-160cbf6e2cc4-t8mgl 1/1 Running 0 25s   Possible reasons you might not see the new compute servers starting up include:   You need to wait a little longer - a minute or two is usually enough The credentials for the service account are incorrect - try deleting and re-creating it There is not currently enough available CPU or memory to start new pods on Kubernetes nodes in your compute node pool - you may see fewer compute servers starting than you requested The account you specified in the runServerAs attribute is already running the maximum number of launched SAS Programming Run-time Environment sessions allowed, as set by the SAS_LAUNCHER_USER_PROCESS_LIMIT setting. See my blog post: Limit a user’s simultaneous compute server processes in Viya 2021.1 and later for more on this.   Assuming you did see the new sas-compute server pods starting up, you can now see if they improve performance of your model pipelines.   Use the new compute context in SAS Model Studio   Sign in to SAS Model Studio. If you limited access to the new compute context to only members of a specific group,  sign in to SAS Model Studio as a user who is in that group.   Then, create or open a model pipeline. To change the compute context used to run each step of this model pipeline, click the 'Settings' icon, in the top right corner of the project tab.   In the Project Settings dialog, choose Compute Context, and switch from the default 'Data Mining compute context' to your new compute context which pre-starts compute servers:   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   I do not believe it is possible to configure individual steps in a model pipeline run under different compute contexts. The whole pipeline runs under the same compute context.   In the screenshot above, you can just about see a four-step sequential pipeline, created from a gradient boosting model in SAS Visual Analytics. When this project runs, each step runs in its own separate compute context. Some models run multiple steps at the same time. You should notice a significant improvement in the total 'wall clock' time (as compared to CPU time) when running these models while sufficient pre-started compute servers in the chosen compute context are available and not currently in use.   Use the new compute context in SAS Studio   SAS Studio users are generally familiar with switching compute contexts - click on the compute context icon top-right in SAS Studio to change to a different context:     If you select a compute context which has unused (i.e. available) pre-started compute servers, you should see a very noticeable improvement in how quickly your compute session in SAS Studio is ready to run SAS code.   The tradeoff for this is that the compute session runs as the shared service account, and not as you (or rather, as the signed-in user). This may have some impact on your filesystem permissions, if you access anything on the filesystem, such as base or other path-based libraries, filerefs etc. But the tradeoff may be worth it for the much faster compute session startup time.   So now you know how to script configuration of the compute context from the command line, and can see how easily it could be automated as part of an environment configuration script. Hopefully, that's useful to someone out there.   Thank you to Rob Collum for reviewing this post and for his great comments. Any remaining errors or omissions are mine.   See you next time!     Find more articles from SAS Global Enablement and Learning here. ... View more

I'm delighted to announce our new SAS Viya Administration Checklist is available now on GitHub:   https://github.com/sassoftware/viya4-admin-checklist   This checklist has 67 administration tasks for SAS Viya 2020.1 and later, organized into initial and regular task lists. There is a suggested frequency for the regular tasks. You, as an IT administrator or a SAS administrator, should consider performing the tasks in these lists for the SAS Viya 2020.1 and later environments that you maintain. Perform all tasks that are relevant to your environment to keep your SAS Viya deployment operating at its best over the long term.     This new checklist has been in development for a long time. The GEL Administration team and a select group of technical experts across the company have all worked on creating it, and we're so happy to make it available in this first release. But it is a living project, and we will add to it over time. If you see something you can improve, reach out to me or any of my GEL admin team colleagues, or raise a an issue in the GitHub project and let us know what you'd like to see changed, added or fixed. You can even contribute your own tasks. We have previously published similar checklists as PDF documents for earlier versions of SAS: Checklist of SAS Viya 3 Administration Tasks: https://support.sas.com/resources/papers/checklist-sas-viya-administration-tasks.pdf Checklist of SAS 9 Administration Tasks: https://support.sas.com/resources/papers/Platform-Administration-Tasks.pdf   Let me know what you think!   Acknowledgements   THANK YOU to all my SAS colleagues who contributed their suggestions and thoughts over the past several months. Not every suggestion made it into this release. We still have all the ideas that didn’t make this first cut, and will use those suggestions – and new ones – to drive future updates to the project. It will grow!   A particular thank you to my GEL Administration team colleagues: @ScottMcCauley, @GerryNelson ,  @AjmalFarzam and @GillesChrzaszcz who all wrote up tasks for this checklist. See you next time! ... View more

Someone contacted SAS Support recently asking for help with an issue in their SAS Viya platform running on Kubernetes. Support asked the customer to upload some logs from the relevant SAS Viya job to the support track. But this customer didn't have a way to get those logs. The job in question had ended, and the customer had no log (or metric) monitoring solution deployed or configured which had stored its log messages. The logs were gone.   This customer had no good way to access to their logs, except for the kubectl logs command which, in the case of transient pods like those which run compute jobs, is really only useful for pods that are still running. It's unlikely to be helpful for pods which have finished. So, basically, until this customer deploys some kind of log monitoring solution, and while they are at it a metric monitoring solution too, it will be near impossible for Support to help them troubleshoot that issue.   This is not the ideal first experience when you have just deployed the current SAS Viya platform. Please, if you are a SAS Administrator you need both a log monitoring solution and a metric monitoring solution for your SAS Viya platform.     Why do you need a log and metric monitoring solution for the SAS Viya platform?   In A first look at logging in SAS Viya 4 | Global Enablement & Learning Blog back in May 2020, I explained that the way SAS Viya [platform] log messages are collected and made available to SAS administrators is very different from the way they were handled in SAS Viya 3 or SAS 9. In correctly designed Kubernetes applications, the app should not attempt to write to or manage log files. Instead, log messages are simply written to an output stream: stdout and stderr . Kubernetes picks up this output and stores it in pod logs.   Rudimentary log viewing tools such as kubectl logs or a cloud service provider's Kubernetes web interface (which more or less offers the same functionality as kubectl logs in a web app) are good enough for simple use by e.g. a Kubernetes administrator and deployment consultants. But they don't offer long-term storage, aggregation over many pods, searching or much other functionality. In any case the SAS Administrators may not have access to them.   This means you need a log monitoring solution to capture SAS Viya log messages. The solution should store the log messages and their contextual information, and let you to chart, filter and search them.   While we're at it, you also need a metric monitoring solution, which will similarly capture and store metrics from your Kubernetes cluster and from your SAS Viya platform, store them, and let you chart, filter and explore them.   Plan to include both log and metric monitoring as part of your deployment. Add or enable both as soon as you can reasonably do so if you don't already have them! You may also want to ensure you have an alerting and at least a basic auditing capability. Collectively all these things fall under the category of observability tools.     Which log and metric monitoring tools should you use?   There are several choices. None is terribly expensive, or very difficult to deploy or use, but some are definitely better than the others.   Our top recommendation for observing SAS Viya deployments is SAS Viya Monitoring for Kubernetes. It consists of a log monitoring stack, and a metric monitoring stack, and a set of samples. It is documented in SAS Help Center, and is open source, supported by SAS, regularly updated by SAS developers and available license free on GitHub. It runs and is supported on all the Kubernetes and Cloud Service providers that SAS Viya is supported on.   If you are willing to do a bit more work or sacrifice a bit of convenience and data richness for the sake of consistency with the observability tool a customer already uses for other Kubernetes applications, all the major cloud service providers offer their own observability tools: Microsoft Azure and AKS has Azure Monitor, comprised of Azure Monitor Metrics and Azure Monitor Logs. Amazon AWS and EKS has Amazon CloudWatch, with Amazon CloudWatch Metrics and Amazon CloudWatch Logs. Google Cloud Platform and GKE has Google Operations Suite, with Cloud Logging and Cloud Monitoring. OpenShift OCP has the OpenShift Container Platform Monitoring Stack.   The SAS Viya Monitoring for Kubernetes project even has samples for how to configure each to work with SAS Viya.   If you are using Upstream Open Source Kubernetes to deploy SAS Viya (one of our newest options), you'd probably choose to create your hosting infrastructure and Kubernetes environment using SAS Viya 4 Infrastructure as Code (IaC) for Open Source Kubernetes, which works with SAS Viya 4 Deployment project on GitHub. This in turn can deploy SAS Viya Monitoring for Kubernetes with its cluster-monitoring and viya-monitoring tasks.   If you already have Kubernetes and/or already have another observability solution with log and metric monitoring support, you could use that.   Just be aware that if you choose something other than SAS Viya Monitoring for Kubernetes, some work is going to be involved to get the same richness of information from SAS Viya platform logs and metrics that is available in SAS Viya Monitoring for Kubernetes, and to keep it up-to-date over time as you update to new versions Kubernetes and the SAS Viya platform.   But please, do set up log and metric monitoring. It's essential.   Further reading Learn more by reading my first look at logging in SAS Viya 4.   To see more recent versions of SAS Viya Monitoring for Kubernetes in action, watch: SAS Demo | Viewing Logs with SAS Viya Monitoring for Kubernetes: Changing Log Levels - YouTube. ...and its supporting SAS Communities post: Code for YouTube video: "Viewing Logs with SAS Viya Monitoring for Kubernetes: Changing Log Levels SAS Demo | Viewing Logs with SAS Viya Monitoring for Kubernetes: Managing Log Retention - YouTube Look for other posts on observability, logging and monitoring (or log monitoring and metric monitoring) here, including: Four Tips for Exporting logs from OpenSearch Dashboards’ Generate CSV function Managing logging data retention period and size in SAS Viya Monitoring for Kubernetes Managing monitoring data retention period and size in SAS Viya Monitoring for Kubernetes Tips for upgrading SAS Viya Monitoring for Kubernetes 1.1.8 to version 1.2.0 Log monitoring updates in the SAS Viya Monitoring for Kubernetes project Overview of updates to the SAS Viya Monitoring for Kubernetes project Exporting logs from SAS Viya on Kubernetes – a survey of five available methods Managing access to logs for specific Viya deployments with Kibana A second look at Azure Monitor Logs for AKS clusters A first look at Azure Monitor Logs for AKS clusters   Find more articles from SAS Global Enablement and Learning here. ... View more

SAS Watchdog is an optional component for the SAS Viya platform's Programming Run-time, which architects and administrators should know about. It has been documented in the READMEs and HTML doc that come with your SAS Viya  platform deployment assets for a long time now, but in the Stable 2023.01 release of the SAS Viya platform, that doc has been improved and SAS Watchdog is covered in the Help Center documentation too.   If you enable SAS Watchdog, it helps keep customer environments secure for users who run their own open source code written in Python, R or Java from within a SAS Compute, Connect or Batch programming session.   In this post, I want to tell you what SAS Watchdog is, how it works, and why you would choose to enable it (or not). This is partly just because it's really clever, but also because SAS Watchdog is an essential tool that can keeping your customer's data safe when they run code written in other programming languages from within a SAS program.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Most importantly, sas-watchdog restricts access to the filesystem using the same allowlist that SAS's LOCKDOWN feature uses. In a future post, we'll look at how to manage both the SAS Programming Run-time allowlist that is relevant here, and also the CAS allowlist, which is a seperate list but which implements a similar concept for SAS CAS Language processing.   Why you need a way to restrict filesystem access from the SAS Programming Run-time   SAS Watchdog is needed because of the way two features of the SAS programming language need to work together: LOCKDOWN, and SAS's ability to run user-written code in other languages.     LOCKDOWN prevents unauthorized access to the filesystem from the SAS programming language   Native SAS code running in a compute, connect or batch programming session is prevented from accessing filesystem paths which should be off-limits by the LOCKDOWN feature of the SAS programming language. It also limits access to certain language features and access methods, but in this post we are more concerned with its function of limiting filesystem access. After initialization, any attempt to access the filesystem from any SAS language feature - a procedure, data step or path-based library - will be checked against an allowlist of filesystem paths by the SAS programming run-time.     If the directory or file is in or below a path in the allowlist, it is allowed. If the directory or file is not in the allowlist and access to it is attempted after the programming session enters its locked-down state, the access is prevented.   There is an exception to this: autoexec code which is managed by SAS administrators, and is processed during the compute (or connect or batch) server/process initialization can define file references and path-based library references to paths outside the allowlist. These references have to be set up during initialization, before the SAS programming session enters its locked-down state. By the time end-user-written code can begin to run, the SAS programming session has already entered a locked-down state and no new file or library references to paths outside the allowlist are allowed.     The SAS Programming Run-time supports calling other programming languages   One of the most exciting features of the SAS programming run-time is that it supports running user-written code in other languages: Python, R and Java.   @ScottMcCauley wrote two great posts recently about how to Configure Python Integration with SAS Viya. and Configuring R Integration with SAS Viya. Together, the two posts (and the documentation they link to) show how the SAS Configurator for Open Source and other steps can be used to enable SAS programs to run Python (e.g. via proc python; ), and R (e.g. via proc IML; ). SAS has also long supported running Java code via the data step Java Object.     When code in another language is executed, the compute (or connect or batch) server uses another SAS process called sasels to launch processes running the respective programming language's own run-time binaries as the user who started the SAS programming session. It passes the code to be executed (or a filepath pointing to a file containing the code) to the respective programming language's executable.   Of course, the Python, R and Java languages are all fully-featured. They also have features which allow them to access the filesystem. And obviously those language runtimes do not have the SAS programming run-time's LOCKDOWN feature. Plus, the top-level processes called when another language's code is executed are also capable of launching additional processes themselves.   So, what will prevent a user running a proc python; statement which executes Python code to read a file outside the SAS Programming Run-time's allowlist? Equally, the same goes for R and Java code.   Sure, the only file system volumes that it has access to, since it is running inside a Kubernetes pod are the paths mounted into the pod. The container runtime (Docker, containerd etc.) and Kubernetes together prevent a process from accessing the host file system, other pods, other hosts etc. But still, it is not desirable to give a launched processes running arbitrary user-written code access to all filesystem paths mounted into the pod!     SAS Watchdog   SAS Watchdog's job - if it is enabled - is to prevent user-written code in one of those languages, started inside a compute (or connect or batch) programming session from exploring the compute (or connect or batch) pod's filesystem, and from accessing files mounted to it which they have no business accessing.   Once you enable it, SAS Watchdog runs as a process inside its own separate sidecar container, in each SAS Programming Run-time pod. In Kubernetes a 'sidecar container' is an additional container in a pod (beside the main container), which stays running after a pod's init containers have finished their initialization.   However, SAS Watchdog is disabled by default.     How SAS Watchdog works     Follow the numbered annotations in the diagram above and the list below to see how SAS Watchdog works. If it is enabled, SAS Watchdog runs with elevated privileges that allow it to register itself with a LINUX kernel API called fanotify, part of the operating system running inside the pod. Once SAS Watchdog has registered itself with fanotify, any request to access the filesystem - such as a file open request - coming from any process launched by the sasels process will trigger an 'open event' notification which will be sent to SAS Watchdog. When a process launched by sasels - including any Python, R or Java processes, and also any sub-processes they spawn - requests access to the filesystem, fanotify sees that a file open request has been made by a watched process. The LINUX kernel does not grant or deny the request yet. Fanotify sends an event to the SAS Watchdog process, and waits for it to respond. The SAS Watchdog process consults the list of filesystem paths in the allowlist, and determines whether or not the requested file is in or below a path on the allowlist. If the file or directory requested is in the allowlist, SAS Watchdog responds to the open event to indicate that it allows the request. If not, it responds saying it denies the request. If SAS Watchdog allowed the request, the LINUX kernel grants the file open request and the calling process gets access to the file or directory. If SAS Watchdog denies the request, the kernel denies that request to access the file.   The allowlist that watchdog uses is the exact same one that LOCKDOWN uses. Inside the pod, it's read from the same file by both processes. So if you change the list of paths in the LOCKDOWN paths list, there is nothing else you need to do to have your change affect the SAS Watchdog process.     How can you enable SAS Watchdog   SAS Watchdog is disabled by default, but can be enabled in your SAS Viya platform deployment in the same way as so many other SAS Viya platform features, with an overlay you copy to your site-config directory, and reference from your kustomization.yaml, so that (along with many other overlays) it will be used by kustomize to modify your site.yaml file before site.yaml is applied to your Kubernetes cluster, following whichever SAS Viya platform deployment method you use at your site.   Specifically, read the instructions in:   the README file at $deploy/sas-bases/overlays/sas-programming-environment/watchdog/README.md (for Markdown format) or the web page at $deploy/sas-bases/docs/configuring_sas_compute_server_to_use_sas_watchdog.htm (for HTML format)   Using the instructions that are shipped with the deployment assets in your specific release of the SAS Viya platform ensures you have the right instructions for that specific release. But the general gist of those instructions is that you add a reference to the  sas-programming-environment/watchdog  overlay to the transformers block of the base kustomization.yaml file ( $deploy/kustomization.yaml ), like this   ... transformers: ... - sas-bases/overlays/sas-programming-environment/watchdog - sas-bases/overlays/required/transformers.yaml ...   NOTE: The reference to the  sas-programming-environment/watchdog  overlay MUST come before the required transformers.yaml, as seen in the example above.   If you are running the SAS Viya platform on an OpenShift environment, there are additional steps in the instructions for applying a Security Context Constraint that is required for SAS Watchdog to work.   Check your release's instructions, at the paths given above, to be sure you are following the right process for your release. These instructions were updated and refreshed for SAS Viya platform Stable cadence release 2023.01.   And take a look at the new documentation for SAS Watchdog in the SAS Viya Platform Administration Guide.     Why might you choose not to enable SAS Watchdog?   The SAS Watchdog process in its sidecar pod has to run with elevated privileges in order to register itself with the fanotify API. Some Kubernetes administrators, or their parent organization may not approve of this. Discuss this with your architect and customer during the architecture phase of an implementation project.   If you disable access to the JAVA Data Step Object using LOCKDOWN, and do not enable Python and R code to be run from within SAS Programming Run-time servers (SAS Compute, SAS/CONNECT and SAS Batch), there is no need to enable SAS Watchdog, and doing so would consume a little bit of system resource for no additional benefit.   Besides those two reasons, I cannot immediately think of any reason why you would not enable SAS Watchdog. But feel free to contact me or add a comment below if you can!   See you next time!   Find more articles from SAS Global Enablement and Learning here. ... View more

I love it when people ask our team questions. I love it even more when we can answer them, and a few days ago a very knowledgeable colleague asked me a really good question:   Is there a way to set a permission to none using the sas-viya CLI like you can do in the GUI?   It helps enormously if you use a couple of additional command-line tools (jq and the getruleid.py pyviyatool) in addition to the sas-viya CLI, but with their assistance, yes, you can set a permission to '(none)' using the sas-viya CLI.   This is what my colleague was asking about:   Setting a permission to none using the SAS Environment Manager GUI   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Read on to learn how to do this from the command line. It's not quite as simple as it looks!   Demo Preparation   To set up a folder to work with, I used to an instance of the SAS Viya environment that we provide for students attending our team's GEL SAS Viya: Administration workshops. These workshops have a set of fictitious users who are in groups, and who work for a fictitious company called GELCorp. There is a Managers group ready made with a couple of users in it. We have a ready-made folder structure in these environments, including a Viya folder called /gelcontent/GELCorp.   To prepare, I ran some sas-viya CLI statements to create a 'Managers' Viya folder under /gelcontent/GELCorp, and to grant the Managers groups some read-write permissions on that folder (targeted by --object-uri ) and on its contents (targeted by --container-uri) :   # Create a Managers folder in /gelcontent/GELCorp /opt/sas/viya/home/bin/sas-viya --output text folders create --parent-path /gelcontent/GELCorp --name Managers #Get /gelcontent/GELCorp/Managers folder id, store in $folderid folderid=$(/opt/sas/viya/home/bin/sas-viya --output json folders show --path "/gelcontent/GELCorp/Managers" | jq -r '.["id"]') echo "The Managers folder ID is" $folderid # Grant Managers group: +RUARe,+RUDARe& echo "Granting Managers +RUARe,+RUDARe& on /gelcontent/GELCorp/Managers" /opt/sas/viya/home/bin/sas-viya authorization grant --object-uri /folders/folders/$folderid/** --group Managers --permissions read,update,add,remove /opt/sas/viya/home/bin/sas-viya authorization grant --container-uri /folders/folders/$folderid --group Managers --permissions read,update,delete,add,remove   Here's the command line output from that series of commands:   [cloud-user@hostname ~]$ # Create a Managers folder in /gelcontent/GELCorp [cloud-user@hostname ~]$ /opt/sas/viya/home/bin/sas-viya --output text folders create --parent-path /gelcontent/GELCorp --name Managers Id 84a65308-b77f-4844-814c-02fcc51221ba Name Managers Description Type folder MemberCount 0 ParentFolderUri /folders/folders/ce8f1f43-3af4-4cc9-a360-922534670eec The folder was created successfully. [cloud-user@hostname ~]$ [cloud-user@hostname ~]$ #Get /gelcontent/GELCorp/Managers folder id, store in $folderid [cloud-user@hostname ~]$ folderid=$(/opt/sas/viya/home/bin/sas-viya --output json folders show --path "/gelcontent/GELCorp/Managers" | jq -r '.["id"]') [cloud-user@hostname ~]$ echo "The Managers folder ID is" $folderid The Managers folder ID is 84a65308-b77f-4844-814c-02fcc51221ba [cloud-user@hostname ~]$ [cloud-user@hostname ~]$ # Grant Managers group: +RUARe,+RUDARe& [cloud-user@hostname ~]$ echo "Granting Managers +RUARe,+RUDARe& on /gelcontent/GELCorp/Managers" Granting Managers +RUARe,+RUDARe& on /gelcontent/GELCorp/Managers [cloud-user@hostname ~]$ /opt/sas/viya/home/bin/sas-viya authorization grant --object-uri /folders/folders/$folderid/** --group Managers --permissions read,update,add,remove { "acceptItemType": "", "acceptType": "", "contentType": "", "createdBy": "geladm", "creationTimestamp": "2022-12-15T16:35:38.835Z", "description": "", "enabled": true, "id": "9f585603-f29b-445a-8e19-1aba538fae8b", "mediaType": "", "modifiedBy": "geladm", "modifiedTimestamp": "2022-12-15T16:35:38.835Z", "objectUri": "/folders/folders/84a65308-b77f-4844-814c-02fcc51221ba/**", "permissions": [ "remove", "read", "update", "add" ], "principal": "Managers", "principalType": "group", "reason": "", "type": "grant", "version": 10 } The authorization rule has been created. [cloud-user@hostname ~]$ /opt/sas/viya/home/bin/sas-viya authorization grant --container-uri /folders/folders/$folderid --group Managers --permissions read,update,delete,add,remove { "acceptItemType": "", "acceptType": "", "containerUri": "/folders/folders/84a65308-b77f-4844-814c-02fcc51221ba", "contentType": "", "createdBy": "geladm", "creationTimestamp": "2022-12-15T16:36:23.113Z", "description": "", "enabled": true, "id": "c626a6de-60dd-4798-a928-a2568f5de466", "mediaType": "", "modifiedBy": "geladm", "modifiedTimestamp": "2022-12-15T16:36:23.113Z", "objectUri": "", "permissions": [ "remove", "read", "delete", "update", "add" ], "principal": "Managers", "principalType": "group", "reason": "", "type": "grant", "version": 10 } The authorization rule has been created. [cloud-user@hostname ~]$   In SAS Environment Manager, in the Content page, the Managers group's permissions on the new folder (right-click > View Authorization) look like this:     Initial permissions set on the new Managers folder   Note that among other permissions, I have granted the Managers group 'Update' permission on the Managers folder itself.     Set a permission to none using the sas-viya CLI   Let's suppose a few days have passed, and I notice that Managers (such as the user 'Helena') in our workshop environment have permission to rename the Managers folder!   Helena can rename the Managers folder!   Oops! That was not my intention.   Helena can rename the Managers folder because I 'accidentally' granted Managers (a group she belongs to) the Update permission on the folder (she already had Update permission on its parent folder, /gelcontent/GELCorp).   I want to remove that grant - in other words, to set the permission to '(none)'. It's easy to do in the SAS Environment Manager GUI's Edit Authorization dialog, but how can we do it using the sas-viya CLI? There isn't exactly a sas-viya CLI syntax that will set a permission to '(none)'.   What we need to do is update the rule that grants the read, update, add and remove permissions on the Managers folder to members of the Managers group, so that it only grants read, add and remove permissions - and not update any more.   We can do this with the sas-viya authorization update-rule command. But the catch is that it requires a rule ID, which I don't know. The commands that created the new general authorization rules that represent the permissions I granted did not include the rule IDs in their output, and in any case, let's assume some time passed since I created it and I wouldn't remember them even if the rule IDs were output at the time. And short of looking up the rule in SAS Environment Manager, which defeats the purpose of using the sas-viya CLI, we need a way to find the rule ID using CLI commands.   I spent a while trying to do this using the sas-viya CLI, with the sas-viya authorization list-rules command and jq. I think it should be possible. However, after a while, I remembered I wrote a getruleid.py pyviyatool for just this sort of purpose! My colleague @GerryNelson  wrote a blog post explaining how to install and use the pyviyatools in 2018, but it's still correct and relevant, and there are more useful tools in the set now too!   That made it much easier, as getruleid.py only requires a folder ID and a identity principal (a user or a group), and returns all the details of the rule - including its id - in JSON, CSV or a simple multiline name-value format.   So, the following code will do the trick - first, it uses the sas-viya CLI and jq to get the folder ID. Next, it uses getruleid.py and awk to get the rule ID. Finally, it uses the sas-viya authorization update-rule command to change the permissions that the rule grants, reducing them from 'read,update,add,remove' to just 'read,add,remove', which effectively sets the 'update' permission to '(none)'.   #Get /gelcontent/GELCorp/Managers folder id, store in $folderid folderid=$(/opt/sas/viya/home/bin/sas-viya --output json folders show --path "/gelcontent/GELCorp/Managers" | jq -r '.["id"]') echo "The Managers folder ID is" $folderid # Get the id of the rule targeting that folder for Managers, and parse the output a bit to keep just the rule ID ruleid=`/opt/pyviyatools/getruleid.py -u /folders/folders/$folderid/** -p "Managers" -o simple | grep "id = " | awk '{print $3}'` echo "The rule ID is" $ruleid # Reduce the permissions that Managers have on the folder, keeping just 'Read', 'Add' and 'Remove', which effectively removes the unwanted 'Update' permission: /opt/sas/viya/home/bin/sas-viya authorization update-rule --id $ruleid --grant --group "Managers" --permissions read,remove,add   Here's the command line output from that series of commands:   [cloud-user@hostname ~]$ #Get /gelcontent/GELCorp/Managers folder id, store in $folderid [cloud-user@hostname ~]$ folderid=$(/opt/sas/viya/home/bin/sas-viya --output json folders show --path "/gelcontent/GELCorp/Managers" | jq -r '.["id"]') [cloud-user@hostname ~]$ echo "The Managers folder ID is" $folderid The Managers folder ID is 84a65308-b77f-4844-814c-02fcc51221ba [cloud-user@hostname ~]$ [cloud-user@hostname ~]$ # Get the id of the rule targeting that folder for Managers, and parse the output a bit to keep just the rule ID [cloud-user@hostname ~]$ ruleid=`/opt/pyviyatools/getruleid.py -u /folders/folders/$folderid/** -p "Managers" -o simple | grep "id = " | awk '{print $3}'` [cloud-user@hostname ~]$ echo "The rule ID is" $ruleid The rule ID is 9f585603-f29b-445a-8e19-1aba538fae8b [cloud-user@hostname ~]$ [cloud-user@hostname ~]$ # Reduce the permissions that Managers have on the folder, keeping just 'Read', 'Add' and 'Remove', which effectively removes the unwanted 'Update' permission: [cloud-user@hostname ~]$ /opt/sas/viya/home/bin/sas-viya authorization update-rule --id $ruleid --grant --group "Managers" --permissions read,remove,add { "acceptItemType": "", "acceptType": "", "contentType": "", "description": "", "enabled": true, "id": "9f585603-f29b-445a-8e19-1aba538fae8b", "mediaType": "", "modifiedBy": "geladm", "modifiedTimestamp": "2022-12-15T17:19:16.495Z", "objectUri": "/folders/folders/84a65308-b77f-4844-814c-02fcc51221ba/**", "permissions": [ "remove", "read", "add" ], "principal": "Managers", "principalType": "group", "reason": "", "type": "grant", "version": 10 } The rule has been modified. [cloud-user@hostname ~]$   If you look at the command output closely (and scroll down), you can see that this rule now only grants the smaller set of permissions we asked for. Here are how the Managers group's permissions on the Managers folder look after this correction:      Corrected Managers folder permissions   The Managers group no longer has the 'Update' permission granted directly on the Managers folder. Since nothing else grants Managers this permission, the effective permission decision for the 'Update' permission for 'Managers' on the Managers folder is 'denied'. In the absence of an grant, permissions in the SAS Viya general authorization system are denied by default.   As a result, the Helena can no longer rename the Managers folder:    Helena can no longer rename Managers folder   Job done. My thanks to my colleaque Bruno Muller for asking a really good question, with a not-so-straightforward answer. And I hope you will find this useful in your projects!   See you next time!   ... View more

In release 1.2.0 of SAS Viya Monitoring for Kubernetes in June 2022, we got a great new way to export SAS Viya log messages to a file, the Reporting > Generate CSV function in OpenSearch Dashboards:   Reporting > Generate CSV menu button   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   At the risk of sounding like click-bait, with four simple tips it's easy to export the SAS Viya log messages you're interested in. You can include just the fields of contextual information you want, and your exported messages can span multiple services over multiple days. These tips will help you work around a bit of quirky behavior, and get the most out of this excellent new(-ish) feature.   As a brief aside while on the topic of exporting logs from SAS Viya, I last wrote about it in this post in April 2021. A couple of things have evolved about the methods I surveyed back then:   Mirantis Lens is still great, but now requires you to create an account and sign in before you can use it. A near equivalent project called OpenLens does not require you to have an account or sign in. You either have to download and trust their unsigned binary installation files, or you have to clone the source code and build/make it yourself. But we like it because in our workshops, not having the attendees need to create an account and sign in removes a little bit of friction. The experimental getlogs.sh script in the SAS Viya Monitoring for Kubernetes project has not received much maintenance in the past year or so, and as a result some key features, like searching and filtering, no longer seem to work. When I last tried using the getlogs.sh script with search or filtering parameters in release 1.2.6, it returned no results when I think it should have done. It always was a little quirky, and was always clearly categorized as EXPERIMENTAL, so I doubt this effects many users. Given the range of good alternatives available and competing development priorities for the team who maintain it, I don't expect to see the getlogs.sh utility become production ready any time soon. You should plan to use something else for the short to medium term.   Four Tips for using the Generate CSV function   Now, on to the main subject of this post: the Reporting > Generate CSV function in OpenSearch Dashboards' Discover page. This will export log messages as seen in the table below the chart on the discover page.   You need to know four things to get best results:   The Time column in the table is not exported. I don't know why not, but its omission from CSV exports appears to be a deliberate choice by the developers. You should add the @timestamp column to the table if you want a timestamp in your CSV export - and why wouldn't you? You likely prefer to move the @timestamp column to the left of the CSV results. But the Time column (which is not exported) is fixed as the first column on the left side of the table. So, you will likely prefer to move the @timestamp column left as far as it will go, which will be the second column on the left side of the table, one to the right of the Time column. OpenSearch generates the CSV results based on the filter and search criteria, and the table columns in a saved search, not based on what you currently see on screen. This can be unintuitive. Changes you make to the Discover page will have no effect on the content of the exported CSV unless you first save them as a saved search. Tip: you should not overwrite the 'Log Messages' saved search. It is provided with your SAS Viya Monitoring for Kubernetes logging stack during its deployment. This saved search is used in a number of dashboards, and changing it (e.g. by adding a filter or search) will impact dashboards based on it. Because dashboards display charts, the effect of changes to the 'Log Messages' saved search may not be immediately obvious. Leave 'Log Messages' alone and save your search and filter criteria as a new saved search before exporting log data to a CSV with the Reporting > Generate CSV function. If you are unable to generate a CSV as the logadm user, generate one as the admin user, just once. Afterwards, the logadm user should be able to generate CSVs.   Let's see why each of these things matters.     Tip 1: Time column not exported; add @timestamp column   Here's a simple saved search I created by opening the Log Messages saved search, adding a filter for 'logsource = cas', and saving it as a new saved search named 'Log Messages - CAS':    On the Discover page of OpenSearch Dashboards, the leftmost column of the table of log documents is always Time   When I choose Reporting > Generate CSV, the resulting CSV data does not include the Time column, and have not found any option that you can change to include it:   The Time column is not included in a generated CSV based on the same saved search   The solution is to add the @timestamp column to the table in your saved search...   Add @timestamp column to the table   ...then remember to save it and lastly export the CSV again:   Now the CSV has a timestamp column… wherever it was in the table. Here it is the right-most column, which looks a bit strange.   Tip 2: Move @timestamp column as far left as it can go, to the second column from the left It's nice to have the @timestamp column first in the CSV. To achieve this, click the little double left chevrons ('«') in the column heading for the @timstamp column - they appear when you hover your mouse pointer over them:    Left double chevrons (‘«’) in the @timestamp column heading. Click to move column to the left.   Keep doing this until the @timestamp column is as far to the left as it will go. This is the second-left most column. The 'Time' column which is not exported in the CSV, is always the left-most column:   The timestamp column moved to the left as far as it will go   Remember again to save your changes to your saved search, and choose Reporting > Generate CSV again. The @timestamp column will now be at the left of the CSV:   CSV with @timestamp column on the left Tip 3: Save the filter and query state of the Discover page as a Saved Search before Generating a CSV   In the tips above, I reminded you to save your changes (but don't overwrite the out-of-the-box Log Messages saved search) before exporting a CSV. There are two reasons for this.   First, if you just open the Discover page in OpenSearch Dashboards, without opening or saving your view as a saved search, you will see that the Reporting > Generate CSV function is disabled:    No saved search is open in the Discover page. The Reporting > Generate CSV option is disabled.   Second, after you change any of the filters, search string, columns, sort order or anything else about the Discover page, if you do not then save your changes to update your saved search, and choose Reporting > Generate a CSV, the CSV will reflect the filters, search string, columns, sort order etc. as they were when you last saved them to the saved search object, and will NOT reflect your changes.   If you try to generate a CSV without saving recent changes, there is no prompt asking if you want to save your changes. This is not great UI design, but it's not too difficult to get into the habit of first saving, and then generating a CSV.     Tip 4: Generate a CSV as the admin user first before trying to do it as the logadm user   Some initialization happens behind the scenes in OpenSearch the first time you generate a CSV this way.   SAS Viya Monitoring for Kubernetes configures a 'non administrator' user in OpenSearch called logadm, which you can use when you don't need full administrator privileges, to reduce the risk of you making an accidental configuration change.   It seems that in SAS Viya Monitoring for Kubernetes prior to version 1.2.7  the admin user has all the permissions it requires to complete the initialization steps for generating a CSV, while the logadm user does not.   So, if you first try to generate a CSV in a new deployment of the SAS Viya Monitoring for Kubernetes logging stack as logadm, it fails like this:   Generating a CSV as the logadm user first fails. Generate one as admin first.   The error message says "Error generating report", "Insufficient permissions. Reach out to your OpenSearch Dashboards Administrator".   The solution is to sign in as the admin user, and generate a CSV from any saved search.  This should succeed, and without you seeing any evidence of it the initialization steps are performed successfully. Then sign out and sign in again as the logadm user. Now generating CSVs as logadm should succeed too.     I hope these tips have been helpful. Please let me know in the comments below if you have any more tips for generating CSVs, or for any other feature in SAS Viya Monitoring for Kubernetes' logging stack (OpenSearch and OpenSearch Dashboards).     See you next time!   Find more articles from SAS Global Enablement and Learning here. ... View more