sassoftware / sas-container-recipes

A collection of recipes and other resources for building containers that include SAS Viya software.

SAS^® Viya^® Container Recipes -- Archived Repository

SAS has archived the SAS Viya 3.5 for containers repository in the sassoftware organization on GitHub. No further changes or issues will be allowed in this repository. We recommend exploring the new cloud-ready version of SAS Viya for future deployments.

---

A framework to build SAS Viya Docker images and create deployments using Kubernetes.

Container deployments are more lightweight and don't have as much overhead as traditional virtual machines. By running a SAS engine inside a container, you can provision resources more efficiently to address a wide variety of SAS workloads. Select a base SAS recipe and create custom containers that include access to different data sources (PC files, Oracle, Hadoop, etc.), the addition of a Jupyter Notebook with Python 3, and more.

For more information, see SAS for Containers.

Quick Start

Use the following instructions to quickly build and launch SAS Viya containers. For extensive information about building and running SAS Viya containers, see the documentation wiki. For single and multiple containers, addons found in the addons directory can enhance the base SAS Viya images with SAS/ACCESS software, LDAP configuration, and more. For information about how to use the addons and any prerequisites, see the documentation about addons.

1. Locate your SAS Viya for Linux Software Order Email (SOE), and retrieve the SAS_Viya_deployment_data.zip file from it. Not sure if your organization purchased SAS Software? Contact Us or get SAS License Assistance. If you have not purchased SAS Software but would like to give it a try, please check out our Free Software Trials.

2. Download the latest or git clone [email protected]:sassoftware/sas-container-recipes.git

3. Choose your flavor and follow the recipe to build, test, and deploy your container(s).

   a. If you are looking for an environment tailored towards individual data scientists and developers, you will be interested in a SAS programming-only deployment running on a single container.

   b. If you would like an environment suitable for collaborative data science work, then you may be interested in a SAS programming-only deployment or a SAS Viya full deployment on multiple containers.

---

For a Single User - SAS Viya Programming-Only Deployment Running on a Single Container

Use these instructions to create a SAS Viya programming-only deployment in a single container for an independent data scientist or developer to execute SAS code. All code and data should be stored in a persistent location outside the container. This deployment includes SAS Studio, SAS Workspace Server, and a CAS server, which provides in-memory analytics for symmetric multi-processing (SMP).

Prerequisites

• Strongly recommended: Create a local mirror repository of the SAS software. Here's why.
• A supported version of Docker-CE (Community Edition) is required.

Build the Image

Run the following command to build the container image and add a default user ID (sasdemo) and password (sasdemo), which can be used to sign in to SAS Studio after the container is running. A non-root user is recommended for executing the build command.

 ./build.sh --type single --zip ~/path/to/SAS_Viya_deployment_data.zip --addons "auth-demo"

Run the Container

After the container image is built, the instructions for running the container will be printed at the end of the build.sh output.

mkdir -p run
cp samples/viya-single-container/example_launchsas.sh run/launchsas.sh
cd run
sed -i 's|@REPLACE_ME_WITH_TAG@|19.05.0-20190509195121-d991185|' launchsas.sh
./launchsas.sh

Use the docker images command to see the images that were built and the most recent tag (example: tag 19.05.0-20190509195121-d991185).

After the launchsas.sh command is completed, use docker ps to list the running container.

Sign In to SAS Studio

Go to http://<myhostname>:8080, and then sign in with the sasdemo user ID and the sasdemo password to start using SAS Studio!

For more information, see the documentation wiki.

---

For One or More Users - SAS Viya Programming-Only or SAS Viya Full Deployment Running on Multiple Containers

Use these instructions to build multiple Docker images and then use the images to create a SAS Viya programming-only or a SAS Viya full deployment in Kubernetes. These deployments can have SMP or massively parallel processing (MPP) CAS servers, which provide in-memory analytics and can be used by one or more users.

A programming-only deployment supports data scientists and programmers who use SAS Studio or direct programming interfaces such as Python or REST APIs. Note that a programming-only deployment does not include SAS Drive, SAS Environment Manager, and the complete suite of services that are included with a full deployment. Make sure that you provide your users with the features that they require.

Prerequisites

• A supported version of Docker-CE (Community Edition) must be installed on the Linux or Mac build machine.
• Access to a Docker registry: The build process will push built Docker images automatically to the Docker registry. Before you run build.sh, run docker login docker.registry.company.com, and then make sure that the values in $HOME/.docker/config.json are correct.
• Access to a Kubernetes environment and kubectl installed (required for the deployment step but not required for the build step).
• Strongly recommended: Create a local mirror repository of the SAS software. Here's why.

Note: Users of Kubernetes clusters running v1.16.0+ should use the "kubernetes-1.16.0-compat" branch.

How to Build

Examples of running build.sh to build multiple containers are provided below. A non-root user is recommended for executing the build command.

Tip: For the list of all required and optional arguments, see the docs/usage.txt file, or run ./build.sh --help .

Example One: Programming-Only Deployment, Multiple Containers

  ./build.sh \
  --type multiple \
  --zip /path/to/SAS_Viya_deployment_data.zip \
  --docker-registry-namespace myuniquename \
  --docker-registry-url myregistry.myhost.com \
  --addons "auth-demo"

Here's a summary of what this command does:

• Multiple Docker images for a programming-only deployment are created: --type multiple.
• The software that is deployed is determined by the software entitlement that is provided in the ZIP file from the Software Order Email: --zip /path/to/SAS_Viya_deployment_data.zip .
• The images are pushed to the namespace in the Docker Registry, which is located at the Docker registry URL: --docker-registry-namespace myuniquename, --docker-registry-url myregistry.myhost.com.
• A default user ID (sasdemo) and password (sasdemo) are added, which can be used to sign in to SAS Studio: --addons "auth-demo".

Example Two: Full Deployment, Multiple Containers (Experimental)

Considerations for a Full Deployment

• This deployment is experimental and includes limited support from SAS.
• A SAS Viya multi-tenant environment is not supported.
• High availability is not currently supported for full and multiple deployments using Kubernetes.
• Persistence is not currently functional when scaling. Scaling down to 0 and back up from 0 will result in the loss of data.

  ./build.sh \
  --type full \
  --zip /path/to/SAS_Viya_deployment_data.zip \
  --docker-registry-namespace myuniquename \
  --docker-registry-url myregistry.myhost.com \
  --addons "auth-sssd"

Here's a summary of what this command does:

• Multiple Docker images for a full deployment are created: --type full.
• The software that is deployed is determined by the software entitlement that is provided in the ZIP file from the Software Order Email: --zip /path/to/SAS_Viya_deployment_data.zip.
• The images are pushed to the namespace in the Docker Registry, which is located at the Docker registry URL: --docker-registry-namespace myuniquename, --docker-registry-url myregistry.myhost.com.
• SSSD is configured inside the container to allow the container authentication to connect to LDAP or Active Directory: --addons "auth-sssd".

Note: Before you use the auth-sssd addon, see the documentation wiki for prerequisite information.

Running Multiple Containers

The build process creates Kubernetes manifests that you use to run multiple containers.

• For a SAS Viya programming-only deployment, the manifests are located at builds/multiple/manifests/.
• For a SAS Viya full deployment, the manifests are located at builds/full/manifests/.

For information about using the manifests, see Build and Run SAS Viya Multiple Containers.

Sign In to SAS Studio

After the containers are running, users can sign on to SAS Studio.

• If you deployed a programming-only environment, then your environment contains SAS Studio 4.4.
• If you deployed a full environment, then your environment contains both SAS Studio 4.4 and SAS Studio 5.1. By default, you will sign in to SAS Studio 5.1.

Here are some examples of how to sign in:

• For SAS Studio 4.4 via Kubernetes:

  https://ingress-path/SASStudio

• For SAS Studio 5.1:

  https://ingress-path/SASStudioV

---

Additional Resources

• Wiki: documentation
• Issues: Questions and Project Improvements
• Kubernetes Documentation
• Docker Documentation
• SAS License Assistance
• SAS Software Purchase
• SAS Software Trial

---

Copyright

Copyright 2018 SAS Institute Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

    https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

sas-container-recipes's Issues

doshell and dostatus

Hi @hornpolish,
I've noticed that doshell and dostatus have a minor typo.

They both reference allinone_sasawb_1 instead of all-in-one_sasawb_1

panic: runtime error: index out of range

Hi guys,

sas support sent me here and asked if I could submit a new issue.

Building a --type single image and running it works fine.
When trying to build a --type multiple or --type full, I always get the following error:

2019/10/22 09:42:05 httpproxy:
Step 19/19 : LABEL sas.recipe="true" sas.recipe.version="19.06.1" sas.recipe.image="httpproxy" sas.layer.httpproxy="true"
2019/10/22 09:42:05 httpproxy:
---> Using cache
2019/10/22 09:42:05 httpproxy:
---> c066fd352551
2019/10/22 09:42:05 httpproxy:
---> c066fd352551
2019/10/22 09:42:05 httpproxy:
[Warning] One or more build-args [BASE SAS_RPM_REPO_URL] were not consumed
2019/10/22 09:42:05 httpproxy:
Successfully built c066fd352551
2019/10/22 09:42:05 httpproxy:
Successfully tagged anaxima/sas-viya-httpproxy:19.06.1-20191022094035-57c3c36
2019/10/22 09:42:05 index.docker.io/anaxima/sas-viya-httpproxy:19.06.1-20191022094035-57c3c36
panic: runtime error: index out of range

goroutine 73 [running]:
main.buildWorker(0x1, 0xc00030c0c0, 0xc000024360, 0xc000024420, 0xc000024300)
/sas-container-recipes/order.go:695 +0x8f4
created by main.(*SoftwareOrder).Build
/sas-container-recipes/order.go:843 +0x3a1
exit status 2
sas-container-recipes-builder-19.06.1-20191022094035-57c3c36

Not sure, what information to add... sas support told me, he would link this newly created issue to the internal support ticket.

I tried this with CentOS 7.5 in a VirtualBox on my laptop, with CentOS 7.6 in Azure and with RHEL 7.5 in Azure.

I added the following to line 679 in file order.go:

progress <- container.GetWholeImageName()

Output was

2019/10/22 09:42:05 index.docker.io/anaxima/sas-viya-httpproxy:19.06.1-20191022094035-57c3c36

The image is there, yet not pushed to the docker registry.
A simple

