I've reached out to the documentation team to make this more clear. ... View more

You mentioned you created an NFS volume accessible to all nodes, did you mount that into the pods that would be using it? The README.md in $deploy/sas-bases/examples/data-access discussing setting these variables (the recommendation being to use an options set statement rather than setting in them in sas-access.properties), as well as mounting the Hadoop files into your pods (i.e. using data-mounts-*.sample.yaml files in the same path). ... View more

From the perspective of a user I think what you'd need to provide to the administrator is what path(s) your SAS sessions need to be able to access. The administrator should be able to modify the deployment to make those paths available. I would agree that if you want to process larger file(s), uploading it as part of the batch execution process would not be the best path forward. More general information about container volumes in Kubernetes can be found here: https://kubernetes.io/docs/concepts/storage/volumes/ Basically, the sas-programming-environment image that is used to run the compute/batch/connect servers contains SAS and not much else, so as part of the deployment process you make adjustments to add in network paths, data access drivers, and additional languages (E.g. python, R) as needed for your use case. In the deployment assets, information and examples specifically on adding volumes to the CAS and compute pods can be found in: $deploy/sas-bases/examples/sas-compute-server-configure/README.md $deploy/sas-bases/examples/cas/configure/README.md The relevant transformers being comptue-server-add-nfs-mount.yaml and cas-server-add-nfs-mount.yaml in those same paths, respectively. ... View more

Hi Tom, Yes, in the Viya Platform the SAS session is running inside of a container so it's file system is controlled. The batch plugin to the sas-viya CLI lets you pass your program and optionally other files that will be staged inside the batch server, and retrieve the results either by waiting for the job to complete or by requesting them later. The batch plugin can also be used to run SAS interactively in line mode, and to run commands from within the cluster rather than SAS. If the code you are submitting is referencing a path as a data source and you aren't uploading that file as part of the submission, that path would need to be mounted into the container so the SAS session has access to it. This would be true for compute servers like those used by SAS Studio, SAS/CONNECT servers, and batch servers used by the batch CLI. The supplied example transformer $deploy/sas-bases/examples/sas-compute-server/compute-server-add-nfs-mount.yaml and its associated README.md provide an example for mounting an NFS server share into the pods that run SAS code. This could be modified to use a different volume type like a PersistentVolume, or to target a subset of the SAS podtemplates used by the various servers (e.g. only mount this into batch servers and not compute and connect servers). ... View more

This is a function of the browser rather than SAS, the browser tabs are sharing the same authentication to Viya. You'd need to check your browser options to see if there is any way to have it treat the tabs separately, I'm not aware of any way to do so. ... View more

@Kurt_Bremser using encrypted caslibs and whole disk encryption. Here is the documentation on Data at Rest encryption on the SAS Viya Platform: https://go.documentation.sas.com/doc/en/sasadmincdc/v_068/calencryptrest/titlepage.htm ... View more

@Kurt_Bremser Not for base SAS tables directly as far as I'm aware, though you can still password protect and encrypt them programmatically. CAS tables can be encrypted with a key stored in an encryption domain, and protected with permissions. ... View more

In the SAS Viya Platform, Base SAS libraries are made available to compute and CAS by way of volume mounts. For example your data might be on an NFS volume nfs.example.com:/sas-data which is mounted to /sas-data inside the CAS and compute pods. For CAS libraries, permissions can be set on the CASLIB, but if you are mounting directly onto the compute pods, access would be governed based on file system permissions, which are based on the execution user's POSIX attributes (uid, gid, secondary gids). The POSIX attributes are either provided to Viya (from LDAP or through bulk-loading), or Viya can generate them. So to limit access to certain data files you would need to set permissions on those paths in the volume you are mounting, based on the user and group identifiers in Viya. ... View more

Are you checking this on the caspassive host where the failure occurs? On the caspassive host are you able to successfully run the command the playbook is attempting to run? (mkdir /tmp/.root.ansible) ... View more

I think this is a question of security posture. In this example were you to use local system you are allowing local system to delegate to specific services, so this would apply to any service running as local system and not just the object spawner. If you wanted to limit this delegation permission only to the object spawner, you'd need to use a service account. ... View more