docker push anaxima/sas-viya-httpproxy

works fine

Tried this with docker hub (--docker-registry-url https://index.docker.io/v1/, also tried index.docker.io and https://index.docker.io) as well as a local registry running in a container.

I'm no go expert so debugging is kinda hard for me... besides, I don't really have a clue what I should check.

This is my build last command:

./build.sh --type multiple --zip ../SAS_Viya_deployment_data.zip --mirror-url http://chrismaschine/mirror --docker-registry-url https://index.docker.io/v1/ --docker-namespace anaxima --addons "auth-demo" --workers 1 --skip-docker-registry-push --verbose 2>&1 | tee /tmp/2019_10_22_11_40_build_httpd.log

Tried it with yum repo mirrored by SimpleHTTPServer as well as httpd with disabled selinux.
Tried it without mirror leading to a overflowing sas download counter, because - how sas support explained it - every image being build increments the counter... hence the mirror.

Any thoughts?

Thanks!

Chris

Issue with SAS Viya Full deployment

Based on information provided in the link below:
https://github.com/sassoftware/sas-container-recipes/wiki/Build-and-Run-SAS-Viya-Multiple-Containers

We are attempting to perform a SAS containerized full deployment using a RHEL 7.8 base image. When running the build script (using the command below), it gives an error.

Build command

./build.sh --type full --base-image --base-tag latest --zip ../SAS_Viya_deployment_data.zip --docker-registry-url --docker-namespace sas --addons "auth-sssd access-odbc"

Errors

unable to sync file '/var/lib/dpkg/tmp.ci//control': Input/output error
dpkg: error processing archive /tmp/apt-dpkg-install-qLupvE/68-python3-selinux_2.8-1+b1_amd64.deb (--unpack):
unable to sync file '/var/lib/dpkg/tmp.ci//md5sums': Input/output error
dpkg: error processing archive /tmp/apt-dpkg-install-qLupvE/69-python3-xmltodict_0.11.0-2_all.deb (--unpack):
unable to sync file '/var/lib/dpkg/tmp.ci//control': Input/output error
dpkg: error processing archive /tmp/apt-dpkg-install-qLupvE/70-python3-winrm_0.3.0-2_all.deb (--unpack):
unable to sync file '/var/lib/dpkg/tmp.ci//control': Input/output error
dpkg: error: unable to sync new file '/var/lib/dpkg/status-new': Input/output error
E: Sub-process /usr/bin/dpkg returned an error code (2)

Although we have specified a RHEL image as an argument in the command line to run the build script, it appears to be pulling debian packages. Please advise.

Password is listed in configuration file.

sas-container-recipes/addons/auth-sssd/sssd.conf

Line 44 in b6a75ea

ldap_default_authtok = LD@Pid

There is what appears to be a legit password in this example file that was not removed.

regexNoSpecialCharacters in order.go does not like a hyphen "-" altough doc says is allowed

When running the sas-container-recipes, I get this message :
The --docker-namespace argument contains invalid characters. It must contain contain only A-Z, a-z, 0-9, _, ., or -
And my namespace is : sas-sbxwvw.
So either the regexNoSpecialCharacters function in order.go is not correct, or the message should be changed to not allow a "-" (hyphen)

I'm not an regexp specialist but according to https://regex101.com/ this function :
^[_A-z0-9]([_A-z0-9\-\.])$
does not allow sas-sbxwvw, whereas this function :
^[_A-z0-9]([_A-z0-9-.])$
seems to allow sas-sbxwvw

No more hosts left - error while doing fresh single auth-demo build

Describe the bug
On a fresh first time install with auth-demo as addon I run into the No more hosts left error. What does it mean? Cannot seem to get past it. Snippet from the logs, right at the end:

} Status: Image is up to date for centos:7 }

[container.go:403] &{NO MORE HOSTS LEFT ************************************************************* Status: Image is up to date for centos:7 }

[container.go:403] &{PLAY RECAP *********************************************************************
deployTarget : ok=123 changed=29 unreachable=0 failed=1
localhost : ok=12 changed=1 unreachable=0 failed=0 Status: Image is up to date for centos:7 }

[container.go:403] &{Removing intermediate container bd34b9eba0dc Status: Image is up to date for centos:7 }
builds/single-2019-06-20-20-32-39/sas-viya-single-programming-only/log.txt

To Reproduce
./build.sh --type single --zip ~/path/to/SAS_Viya_deployment_data.zip --addons "auth-demo"

Expected behavior
Basic build should proceed

Environment (please complete the applicable information):
Client:
Version: 18.09.6
API version: 1.39
Go version: go1.10.8
Git commit: 481bc77156
Built: Sat May 4 02:34:58 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:02:43 2019
OS/Arch: linux/amd64
Experimental: false

getting error with build the container

useradd: UID 0 is not unique

[centos@cent01 sas-container-recipes]$ sudo ./build.sh --type single --zip /home/centos/SAS_Viya_deployment_data.zip --mirror-url "http://cent01.fedtst.sashq-d.openstack.sas.com/sas_repos" --addons "auth-demo"

Building Docker Build Container

Sending build context to Docker daemon 39.56MB
Step 1/20 : FROM golang:1.14.0
---> 25c4671a1478
Step 2/20 : ARG USER_UID=1000
---> Using cache
---> 197becc58963
Step 3/20 : ARG DOCKER_GID=997
---> Using cache
---> 53a104c66f70
Step 4/20 : RUN apt-get update && apt-get install -y openjdk-11-jdk-headless ansible && rm -rf /var/lib/apt/lists/*
---> Using cache
---> 31233e08406c
Step 5/20 : RUN go get -x -u gopkg.in/yaml.v2 github.com/docker/docker/api/types github.com/docker/docker/client
---> Using cache
---> 26be5e0ad7a2
Step 6/20 : RUN groupadd --gid ${DOCKER_GID} docker
---> Using cache
---> 66cdc165782e
Step 7/20 : RUN useradd --uid ${USER_UID} --gid ${DOCKER_GID} --create-home --shell /bin/bash sas
---> Running in 6b75dc5daffd
useradd: UID 0 is not unique
The command '/bin/sh -c useradd --uid ${USER_UID} --gid ${DOCKER_GID} --create-home --shell /bin/bash sas' returned a non-zero code: 4

Jupyter Notebook kernels fail when running in Azure Container Instance

Describe the bug
I was able to build a local Docker image, and run SASStudio fine, and was able to run SAS and Python kernels in Jupyter Notebook locally. I then deployed this image to Azure (a hefty 25GB), and SAS Studio works fine so far, but neither SAS nor Python Kernel can connect. I attach the screenshot of the error. Are there some settings that need to change to be able to use Jupyter in Azure hosted Docker image?

To Reproduce
Use the default auth and jupyter support addons, upload 25GB Docker image to Azure Container Registry and launch a Docker instance.

Expected behavior
Jupyter should work just like it does locally, but it fails to connect

Screenshots
Screenshot of Jupyter kernel error:

Environment (please complete the applicable information):
[azablocki@localhost sas-container-recipes-master]$ docker version
Client:
Version: 18.09.6
API version: 1.39
Go version: go1.10.8
Git commit: 481bc77156
Built: Sat May 4 02:34:58 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:02:43 2019
OS/Arch: linux/amd64
Experimental: false

Additional context
Reading other issues I execed into the image and this is the information in my local /etc/httpd/conf.d/jpy3_proxy.conf . It is exactly the same in the Azure image, when I exec into that.

<Location /Jupyter>
ProxyPass http://localhost:8888/Jupyter
ProxyPassReverse http://localhost:8888/Jupyter
RequestHeader set Origin "http://localhost:8888"

<Location /Jupyter/api/kernels>
ProxyPass ws://localhost:8888/Jupyter/api/kernels
ProxyPassReverse ws://localhost:8888/Jupyter/api/kernels

<Location /Jupyter/terminals/>
ProxyPass ws://localhost:8888/Jupyter/terminals
ProxyPassReverse ws://localhost:8888/Jupyter/terminals

Thank you

Ansible version check failed

sas-container-recipes-master.zip
Describe the bug
On a fresh auth-demo and python install, we run into a completely new error in Centos 7,
[container.go:391] &{fatal: [localhost]: FAILED! => {
"changed": false,
"failed": true,
"failed_when_result": true,
"msg": "At least one third-party assessment check failed: The Ansible version check failed. Deployment requires Ansible, version 2.5 or later. SAS recommends version 2.7 or earlier."
}

To Reproduce
On Centos 7, with latest updates run auth-demo and python addon using the zip I attached.

Expected behavior
Build should complete.

Not sure how to mitigate this. Please let me know if you need any more system information.

invalid group ID 'docker' when building on Docker for Windows

I am trying to build sas-viya image using Docker on Windows 10.
Build step started from GIT bash
$ ./build.sh --zip ../SAS_Viya_deployment_data.zip --addons "addons/auth-sssd" --type single

ends with groupadd: invalid group ID 'docker'
----end of log----
rm -r $WORK/b132/
Removing intermediate container d6e3bd563cec
---> 84c21dc8dc75
Step 6/19 : RUN groupadd --gid ${DOCKER_GID} docker
---> Running in 2145b18bd300
groupadd: invalid group ID 'docker'
The command '/bin/sh -c groupadd --gid ${DOCKER_GID} docker' returned a non-zero code: 3
----end of log----

Any idea? Any experience with sasviya image on Windows docker ?
Regards
Jaroslav Pulpan

Unable to do docker build inside addons

Describe the bug
I am trying to add the python jupyter support to the base image. I am not sure how to do that using the build.sh script, so I chose to follow the Advanced Build documentation and get the following error:

[azablocki@localhost ide-jupyter-python3]$ docker build --file Dockerfile --build-arg BASEIMAGE=19.04.0-20190516160342-no-git-sha . --tag svc-ide-jupyter-python3
Sending build context to Docker daemon 20.99kB
Step 1/15 : ARG BASEIMAGE=viya-single-container
Step 2/15 : ARG BASETAG=latest
Step 3/15 : FROM $BASEIMAGE:$BASETAG
pull access denied for 19.04.0-20190516160342-no-git-sha, repository does not exist or may require 'docker login'

To Reproduce
Steps to reproduce the behavior:

1. Build the auth-demo image as per the quick instructions - I used:
   ./build.sh --type single --zip ~/path/to/SAS_Viya_deployment_data.zip --addons "auth-demo"
2. Test the build by logging into SAS Studio with sasdemo user, all works
3. Descend into the addons directory and the addon you wish to add to the base-image, or any other previously built image with
   cd addons/ide-jupyter-python3
4. Run the following command:

docker build --file Dockerfile --build-arg BASEIMAGE=19.04.0-20190516160342-no-git-sha . --tag svc-ide-jupyter-python3

, assuming that BASEIMAGE is the tag that refers to the image just built using step1.

Use docker images to list the images and the tags, to see

REPOSITORY TAG IMAGE ID CREATED SIZE
fbd4d0f5c5db 16 minutes ago 23.4GB
sas-container-recipes-builder 19.04.0-20190521150511-no-git-sha 78065ff771ea 19 minutes ago 1.21GB
sas-viya-single-programming-only 19.04.0-20190516160342-no-git-sha c00fcda85064 4 days ago 23.4GB
sas-container-recipes-builder 19.04.0-20190516160342-no-git-sha 64fe23fad2b0 4 days ago 1.21GB
centos 7 9f38484d220f 2 months ago 202MB
golang 1.12.0 cee68f119e19 2 months ago 772MB
hello-world latest fce289e99eb9 4 months ago 1.84kB

Questions:

1. What is wrong with my docker build tag syntax? Step 1/15 suggests it is ignoring my tag completely as it says ( 1/15 : ARG BASEIMAGE=viya-single-container) instead of ARG BASEIMAGE=19.04.0-20190516160342-no-git-sha

2. There are two Dockerfiles (Dockerfile and Dockerfile_http) in the addons directory for jupyter, does this mean I have to run the build twice, and if is in what order?

3. Is there a way to do this using the build.sh script? All the examples I see either do "auth-demo" or at the same time do "auth-demo auth-sssd ide-jupyter-python3", but what if now I wanted to add access-hadoop or any other addon to ide-jupyter-python3? What is the correct way to use build.sh to extend the previously built image? I am assuming that if I pass "auth-demo ide-jupyter-python3 access-hadoop" this will REBUILD the auth-demo and the jupyter addons that I already have? Is that a correct assumption? Or is the build.sh clever enough to know that there are images that already have "auth-demo auth-sssd ide-jupyter-python3"?
   Thank you.

Expected behavior
The build proceeds as in the simple example and returns docker run instructions

Environment (please complete the applicable information):
[azablocki@localhost sas-container-recipes-master]$ docker version
Client:
Version: 18.09.6
API version: 1.39
Go version: go1.10.8
Git commit: 481bc77156
Built: Sat May 4 02:34:58 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:02:43 2019
OS/Arch: linux/amd64
Experimental: false

test issue for Jon

Lets see if this gets thru

[ERROR] : Could not create base image (n_docker_build_rc=2)

Got error "[ERROR] : Could not create base image" when try to create sas viya docker single container

This is command I used :

./build.sh --zip ~/viya/SAS_Viya_deployment_data.zip addons/auth-demo addons/ide-jupyter-python3

I used most current docker:

/home/kchaksuvej/sas-container-recipes
[kchaksuvej@ermas-erm logs]$ docker version
Client:
Version: 18.09.4
API version: 1.39
Go version: go1.10.8
Git commit: d14af54266
Built: Wed Mar 27 18:34:51 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.4
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: d14af54
Built: Wed Mar 27 18:04:46 2019
OS/Arch: linux/amd64
Experimental: false

This is error:

PLAY RECAP *********************************************************************
deployTarget : ok=50 changed=6 unreachable=0 failed=1
localhost : ok=10 changed=0 unreachable=0 failed=0

The command '/bin/sh -c set -e; pushd sas_viya_playbook ; echo; echo "####### Run the playbook"; echo; ansible-playbook -i inventory_local.ini site.yml -e '@vars_usermods.yml' -vvv ; echo; echo "####### Stop the running services"; echo; /etc/init.d/sas-viya-all-services stop; popd; echo; echo "####### Reset host variables to localhost"; echo; sed -i 's|^options cashost="." casport|options cashost="localhost" casport|' /opt/sas/viya/config/etc/batchserver/default/autoexec_deployment.sas; sed -i 's|^env.CAS_VIRTUAL_HOST = '.'|env.CAS_VIRTUAL_HOST = 'localhost'|' /opt/sas/viya/config/etc/cas/default/casconfig_deployment.lua; sed -i 's|^SASCONTROLLERHOST=.|SASCONTROLLERHOST=localhost|' /opt/sas/viya/config/etc/sysconfig/cas/default/sas-cas-deployment; sed -i 's|^SAS_CURRENT_HOST=.|SAS_CURRENT_HOST=localhost|' /opt/sas/viya/config/etc/sysconfig/cas/default/sas-cas-deployment; sed -i 's|^options cashost="." casport|options cashost="localhost" casport|' /opt/sas/viya/config/etc/workspaceserver/default/autoexec_deployment.sas; if [ "$PLATFORM" = "redhat" ] ; then sed -i 's|http://.:|http://localhost:|' /etc/httpd/conf.d/proxy.conf; echo "ServerName localhost" >> /etc/httpd/conf/httpd.conf; elif [ "$PLATFORM" = "suse" ]; then sed -i 's|http://.:|http://localhost:|' /etc/apache2/conf.d/proxy.conf; echo "ServerName localhost" >> /etc/apache2/httpd.conf; fi; echo; echo "####### Remove permstore"; echo; rm --verbose --recursive --force /opt/sas/viya/config/etc/cas/default/permstore/; echo; echo "####### Remove created logs"; echo; rm --verbose --recursive --force /opt/sas/viya/config/var/log/all-services/default/; rm --verbose --recursive --force /opt/sas/viya/config/var/log/cas/default/; rm --verbose --recursive --force /opt/sas/viya/config/var/log/sasstudio/default/; rm --verbose --recursive --force /opt/sas/viya/config/var/log/spawner/default/; echo; if [ "$PLATFORM" = "redhat" ] || [ "$PLATFORM" = "suse" ]; then echo; echo "####### Remove Text Analytic languages; we will add them back in their own layer"; echo; for txtmin in $(rpm -qa | grep sas-txtmin); do if [[ "${txtmin}" != "sas-txtmineng"* ]] && [[ "${txtmin}" != "yum" ]]; then echo "####### Uninstalling ${txtmin}"; rpm --verbose -e ${txtmin}; fi; done; fi; if [ "$PLATFORM" = "redhat" ] ; then echo; echo "####### Remove some of the bigger packages that have bloated the layer"; echo; for bigpackage in "sas-mapsgfka1" "sas-mapsgfkb1" "sas-nvidiacuda1" "sas-nvidiacuda" "sas-mapsvahdat" "sas-reportvahdat"; do if rpm -q --quiet ${bigpackage}; then yum erase --assumeyes ${bigpackage}; fi; done; echo; echo "####### Remove the repos"; echo; yum erase --assumeyes "sas-meta-repo*"; if [ -e "/etc/yum.repos.d/sas.repo" ]; then rm --verbose /etc/yum.repos.d/sas.repo; fi; echo; echo "####### Clean up yum"; echo; yum clean all; rm --verbose --recursive --force /root/.cache /var/cache/yum; elif [ "$PLATFORM" = "suse" ]; then echo; echo "####### Remove some of the bigger packages that have bloated the layer"; echo; for bigpackage in "sas-mapsgfka1" "sas-mapsgfkb1" "sas-nvidiacuda1" "sas-nvidiacuda" "sas-mapsvahdat" "sas-reportvahdat"; do if rpm -q --quiet ${bigpackage}; then zypper remove -y ${bigpackage}; fi; done; mkdir -p /opt/sas/viya/config/var/log/spawner/default ; chown sas:sas /opt/sas/viya/config/var/log/spawner/default; echo; echo "####### Clean up zypper"; echo; zypper clean --all; rm --verbose --recursive --force /etc/zypp/repos.d/sas-reposuse.repo; rm --verbose --recursive --force /var/cache/zypp; fi; echo; echo "####### Remove the entitlement certificate"; echo; rm --verbose --recursive --force /etc/pki/sas; echo; echo "####### Remove the content in the WORKDIR"; echo; rm --verbose --recursive --force sas-orchestration sas-orchestration-linux.tgz;' returned a non-zero code: 2

• n_docker_build_rc=2
• set +x

[ERROR] : Could not create base image

Any suggestions.

Thanks

environment manager not showing the cas worker nodes

environment manager not showing the cas worker nodes on the dashboard. any limitation, as environment manager does not identify pods as worked nodes? also in the node section role of cas worker is blank.

Proxy issue with ide-jupyter-python3 addon

There's probably something missing with the documentation for the "ide-jupyter-python3" addon. A plain "docker build" (as the readme suggests) will not copy the httpd proxy.conf into the new container, which means that Jupyter can't be reached from the outside.

I see that there's a Dockerfile_http which does just that. It's probably meant to be run as a separate step before or after the main build? However it seems to make assumptions concerning the internal hostname so it didn't work for me.

I used this as a simple workaround for the issue:

echo "COPY proxy.conf /etc/httpd/conf.d/jpy3_proxy.conf" >> Dockerfile

(followed by the usual docker build command).

Kubernete Pods are evicted

Hi,

I have followed the instructions to built multi-container visual analytics on CentOS and I deployed it into Azure Kubernetes Service (AKS). The cluster only consist of 1 worker node, with 32 core and 256G RAM.

After the deployment, the administrativeservices pod status shows error after it ran for a while, and the rest of the Pods' status start to show error too. Eventually all Pods were Evicted.

curl#18 - "transfer closed with XXXXXXX bytes remaining to read

Hello everyone,

after several kind of issues, some thankfully supported by Younes / @frayos , some I could resolve myself, I am hitting a new issue. I hope you can give me a hand with it.

First of all, the error is not very clear. When I trace back the previous issues in the log, I can find several messages of the kind:
"http://172.22.168.128:180/sas_repos/repos/shipped/dmdq/125/dmdq-125-x64_redhat_linux_6-yum/Packages/s/sas-qkb-ci-31.1.5-20190523.1558632690288.x86_64.rpm: [Errno 14] curl#18 - \"transfer closed with 290822683 bytes remaining to read\""

Several messsages in the logs tell me the local mirror is reachable. Just to be sure, I added the following to the Dockerfile:
# 20210314 Test connection to local mirror and get IP RUN set -e; \ echo; echo "####### 20210314 Test connection to local mirror and get IP"; echo; \ echo $(hostname -a); \ echo $(hostname -A); \ echo $(hostname -d); \ echo $(hostname -i); \ echo $(nc -zv 172.22.168.128 180); \ curl --remote-name http://172.22.168.128:180/sas_repos/repos/shipped/dmdq/125/dmdq-125-x64_redhat_linux_6-yum/Packages/s ; \ curl http://172.22.168.128:180/sas_repos/repos/shipped/dmdq/125/dmdq-125-x64_redhat_linux_6-yum/Packages/s ; \ echo; echo "####### 20210314 END Test connection to local mirror and get IP"; echo;

The results are satisfactory from the container itself.

Just as a reminder, I am executing the following command:
./build.sh --type single --zip ../SAS_Viya_deployment_data.zip --addons "auth-demo" -m http://172.22.168.128:180/sas_repos -u localhost:5000 -i localhost:5000/va-125-x64_redhat_linux_7-docker/sas-viya-programming -t 3.5.9-20201210.1607626389474 --tag v1 -p redhat --verbose --debug

Any ideas?

Attaching the log file. I hope it helps.

log.txt

Thank you in advance!
Best regards,
Juan

Ansible is not being installed for Centos:7 based microservice images

I am running a full build and it stops with:

2020/05/03 14:27:29 casservices:19.06.1-20200503142552-c96ed66 container build [ERROR] casservices: map[code:127 message:The command '/bin/sh -c ansible-playbook -vv /ansible/playbook.yml --extra-vars layer=ansible --extra-vars PLAYBOOK_SRV=${PLAYBOOK_SRV} --extra-vars container_name=casservices' returned a non-zero code: 127]

Debugging: builds/full-2020-05-03-14-26-09/sas-viya-casservices/log.txt

If I check the log it says:

[container.go:403] &{Step 1/21 : FROM centos:7  <nil>}
...
[container.go:403] &{Step 7/21 : RUN if [ "$PLATFORM" = "redhat" ]; then         yum install --assumeyes ansible;               rm -rf /root/.cache /var/cache/yum;             echo -e "minrate=1" >> /etc/yum.conf;           echo -e "timeout=300" >> /etc/yum.conf;     elif [ "$PLATFORM" = "suse" ]; then         zypper install --no-confirm ansible curl && rm -rf /var/cache/zypp;     else            echo -e "Platform $PLATFORM not supported";             exit 1;     fi  <nil>}
[container.go:403] &{  <nil>}
[container.go:403] &{---> Using cache  <nil>}
[container.go:403] &{---> 8225643878b4  <nil>}
...
[container.go:403] &{ESC[91m/bin/sh: ansible-playbook: command not found

Having a look at the container, it seems the ansible is not installed.

As a workaround, I added
yum install --assumeyes epel-release;\
before
yum install --assumeyes ansible; \
in container.go.

After that, the build went on.

Recent updates to recipes break the build on Centos 7

Describe the bug
Doing auth-demo build on current sas-container-recipes zip (Downloading, not cloned) does not work. Older versions work as they used to.

Error No2: Unknown Platform, encountered when using SAS repos for the build
Snippet of the logs:
2019/06/11 16:29:36 Finished pulling base container image 'centos:7'

2019/06/11 16:29:36 Skipping adding file to single-programming-only Docker context: addons/auth-demo/Dockerfile
2019/06/11 16:29:36 Skipping adding file to single-programming-only Docker context: addons/auth-demo/addon_config.yml
2019/06/11 16:29:36 Starting 1 build process ... (this may take several minutes)
2019/06/11 16:29:36 [TIP] System resource utilization can be seen by using the docker stats command.
2019/06/11 16:29:36 Starting Docker build: sas-viya-single-programming-only:19.05.0-20190611112921-no-git-sha ...
2019/06/11 16:33:16 single-programming-only: container build [ERROR] single-programming-only: map[code:6 message:The command '/bin/sh -c set -e; if [ "$PLATFORM" = "redhat" ]; then rpm --rebuilddb; curl --silent --output ${TINI_RPM_NAME} --location ${TINI_URL}/${TINI_RPM_NAME}; yum install --assumeyes ${TINI_RPM_NAME}; rm --verbose ${TINI_RPM_NAME}; yum clean all; rm --verbose --recursive --force /root/.cache /var/cache/yum; elif [ "$PLATFORM" = "suse" ]; then zypper install -y curl ; curl --silent --output ${TINI_RPM_NAME} --location ${TINI_URL}/${TINI_RPM_NAME}; rpm -i ${TINI_RPM_NAME}; rm --verbose ${TINI_RPM_NAME}; zypper clean ; rm --verbose --recursive --force /var/cache/zypp; else echo; echo "####### [ERROR] : Unknown platform of "$PLATFORM" passed in"; echo; exit 1; fi' returned a non-zero code: 6]

Error No.1: Unknown error here - encountered when trying to use our mirror-url (it's possible the mirror url is not setup correctly - we did see a TLS warning on our mirror url)

2019/06/11 16:10:51 [TIP] System resource utilization can be seen by using the docker stats command.
2019/06/11 16:10:51 Starting Docker build: sas-viya-single-programming-only:19.05.0-20190611111036-no-git-sha ...
2019/06/11 16:15:33 single-programming-only: container build [ERROR] single-programming-only: map[code:1 message:The command '/bin/sh -c set -e; echo; echo "####### Run the Ansible playbook to create the main layer"; echo; if [ "$PLATFORM" = "redhat" ]; then rpm --rebuilddb; echo; echo "####### Add the packages to support running the Ansible playbook"; echo; yum install --assumeyes https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm ; yum install --assumeyes python-setuptools python-devel openssl-devel; yum install --assumeyes python-pip gcc wget tree automake python-six; pip install --upgrade pip setuptools; pip install ansible==${ANSIBLE_VERSION}; yum install --assumeyes python iproute openssh-clients initscripts sudo; elif [ "$PLATFORM" = "suse" ]; then zypper --non-interactive install -y python-setuptools python-pyOpenSSL python-devel; zypper --non-interactive install -y openssh sudo; easy_install pip; zypper remove -y python-cryptography ; pip install ansible==${ANSIBLE_VERSION}; fi;' returned a non-zero code: 1]

Debugging: builds/single-2019-06-11-16-10-40/sas-viya-single-programming-only/log.txt
exit status 1

To Reproduce
Run a build with today's (06/11/19) recipes folder. I have older zips on a different machine and I tried those and auth-demo built in just over an hour.

Expected behavior
The build should proceed for about an hour, but instead fails after just few minutes.

Environment (please complete the applicable information):
uname -r
3.10.0-957.12.2.el7.x86_64
docker --version
Docker version 18.09.6, build 481bc77156

Ingress on Google Cloud Platform

Describe the bug
Google Cloud Platform deployment.
By Default sas-viya-httpproxy service is created with detault type ClusterIP. But Ingress configuration doesn't support this type.
NodePort service type is supported by Ingress. However with this type hostname sas-viya-httpproxy-0 host name is not resolved across containers.

To Reproduce
Steps to reproduce the behavior:

1. Deploy Ingress configuration to Google Cloud Platform
   kubectl -n sas-viya apply -f viya-visuals/working/manifests/kubernetes/ingress
2. Go to Google Cloud Platform -> Kubernetes Engine -> Services
3. Select Ingress service type
4. See error

Expected behavior
Successful Ingress service type registration or any workarond for Google Cloud Platform

Environment (please complete the applicable information):

• OS: Windows
• Browser Chrome
• Version v19m03

Additional context
Add any other context about the problem here.

error while running build.sh

Describe the bug
I am running the build.sh using "viyadep" user after following all the instructions but getting this below error... I have proxy setup and can connect to internet. "docker run hello-world" works fine too.....

Err:47 http://cdn-fastly.deb.debian.org/debian stretch/main amd64 openjdk-8-jre-headless amd64 8u212-b01-1~deb9u1
Hash Sum mismatch
Hashes of expected file:

• SHA256:a02bdc083f33baa713e54e32639033692862c9a83a13d32c70510e59d9af2696
• MD5Sum:8b9b4d47ca34be2d76ee3aa8bef65b61 [weak]
• Filesize:27257306 [weak]
  Hashes of received file:
• SHA256:c39fb79f2df85c5e02f1695205bb379b79dbf0e3b37495eb5595dfafb8980ca2
• MD5Sum:4950594160ace27b4fa1edeba0a52f43 [weak]
• Filesize:32 [weak]
  Last modification reported: Tue, 19 Mar 2019 18:48:05 +0000
  Get:48 http://cdn-fastly.deb.debian.org/debian stretch/main amd64 ca-certificates-java all 20170929deb9u3 [15.1 kB]
  Get:47 http://security-cdn.debian.org/debian-security stretch/updates/main amd64 openjdk-8-jre-headless amd64 8u212-b01-1deb9u1 [27.3 MB]
  Get:49 http://cdn-fastly.deb.debian.org/debian stretch/main amd64 openjdk-8-jdk-headless amd64 8u212-b01-1deb9u1 [8247 kB]
  Get:49 http://cdn-fastly.deb.debian.org/debian stretch/main amd64 openjdk-8-jdk-headless amd64 8u212-b01-1deb9u1 [8247 kB]
  Err:47 http://security-cdn.debian.org/debian-security stretch/updates/main amd64 openjdk-8-jre-headless amd64 8u212-b01-1deb9u1
  Connection failed
  Err:49 http://cdn-fastly.deb.debian.org/debian stretch/main amd64 openjdk-8-jdk-headless amd64 8u212-b01-1deb9u1
  Connection failed
  Get:50 http://cdn-fastly.deb.debian.org/debian stretch/main amd64 python-kerberos amd64 1.1.5-2+b2 [22.5 kB]
  Get:51 http://cdn-fastly.deb.debian.org/debian stretch/main amd64 python-selinux amd64 2.6-3+b3 [171 kB]
  Get:52 http://cdn-fastly.deb.debian.org/debian stretch/main amd64 python-xmltodict all 0.10.2-1 [11.8 kB]
  Err:49 http://security-cdn.debian.org/debian-security stretch/updates/main amd64 openjdk-8-jdk-headless amd64 8u212-b01-1~deb9u1
  Connection failed
  Fetched 11.3 MB in 5min 45s (32.8 kB/s)
  E: Failed to fetch http://security-cdn.debian.org/debian-security/pool/updates/main/o/openjdk-8/openjdk-8-jre-headless_8u212-b01-1~deb9u1_amd64.deb Connection failed
  E: Failed to fetch http://security-cdn.debian.org/debian-security/pool/updates/main/o/openjdk-8/openjdk-8-jdk-headless_8u212-b01-1~deb9u1_amd64.deb Connection failed
  E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
  The command '/bin/sh -c apt-get update && apt-get install -y openjdk-8-jdk-headless ansible && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 100

To Reproduce
Steps to reproduce the behavior:

1. Run something with the following arguments and flags 'viyadep@server1$ ./build.sh --type single --zip ./SAS_Viya_deployment_data.zip --addons "auth-demo"'

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the applicable information):

• OS: rhel 7.4
• docker :

Client:
Version: 18.09.5
API version: 1.39
Go version: go1.10.8
Git commit: e8ff056
Built: Thu Apr 11 04:43:34 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.5
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: e8ff056
Built: Thu Apr 11 04:13:40 2019
OS/Arch: linux/amd64
Experimental: false

Additional context
Anything to do with apt-get permission as I am running the build.sh using non-root user?

ingress manifest remove static namespace entry

The generated ingress manifest contains a reference to the static namespace (verse other manifest don't give command flexibility) requiring the user to manually modify vs using the command option (-n or --namespace) to dynamically change based on K8S cluster namespace.

Recommend removing that property inside the generated file so the recommended output commands work:
kubectl -n jakoch apply -f builds/full/manifests/kubernetes/ingress/sas-viya.yml &&
kubectl -n sas-viya apply -f builds/full/manifests/kubernetes/configmaps &&
kubectl -n sas-viya apply -f builds/full/manifests/kubernetes/secrets &&
kubectl -n sas-viya apply -f builds/full/manifests/kubernetes/services &&
kubectl -n sas-viya apply -f builds/full/manifests/kubernetes/deployments

If you don't remove that option and want to change namespace on command, it fails:
kubectl -n jakoch apply -f ingress/sas-viya.yml --namespace=ssa-viya
error: the namespace from the provided object "sas-viya" does not match the namespace "ssa-viya". You must pass '--namespace=sas-viya' to perform this operation.

Unable to write and view data in container directories

Describe the bug
I am trying to setup data persistence and sharing between the VM hosting my docker image and the working directories of the docker image. In the docker image, I am unable to write to /data, /cas, and /sasinside. I am able to write to cas/permstore and cas/data, but not cas/cache. I am unable to do this in SAS Studio for a very simple .sas script.

Where should we save SAS user programs when using SAS Viya docker images, and how do we make that available in the VM running the docker image? Maybe the UID and GID need to be changed in the Dockerfile to achieve this?

In addition, I want to be able to save and view my Jupyter Notebooks, which get saved in the docker image under /home/sasdemo/jupyter. Although I can successfully setup the share between docker image /home and the VM (using --volume ${PWD}/home:/home), to view the files in the VM, I have to use sudo, otherwise I get permission denied.

To Reproduce
Use this launch script:

SAS_CONTAINER_NAME=sas-viya-single-programming-only
IMAGE=$SAS_CONTAINER_NAME:@REPLACE_ME_WITH_TAG@
SAS_HTTP_PORT=8080
SAS_HTTPS_PORT=8443

mkdir -p ${PWD}/sasinside
mkdir -p ${PWD}/sasdemo
mkdir -p ${PWD}/cas/data
mkdir -p ${PWD}/cas/cache
mkdir -p ${PWD}/cas/permstore
mkdir -p ${PWD}/home

run_args="
--name=$SAS_CONTAINER_NAME
--rm
--hostname $SAS_CONTAINER_NAME
--env RUN_MODE=developer
--env CASENV_ADMIN_USER=sasdemo
--env CASENV_CAS_VIRTUAL_HOST=$(hostname -f)
--env CASENV_CAS_VIRTUAL_PORT=${SAS_HTTPS_PORT}
--env CASENV_CASDATADIR=/cas/data
--env CASENV_CASPERMSTORE=/cas/permstore
--publish-all
--publish 5570:5570
--publish ${SAS_HTTP_PORT}:80
--publish ${SAS_HTTPS_PORT}:443
--volume ${PWD}/sasinside:/sasinside
--volume ${PWD}/sasdemo:/data
--volume ${PWD}/home:/home
--volume ${PWD}/cas/data:/cas/data
--volume ${PWD}/cas/cache:/cas/cache
--volume ${PWD}/cas/permstore:/cas/permstore"

docker run --detach ${run_args} $IMAGE "$@"

Expected behavior
I should be able to ls ~/sas-container-recipes/run/home/sasdemo and see

authinfo.txt - file
jupyter - folder
sasuser.viya - folder

Cannot do this as my user, I have to do su, log in and then I can see the data and cd into sasdemo/jupyter, otherwise I get permission denied.

Environment (please complete the applicable information):
[azablocki@localhost sas-container-recipes-master]$ docker version
Client:
Version: 18.09.6
API version: 1.39
Go version: go1.10.8
Git commit: 481bc77156
Built: Sat May 4 02:34:58 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:02:43 2019
OS/Arch: linux/amd64
Experimental: false

Additional context
if I do ls -ld in /run I get
drwxrwxr-x. 6 azablocki azablocki 161

in home I get
drwxrwxr-x. 3 azablocki azablocki 21

and if I do ls sasdemo/ -ld I get
drwx------. 9 1004 1001 238

Thank you

Darwin has no getent

Describe the bug
build.sh fails when run on darwin

To Reproduce

./build.sh --type single
--zip ~/proj/SOE/SAS_Viya_deployment_data.zip
--docker-url docker.sas.com
--docker-namespace kent
--addons addons/auth-demo

./build.sh: line 277: getent: command not found

Expected behavior
build builds

Environment (please complete the applicable information):

• OS: Mojave 10.14.4
• Version [e.g. v19m04]

Additional context
dscl . -read /users/$USER | grep PrimaryGroupID |awk -F: '{print $2}'
is what you want for Darwin

viya vault and pgpool service were down in a fresh deployment to GKE

Hi Team ,

We have built and deployed SAS Viya Full on GKE. when we checked the status , we see vault and pgpool were down and there are no logs for vault under /var/log/sas/viya.
It is the same situation on pgpool pod.

Can you please help.

bash-4.2$ /etc/init.d/sas-viya-all-services status
Getting service info from consul...
Service Status Host Port PID
sas-viya-consul-default up N/A N/A 537
sas-viya-vault-default down N/A N/A N/A
sas-viya-alert-track-default up 10.32.0.35 0 767
sas-viya-ops-agent-default up 10.32.0.35 0 53704
sas-viya-watch-log-default up 10.32.0.35 0 1107
sas-viya-backup-agent-default up 10.32.0.35 35973 1050

Also , there were some extra characters at the file /opt/sas/viya/home/lib/envesntl/sas-init-functions which is causing error while checking the status of serivces.

Please help

Cannot find inventory.ini section with container names

Running the recipe process with any order will result in the following error:

Cannot find inventory.ini section with all container names
exit status 1

This is due to a change in the way that the SAS Orchestration CLI lists container names in the generated playbook's inventory.ini file.

Error: Could not create base image

Tried a single machine image build, and got the following error. Checked the .log, no help.

[cloud-user@viya-container sas-container-recipes]$ sudo ./build.sh --type single --zip /home/cloud-user/SAS_Viya_deployment_data.zip --addons "addons/auth-demo"

mkdir: created directory ‘/home/cloud-user/sas-container-recipes/logs’
‘/home/cloud-user/sas-container-recipes/build_sas_container.log’ -> ‘/home/cloud-user/sas-container-recipes/logs/build_sas_container_20181212122140.log’

==============
Variable check

Deployment Type = single
BASEIMAGE = centos
BASETAG = latest
Mirror URL =
Validate Mirror URL = true
Platform = redhat
Deployment Data Zip = /home/cloud-user/SAS_Viya_deployment_data.zip
Addons = addons/auth-demo
Docker registry URL =
Docker registry namespace =
Validate Docker registry URL = true
HTTP Ingress endpoint =
Tag SAS will apply = 18.11.0-20181212122140-e5ee16e

[INFO] : Bypassing validation of mirror URL:

[INFO] : Copying /home/cloud-user/SAS_Viya_deployment_data.zip to viya-programming/viya-single-container
‘/home/cloud-user/SAS_Viya_deployment_data.zip’ -> ‘viya-programming/viya-single-container/SAS_Viya_deployment_data.zip’

/home/cloud-user/sas-container-recipes/viya-programming/viya-single-container /home/cloud-user/sas-container-recipes

[INFO] : Building the base image

• docker build --file Dockerfile --label sas.recipe.version=18.11.0 --label sas.layer.viya-single-container=true --build-arg BASEIMAGE=centos --build-arg BASETAG=latest --build-arg PLATFORM=redhat . --tag viya-single-container
  Sending build context to Docker daemon 83.97 kB
  Step 1/25 : ARG BASEIMAGE=centos
  Please provide a source image with from prior to commit
• n_docker_build_rc=1
• set +x

[ERROR] : Could not create base image

build.sh hangs when docker user has large uid

Describe the bug
build.sh hangs when docker user has large uid.

To Reproduce
Steps to reproduce the behavior:
sudo useradd biguiduser -u 1952219375 -g sas

sudo usermod -aG Docker biguiduser

sudo su – biguiduser

Then execute the build with this user and see if hangs…

./build.sh --type single --zip /SAS_Viya_deployment_data.zip --addons "auth-demo"

Expected behavior
The container should be build successfully but it hangs on steps 7 of 20

Step 7/20 : RUN useradd --uid ${USER_UID} --gid ${DOCKER_GID} --create-home --shell /bin/bash sas
---> Running in b9068a5a7ebb

Environment (please complete the applicable information):

• OS: CentOs
• Browser NA
• Version Viya 3.5

**Resolution:

Modify the following to sas-container-recipes/Dockerfile with -l in useradd command.

RUN useradd -l --uid ${USER_UID}
--gid ${DOCKER_GID}
--create-home
--shell /bin/bash
sas

Additional context
Add any other context about the problem here.

Unclear instruction on mirror repository

As a first time Viya user, it is unclear to me how and where I can get mirror repository URL as described in the README doc here.

This is a roadblock to me. I'd expect some more technical details. For example, request an internal order to acquire deployment data from SAS. Also, we'd better provide an pre-built container that run mirror manager inside.

build error

Describe the bug
./build.sh --type single --zip /home/centos/SAS_Viya_deployment_data.zip --addons "auth-demo"

groupadd: invalid group ID 'docker'
The command '/bin/sh -c groupadd --gid ${DOCKER_GID} docker' returned a non-zero code: 3

Document links in Home.md are wrong

Links at the beginning of the page like Introduction, System requirements, etc are resulting 404. It seems to me that ".md" is missing from the end of the links.

build.sh error: Unable to parse all content from SOE Zip exit status 1

Describe the bug

Trying to perform a docker build in a VM running Ubuntu 18.04.2 as guest OS , on Windows 10 host. Upon running the build script I get an SOE Error:

#To Reproduce
Run the build script with SOE zip

``
work@work:~/sas-container-recipes-19m04$ ./build.sh --type single --zip /home/work/SAS_Viya_deployment_data.zip --addons "auth-demo"

Building Docker Build Container

Sending build context to Docker daemon 2.136MB
Step 1/19 : FROM golang:1.12.0
---> cee68f119e19
Step 2/19 : ARG USER_UID=1000
---> Using cache
---> 1076921135f2
Step 3/19 : ARG DOCKER_GID=997
---> Using cache
---> 372931cdf39d
Step 4/19 : RUN apt-get update && apt-get install -y openjdk-8-jdk-headless ansible && rm -rf /var/lib/apt/lists/*
---> Using cache
---> 007dcfe51d92
Step 5/19 : RUN go get -x -u gopkg.in/yaml.v2 github.com/docker/docker/api/types github.com/docker/docker/client
---> Using cache
---> c50ca82c0101
Step 6/19 : RUN groupadd --gid ${DOCKER_GID} docker
---> Using cache
---> eb966abc16fb
Step 7/19 : RUN useradd --uid ${USER_UID} --gid ${DOCKER_GID} --create-home --shell /bin/bash sas
---> Using cache
---> 936eb8d0efcf
Step 8/19 : WORKDIR /sas-container-recipes
---> Using cache
---> f4d4c4558464
Step 9/19 : RUN chmod 777 /sas-container-recipes
---> Using cache
---> e721803871f8
Step 10/19 : COPY --chown=sas:docker addons ./addons
---> Using cache
---> 205663975502
Step 11/19 : COPY --chown=sas:docker samples ./samples
---> Using cache
---> ed27f1bb7f52
Step 12/19 : COPY --chown=sas:docker tests ./tests
---> Using cache
---> 197aa6afc60a
Step 13/19 : COPY --chown=sas:docker util ./util
---> Using cache
---> aa47b06ac46d
Step 14/19 : COPY --chown=sas:docker *.yml *.go ./
---> Using cache
---> 9bcfbc1d49a2
Step 15/19 : RUN chown -R ${USER_GID}:${DOCKER_GID} /sas-container-recipes
---> Using cache
---> 2934bab35e02
Step 16/19 : USER sas
---> Using cache
---> 7adc395018fd
Step 17/19 : ENTRYPOINT ["/usr/local/go/bin/go", "run", "main.go", "container.go", "order.go"]
---> Using cache
---> 008f4214070c
Step 18/19 : LABEL sas.recipe=true
---> Using cache
---> 21ba965ccbe8
Step 19/19 : LABEL sas.recipe.builder.version=19.04.0-20190510135948-no-git-sha
---> Running in de3b467b8811
Removing intermediate container de3b467b8811
---> e25b3f7bbbf9
Successfully built e25b3f7bbbf9
Successfully tagged sas-container-recipes-builder:19.04.0-20190510135948-no-git-sha

==============================
Running Docker Build Container

2e37b777abe3eeeb8f8cfb3d349d47e28c865e73c15482f019c122c0cc65dc70
2019/05/10 18:59:58

	Build Variables

==================================================
'Base Image ': centos:7
'Mirror URL ': https://ses.sas.download/ses/
'Virtual Host ': myvirtualhost.mycompany.com
'Docker Namespace ': ""
'Docker Registry ': ""
'Deployment Type ': single
'Platform ': redhat
'Project Name ': sas-viya
'Tag Override ': 19.04.0-20190510135948-no-git-sha
'AddOns ':

• addons/auth-demo/
  'Debug Containers ': []
  'Worker Count ': 1
  'Verbose ': false
  'Skip Mirror Validation ': true
  'Skip Docker Validation ': false
  'Generate Manifests Only ': false
  'Build Only ': []
  'Timestamp Tag ': 2019-05-10-18-59-58
  ==================================================

2019/05/10 18:59:58 Reading sitedefault.yml ...
2019/05/10 18:59:58 Skipping loading sitedefault.yml
2019/05/10 18:59:58 Fetching orchestration tool ...
2019/05/10 18:59:58 Reading Software Order Email Zip ...
2019/05/10 18:59:58 Connecting to the Docker daemon ...
2019/05/10 18:59:58 Finished connecting to Docker daemon
2019/05/10 18:59:58 Pulling base container image 'centos:7' ...

2019/05/10 18:59:58 Unable to parse all content from SOE zip
exit status 1
sas-container-recipes-builder-19.04.0-20190510135948-no-git-sha
``

Expected Behaviour

get the server address and be able to deploy

#Additional Context

We are therefore hitting this part of the build:

// Make sure all required files were loaded into the order if len(order.License) == 0 || len(order.MeteredLicense) == 0 || len(order.CA) == 0 || len(order.Entitlement) == 0 { fail <- "Unable to parse all content from SOE zip" return }

Any idea what the issue is with SOE? Could it be because we have a partner license?

Since the build complained about the SOE, I looked into the SOE structure as shown in
https://github.com/sassoftware/sas-container-recipes/blob/master/order.go

The only odd thing I saw, is that it seems like it is expecting a folder called license, but in our .zip, the folder is called licenses. Changing folder name did not fix the issue.

Also I noticed that while a windows Viya SOE had a jwt file, our Linux Viya does not. Could that be the issue?

#Environment

Our docker version and VM os details:
work@work:$ uname -a
Linux work 4.18.0-15-generic #1618.04.1-Ubuntu SMP Thu Feb 7 14:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
work@work:~$ docker version
Client:
Version: 18.09.6
API version: 1.39
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:35:57 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 01:59:36 2019
OS/Arch: linux/amd64
Experimental: false

github.com/docker/docker/client source not working

Describe the bug
There seems to be an issue with building container image with the sas-container-recipes.

To Reproduce
Steps to reproduce the behavior:
0. If the container was built before and the Dockerfile is unchanged the docker build command will skip the build steps and use cached data to create the image. If this case apply to you, you can add the
--no-cache flag to the docker build command in the build.sh script:
Command

docker build . \
    --no-cache \
    --label sas.recipe=true \
    --label sas.recipe.builder.version=${SAS_DOCKER_TAG} \
    --build-arg USER_UID=${UID} \
    --build-arg DOCKER_GID=${DOCKER_GID} \
    --tag sas-container-recipes-builder:${SAS_DOCKER_TAG} \
    --file Dockerfile \

1. Run time ./build.sh --type single --addons "auth-demo" --zip ~/recipes/sas-container-recipes/SAS_Viya_deployment_data.zip
2. Scroll to the

Step 5/20 : RUN go get -x -u gopkg.in/yaml.v2 github.com/docker/docker/api/types github.com/docker/docker/client

3. See error

The command '/bin/sh -c go get -x -u gopkg.in/yaml.v2 github.com/docker/docker/api/types github.com/docker/docker/client' returned a non-zero code: 2

Expected behavior
The github.com/docker/docker/client source in the go get command doesn't seem to work.
I did build this image few weeks ago and the build was successful.
I tried to built it on 2 environments - Centos and openstack rhel cluster.

Environment:

• 1st OS: CentOS Linux 7 (Core) , Docker version 19.03.8
• 2nd OS: Red Hat Enterprise Linux Server 7.7 (Maipo) , Docker version 1.13.1

Modifying Dockerfile with custom addons

Describe the bug
I am wondering if after building an image with auth-demo and ide-jupyter-python3, running the same build but with a modification to Dockerfile in addons/ide-jupyter-python3/Dockerfile, will pick up on the fact that I have added R and Rstudio server installation:

RUN yum install epel-release
&& yum update

RUN yum install -y R libcurl-devel cairo-devel \
&& yum clean all

RUN wget https://download2.rstudio.org/server/centos6/x86_64/rstudio-server-rhel-1.2.1335-x86_64.rpm \
&& yum install -y --nogpgcheck rstudio-server-rhel-1.2.1335-x86_64.rpm \
&& rm -f rstudio-server-rhel-1.2.1335-x86_64.rpm

Will the build.sh pick this change in Dockerfile up or should I start a new addon folder, called addons/ide-jupyter-python3-R-RStudio?

Could we have R and RStudio added to the addons?

viya-single-container running on K8S cluster cannot apply a new SAS license without rebuild

I've built SAS Viya 3.5 single container using your framework build.sh and SAS_Viya_deployment_data.zip including SAS license A. Containers created from the image run inside kubernetes cluster. After I added SETINIT_TEXT variable into kubernetes Config Map contained SAS license B and changed the manifest starting Viya containers I expected new Viya containers will start with SAS license B. Unfortunetly this functionality is not working for the image as described in doc https://go.documentation.sas.com/doc/en/dplyml0phy0dkr/3.5/n0qu54bw8k60fqn1rpevg0qnx0q0.htm
New Viya containers still have applied SAS license A in CAS and Foundation. The only change is inside Viya container we have SETINIT_TEXT env variable with license B.

After few tests I found I can change the SAS license only for pre-build single Viya container image downloaded from ses.sas.download docker repository. In example:
ses.sas.download/va-125-x64_redhat_linux_7-docker/sas-viya-programming:3.5.11-20210528.1622225215043

SAS Viya image build not completed-returned a non-zero code: 2

Could not get from the log what was the issue. Any insight please ? Attached log file.

Absolute path detected, but authentication failed.

Hi @hornpolish,

When I try to load image from an absolute path, I keep getting following message:
ERROR: Absolute path detected, but authentication failed. Please use a caslib, or gain the ability to assume an administrator role for using absolute paths.
ERROR: The action stopped due to errors.

And in CAS log, here is a corresponding message:
2018-09-05T09:28:22,234 INFO [00000007] cas local 14662 sasdemo 13 [tkcasaimp.c:6055] - -- 'image.loadimages' FAILED. Absolute path detected, but authentication failed. Please use a caslib, or gain the ability to assume an administrator role for using absolute paths.

Here is the code I run:

%matplotlib inline
import swat as sw
from IPython.display import Image, display

# Start CAS session
s = sw.CAS('localhost', 5570)
s.loadactionset('image')

path='/tmp/IMG'
s.image.loadimages(casout=dict(name='train', blocksize='128',replace=True), recurse=True, 
decode=True, distribution="RANDOM", labelLevels=-2, path=path)

You can just run it, and message will be shown. (it is shown before checking if this folder is exist)
Could you please help to point out the cause?

Thanks,
Neal

On login attempt: "The launch of the server process failed because of an invalid or inaccessible SASUSER library"

Describe the bug
When trying to volume mount my current working directory to the sasdemo folder in the container (so I can access it via SAS Studio), I am unable to log in, and I'm prompted with "The launch of the server process failed because of an invalid or inaccessible SASUSER library". I would like to mount to the sasdemo folder in the container so that files from the local machine can be opened, run, and edited in SAS Studio in the SAS container. I have been successful in volume mounting files to other locations within the container, and I can list them using SAS code within SAS Studio, but I'm unable to open them or view them in the file tree in the left panel in SAS Studio.

As an aside, it is also unclear if it is possible to simply run a .sas file via docker exec ... -- this is ultimately what I'm trying to do. Is there a way to do that? When trying docker exec --interactive --tty sas-viya-single-programming-only sas, I get the following error:

OCI runtime exec failed: exec failed: container_linux.go:349: starting container process caused "exec: \"sas\": executable file not found in $PATH": unknown

I guess there just isn't a symlink for sas. What is the path to the sas executable, or is there one?

To Reproduce
Steps to reproduce the behavior:

1. Edit the run arguments in launchsas.sh as follows:

run_args="
--name=$SAS_CONTAINER_NAME
--rm
--hostname $SAS_CONTAINER_NAME
--env RUN_MODE=developer
--env CASENV_ADMIN_USER=sasdemo
--env CASENV_CAS_VIRTUAL_HOST=$(hostname -f)
--env CASENV_CAS_VIRTUAL_PORT=${SAS_HTTPS_PORT}
--env CASENV_CASDATADIR=/cas/data
--env CASENV_CASPERMSTORE=/cas/permstore
--publish-all
--publish 5570:5570
--publish ${SAS_HTTP_PORT}:80
--publish ${SAS_HTTPS_PORT}:443
--volume ${PWD}/sasinside:/sasinside
--volume ${PWD}:/home/sasdemo/data-code    
--volume ${PWD}/cas/data:/cas/data
--volume ${PWD}/cas/cache:/cas/cache 
--volume ${PWD}/cas/permstore:/cas/permstore
"

2. navigate to port 8080 via the browser, and attempt to log in

Expected behavior
Successful log in.

Screenshots

Environment (please complete the applicable information):

• OS: CentOS Linux 7 for the docker image, ubuntu 18.04 is the host OS
• Browser: Chrome
• Version: v19m06

Failed to access deployTargert

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Run something with the following arguments and flags '...'
2. Scroll to '...'
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the applicable information):

• OS: [e.g. Fedora 29]
• Browser [e.g. chrome, safari]
• Version [e.g. v18m12]

Additional context
Add any other context about the problem here.

SAS Viya Deployment Size

Hi there! @hornpolish :)

I work at Statistics Canada and am super keen to help in this area as well and keen to make improvements to my workflow and align to best practices.

One thing I noticed is your installation is different then mine and I was curious what your total container size was with just Viya? I only ask because when I launch my SAS container in K8S it is a hefty 5GB which is why our jupyterhub SASpy notebook just runs sas kernel with SASpy and communicates with the separately launched SAS container via IOM. So when we have multiple launched jupyterhub users don't have such monolithic containers running.

However sometimes when working with files in the jupyter notebook it is nice to also be able to send those files to SAS without needing to use pandas so if the container size was more reduced I would no longer need to separate it from saspy. (Separately we did not separate our strata notebook with stata which was 1gb so was hoping for 1-2gb or so as a goal)

My temporary solution is to leverage blobfuse on the jupyter notebook saspy container and the SAS container as ultimately we want the data to reside on azure blob storage.

Background

a) Install steps I used: https://github.com/govcloud/docker-sas4c/blob/master/docs/install.md
b) Dockerfile: https://github.com/govcloud/docker-sas4c/blob/master/studio/Dockerfile
c) Jupyter SASpy Notebook: https://github.com/govcloud/jupyter-notebooks/tree/master/sas
c) Jupyter SASpy Notebook: https://github.com/govcloud/jupyter-notebooks/tree/master/stata
d) SAS Container deployed in cluster: https://github.com/govcloud/public-charts/tree/master/incubator/sas4c
e) Relevant Issue: sassoftware/saspy#151

Cannot create Kubernetes namespace

Describe the bug
Running this command
kubectl apply -f builds/full/manifests/kubernetes/namespace/sas-viya.yml
gives me the
error: unable to recognize "builds/full/manifests/kubernetes/namespace/sas-viya.yml": Get http://localhost:8080/api?timeout=32s: dial tcp [::1]:8080: connect: connection refused

Environment (please complete the applicable information):
[admin@RM-SAS-DOCKER-01 sas-container-recipes-master]$ docker version
Client:
Version: 18.09.6
API version: 1.39
Go version: go1.10.8
Git commit: 481bc77156
Built: Sat May 4 02:34:58 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:02:43 2019
OS/Arch: linux/amd64
Experimental: false

invalid repository type docker

Hi. Is this message expected? Was attempting to mirror the SAS repository as directed:

_skipping docker/v2/va-100-x64_redhat_linux_7-docker due to invalid repository type docker_

Entire command:

[cloud-user@viya-container ~]$ ./mirrormgr mirror --deployment-data /home/cloud-user/SAS_Viya_deployment_data.zip --platform x64-redhat-linux-7 --latest

Mirroring 1/2 docker/v2/va-100-x64_redhat_linux_7-docker
skipping docker/v2/va-100-x64_redhat_linux_7-docker due to invalid repository type docker
Mirroring 2/2 sasmd/shipped/va/100/va-100-x64_redhat_linux_7-dockersasmd
8.77 KiB / 8.77 KiB [===============================================================================================================================================================] 100.00% 64.77 KiB/s 0s
Done

Unable to run SAS code in Docker container-no permission for library SASHELP

Describe the bug
Running sample code on iris dataset from lib sashelp fails. This was tested on a local and Azure hosted single programming-only container. This fails in SAS Studio, SAS kernel as well as in SASPy. The user is sasdemo from the auth-demo addon.

In SAS the error is
SAS Connection established. Subprocess id is 56916

No encoding value provided. Will try to determine the correct encoding.
Setting encoding to utf_8 based upon the SAS session encoding value of utf-8.

24 ods listing close;ods html5 (id=saspy_internal) file=stdout options(bitmap_mode='inline') device=svg style=HTMLBlue; ods graphics on / outputfmt=png;
NOTE: Writing HTML5(SASPY_INTERNAL) Body file: STDOUT
25
26 proc hpsample data=sashelp.iris out=sashelp.iris samppct=70.0 seed=9878 Partition;
ERROR: User does not have appropriate authorization level for library SASHELP.
NOTE: The SAS System stopped processing this step because of errors.
NOTE: PROCEDURE HPSAMPLE used (Total process time):
real time 0.00 seconds
cpu time 0.00 seconds

27 class character;
28 target species;
29 var numeric;
30 run;
31
32
33
34
35
36 ods html5 (id=saspy_internal) close;ods listing;

37

In Python the full error is

---

RuntimeError Traceback (most recent call last)
in
----> 1 iris_part = iris.partition(fraction=.7, var='species')

/usr/local/lib/python3.6/site-packages/saspy/sasdata.py in partition(self, var, fraction, seed, kfold, out, singleOut)
431 elog.append(line)
432 if len(elog):
--> 433 raise RuntimeError("\n".join(elog))
434 if not singleOut:
435 outTableList = []

RuntimeError: ERROR: User does not have appropriate authorization level for library SASHELP.

To Reproduce
In a container with Python addon, open a notebook with SAS kernel and run
proc hpsample data=sashelp.iris out=sashelp.iris samppct=70.0 seed=9878 Partition;
class character;
target species;
var numeric;
run;

In a python kernel setup a SASpy session and run
import saspy
import pandas as pd
from IPython.display import HTML
sas = saspy.SASsession()
sas
iris = sas.sasdata('iris','sashelp')
iris_part = iris.partition(fraction=.7, var='species')

Expected behavior
Should be able to run basic code. If there is a SAS permission issue on this the danger is that many machine learning methods will fail, because they have built in sampling and partitioning methods.

Env

Client:
Version: 18.09.6
API version: 1.39
Go version: go1.10.8
Git commit: 481bc77156
Built: Sat May 4 02:34:58 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:02:43 2019
OS/Arch: linux/amd64
Experimental: false

rm: cannot remove ‘/etc/security/limits.d/20-nproc.conf’: No such file or directory

Hi there,

I could deploy and access SASStudio successfully the programming-only interface with the basic instructions. Easy and straightforward.

However, when I wanted to deploy with a local mirror and a local docker repo, the build fails with the error mentioned above.

The executed build command was:

./build.sh --type single --zip ../SAS_Viya_deployment_data.zip --addons "auth-demo" --verbose -m http://localhost:180/pulp -u localhost:5000 -i localhost:5000/va-125-x64_redhat_linux_7-docker/sas-viya-programming -t 3.5.9-20201210.1607626389474

The last lines of the log are:

`2021/03/08 13:43:10 single-programming-only:
Removing intermediate container 0b811cfe7dc9
2021/03/08 13:43:10 single-programming-only:
Removing intermediate container 0b811cfe7dc9

2021/03/08 13:43:10 single-programming-only: container build [ERROR] single-programming-only: map[code:1 message:The command '/bin/sh -c set -e;     echo; echo "####### Go ahead and add the packages that the Ansible playbook will look for"; echo;     if [ "$PLATFORM" = "redhat" ]; then         rpm --rebuilddb;         yum install --assumeyes java-1.8.0-openjdk libselinux-python which;         yum clean all;         rm --verbose --recursive --force /root/.cache /var/cache/yum;         rm --verbose /etc/security/limits.d/20-nproc.conf;     elif [ "$PLATFORM" = "suse" ]; then         zypper --non-interactive install -y java-1_8_0-openjdk tar curl hostname iproute2 which gzip;         zypper clean --all;         rm --verbose --recursive --force /var/cache/zypp;         sed -i 's/^*/#*/g' /etc/security/limits.conf;     fi;' returned a non-zero code: 1]

Debugging: builds/single-2021-03-08-13-39-33/sas-viya-single-programming-only/log.txt
exit status 1
sas-container-recipes-builder-19.06.1-20210308143900-no-git-sha`

I have tried to add the following line to the Dockerfile,
RUN touch /etc/security/limits.d/20-nproc.conf

But then the Build takes forever in the step for installing the packages openjdk-11-jdk-headless and ansible. Therefore I discarded this rough fix - as it fixes nothing.

Do you have any ideas, have you seen this before?

Thank you in advance!
Best regards,
Juan

Docker container Image starting as root user

Describe the bug
Docker inspect on the viya Image shows that the container runs as root

To Reproduce
Steps to reproduce the behavior:
docker inspect

Expected behavior

containers are expected to run as non-root user example "sas"

Cannot do full build on Centos7

Describe the bug
I am unable to do a full build, after successfully doing programming-only single build. I see the message:

2019/06/20 18:54:24 Serving license and entitlement on sas-container-recipes-builder:1976 (172.17.0.2)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x889372]

goroutine 23 [running]:
main.(*SoftwareOrder).TestRegistry(0xc0002c8000, 0xc00033c180, 0xc00033c120, 0xc00033c0c0)
/sas-container-recipes/order.go:1046 +0x1e2
created by main.NewSoftwareOrder
/sas-container-recipes/order.go:308 +0x7e3
exit status 2
sas-container-recipes-builder-19.05.0-20190620135121-no-git-sha

Is this complaining about the registry? Can it be azure container registry or must it be an actual dockerhub registry?

Thanks

To Reproduce
Steps to reproduce the behavior:
./build.sh --type full --docker-namespace sasfullxyz --docker-registry-url sasfullxyz.azurecr.io --zip /home/admin/sas-container-recipes-master/SAS_Viya_deployment_data.zip --addons "auth-demo ide-jupyter-python3"

Expected behavior
Get into the build step

Environment (please complete the applicable information):
[admin@RM-SAS-DOCKER-01 sas-container-recipes-master]$ docker version
Client:
Version: 18.09.6
API version: 1.39
Go version: go1.10.8
Git commit: 481bc77156
Built: Sat May 4 02:34:58 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:02:43 2019
OS/Arch: linux/amd64
Experimental: false

SAS Viya - running on a single container - build error - certificates

Describe the bug
I am following the instructions for deploying a single container inside Docker on a MacBook.

The Dockerfile within the container recipe contains the following command, which errors:

RUN go get -x -u gopkg.in/yaml.v2 github.com/docker/docker/api/types github.com/docker/docker/client

It seems to fail due to a certificate error, so can the code be amended so it does not error please?

To Reproduce
Run the standard build command in the instructions.
./build.sh --type single --zip ~/path/to/SAS_Viya_deployment_data.zip --addons "auth-demo"

Expected behavior
I expected it to run as expected.

Screenshots

===============================
Building Docker Build Container

./build.sh: line 268: getent: command not found
[+] Building 51.6s (8/19)

=> [internal] load build definition from Dockerfile
0.0s
=> => transferring dockerfile: 37B
0.0s
=> [internal] load .dockerignore
0.0s
=> => transferring context: 34B
0.0s
=> [internal] load metadata for docker.io/library/golang:1.14.0
2.6s
=> [auth] library/golang:pull token for registry-1.docker.io
0.0s
=> [internal] load build context
0.3s
=> => transferring context: 30.76kB
0.2s
=> [ 1/14] FROM docker.io/library/golang:1.14.0@sha256:a2919ec3e75deeea8a7a972bef833d9b9546d3ca93f5ef44009750e814172d8d
0.0s
=> CACHED [ 2/14] RUN apt-get update && apt-get install -y openjdk-11-jdk-headless ansible && rm -rf
/var/lib/apt/lists/* 0.0s
=> ERROR [ 3/14] RUN go get -x -u gopkg.in/yaml.v2 github.com/docker/docker/api/types github.com/docker/docker/client
48.8s

[ 3/14] RUN go get -x -u gopkg.in/yaml.v2 github.com/docker/docker/api/types github.com/docker/docker/client:

#7 1.200 # get https://gopkg.in/yaml.v2?go-get=1

#7 1.559 # get https://gopkg.in/yaml.v2?go-get=1: Get "https://gopkg.in/yaml.v2?go-get=1": x509: certificate signed by unknown
authority
#7 1.559 unrecognized import path "gopkg.in/yaml.v2": https fetch: Get "https://gopkg.in/yaml.v2?go-get=1": x509: certificate
signed by unknown authority
#7 1.560 cd .

#7 1.560 git clone -- https://github.com/docker/docker /go/src/github.com/docker/docker
#7 47.76 cd /go/src/github.com/docker/docker
#7 47.76 git submodule update --init --recursive
#7 47.80 cd /go/src/github.com/docker/docker
#7 47.80 git show-ref
#7 47.81 cd /go/src/github.com/docker/docker
#7 47.81 git submodule update --init --recursive
#7 48.21 cd /go/src/github.com/docker/docker
#7 48.21 git config remote.origin.url
#7 48.21 cd /go/src/github.com/docker/docker
#7 48.21 git config remote.origin.url
#7 48.21 cd /go/src/github.com/docker/docker
#7 48.21 git config remote.origin.url
#7 48.22 cd /go/src/github.com/docker/docker
#7 48.22 git config remote.origin.url
#7 48.22 cd /go/src/github.com/docker/docker
#7 48.22 git config remote.origin.url
#7 48.22 cd /go/src/github.com/docker/docker
#7 48.22 git config remote.origin.url
#7 48.22 cd /go/src/github.com/docker/docker
#7 48.22 git config remote.origin.url
#7 48.23 cd /go/src/github.com/docker/docker
#7 48.23 git config remote.origin.url
#7 48.23 cd /go/src/github.com/docker/docker
#7 48.23 git config remote.origin.url
#7 48.23 cd /go/src/github.com/docker/docker
#7 48.23 git config remote.origin.url
#7 48.23 cd /go/src/github.com/docker/docker
#7 48.23 git config remote.origin.url
#7 48.23 cd /go/src/github.com/docker/docker
#7 48.23 git config remote.origin.url
#7 48.23 cd /go/src/github.com/docker/docker
#7 48.23 git config remote.origin.url
#7 48.24 cd /go/src/github.com/docker/docker
#7 48.24 git config remote.origin.url
#7 48.24 cd /go/src/github.com/docker/docker
#7 48.24 git config remote.origin.url
#7 48.24 cd /go/src/github.com/docker/docker
#7 48.24 git config remote.origin.url
#7 48.43 cd /go/src/github.com/docker/docker
#7 48.43 git config remote.origin.url
#7 48.44 cd /go/src/github.com/docker/docker
#7 48.44 git config remote.origin.url
#7 48.45 cd /go/src/github.com/docker/docker
#7 48.45 git config remote.origin.url
#7 48.45 cd /go/src/github.com/docker/docker
#7 48.45 git config remote.origin.url
#7 48.45 cd /go/src/github.com/docker/docker
#7 48.45 git config remote.origin.url
#7 48.45 cd /go/src/github.com/docker/docker
#7 48.45 git config remote.origin.url
#7 48.45 cd /go/src/github.com/docker/docker
#7 48.45 git config remote.origin.url
#7 48.46 cd /go/src/github.com/docker/docker
#7 48.46 git config remote.origin.url
#7 48.46 cd /go/src/github.com/docker/docker
#7 48.46 git config remote.origin.url
#7 48.46 cd /go/src/github.com/docker/docker
#7 48.46 git config remote.origin.url
#7 48.46 cd /go/src/github.com/docker/docker
#7 48.46 git config remote.origin.url
#7 48.47 cd /go/src/github.com/docker/docker
#7 48.47 git config remote.origin.url
#7 48.47 cd /go/src/github.com/docker/docker
#7 48.47 git config remote.origin.url
#7 48.47 cd /go/src/github.com/docker/docker
#7 48.47 git config remote.origin.url
#7 48.47 cd /go/src/github.com/docker/docker
#7 48.47 git config remote.origin.url
#7 48.48 cd /go/src/github.com/docker/docker
#7 48.48 git config remote.origin.url
#7 48.48 cd /go/src/github.com/docker/docker
#7 48.48 git config remote.origin.url
#7 48.48 cd /go/src/github.com/docker/docker
#7 48.48 git config remote.origin.url
#7 48.48 cd /go/src/github.com/docker/docker
#7 48.48 git config remote.origin.url
#7 48.49 cd /go/src/github.com/docker/docker
#7 48.49 git config remote.origin.url
#7 48.49 cd /go/src/github.com/docker/docker
#7 48.49 git config remote.origin.url
#7 48.49 cd /go/src/github.com/docker/docker
#7 48.49 git config remote.origin.url
#7 48.49 cd /go/src/github.com/docker/docker
#7 48.49 git config remote.origin.url
#7 48.49 cd /go/src/github.com/docker/docker
#7 48.49 git config remote.origin.url
#7 48.50 cd /go/src/github.com/docker/docker
#7 48.50 git config remote.origin.url
#7 48.50 cd /go/src/github.com/docker/docker
#7 48.50 git config remote.origin.url
#7 48.50 cd /go/src/github.com/docker/docker
#7 48.50 git config remote.origin.url
#7 48.51 cd /go/src/github.com/docker/docker
#7 48.51 git config remote.origin.url
#7 48.51 cd /go/src/github.com/docker/docker
#7 48.51 git config remote.origin.url
#7 48.51 cd /go/src/github.com/docker/docker
#7 48.51 git config remote.origin.url

executor failed running [/bin/sh -c go get -x -u gopkg.in/yaml.v2 github.com/docker/docker/api/types
github.com/docker/docker/client]: exit code: 1

Environment (please complete the applicable information):

• OS: macOS Big Sur
• Browser: n/a
• Version: 11.6

Additional context
n/a