SAS VIya 3.4 Preinstallation task is failing

[sascodequestion]

Hi Everyone,

At my customer site i am installing VIYA 3.4 on redhat Linux machines. I have completed all pre installation tasks as per the deployment guide. When i am executing the the below command it is failing with the below error. We have 4 machines in the architecture 1 is  for micro services, 1-CAS Contoller, 2-CAS Workers. i have created the account "sas" as installer (with same uid and gid in all the machines)  account and it has sudo previliges in all the 4 machines and also enabled passwordless ssh. Please let me know if i am missing anything.

command :ansible-playbook system-assessment.yml

Error:

TASK [ensure_install_user : Ensure installation user and group are present] ******************************************************************************************************************************************************************
fatal: [deployTarget]: FAILED! => {"changed": true, "msg": "non-zero return code", "rc": 126, "stderr": "Shared connection to 974760-xxxxxxxxxxxxxxxxx closed.\r\n", "stderr_lines": ["Shared connection to 974760-xxxxxxxxxxxxxxxxxclosed."], "stdout": "/bin/sh: /tmp/.sas.ansible/ansible-tmp-1542907964.41-102175813031644/create_sas_user_group.sh: Permission denied\r\n", "stdout_lines": ["/bin/sh: /tmp/.sas.ansible/ansible-tmp-1542907964.41-102175813031644/create_sas_user_group.sh: Permission denied"]}

fatal: [cas-controller]: FAILED! => {"changed": true, "msg": "non-zero return code", "rc": 126, "stderr": "Shared connection to 974762-xxxxxxxxxxxxxxxxx closed.\r\n", "stderr_lines": ["Shared connection to 974762-sasinttst02.incres earch.com closed."], "stdout": "/bin/sh: /tmp/.sas.ansible/ansible-tmp-1542907964.44-267215150093204/create_sas_user_group.sh: Permission denied\r\n", "stdout_lines": ["/bin/sh: /tmp/.sas.ansible/ansible-tmp-1542907964.44-267215150093204/create_sas_user_group.sh: Permission denied"]}

fatal: [cas-worker1]: FAILED! => {"changed": true, "msg": "non-zero return code", "rc": 126, "stderr": "Shared connection to 974763-xxxxxxxxxxxxxxxxx closed.\r\n", "stderr_lines": ["Shared connection to 974763-sasinttst03.incresearch.com closed."], "stdout": "/bin/sh: /tmp/.sas.ansible/ansible-tmp-1542907964.48-209654282955594/create_sas_user_group.sh: Permission denied\r\n", "stdout_lines": ["/bin/sh: /tmp/.sas.ansible/ansible-tmp-1542907964.48-209654282955594/create_sas_user_group.sh: Permission denied"]}

fatal: [cas-worker2]: FAILED! => {"changed": true, "msg": "non-zero return code", "rc": 126, "stderr": "Shared connection to 974764-xxxxxxxxxxxxxxxxx closed.\r\n", "stderr_lines": ["Shared connection to 974764-sasinttst04.incresearch.com closed."], "stdout": "/bin/sh: /tmp/.sas.ansible/ansible-tmp-1542907964.52-154406900839758/create_sas_user_group.sh: Permission denied\r\n", "stdout_lines": ["/bin/sh: /tmp/.sas.ansible/ansible-tmp-1542907964.52-154406900839758/create_sas_user_group.sh: Permission denied"]}

[JuanS_OCS]

Hello,

did you try to run the same command with -vvv or -vvvv parameter? Could you use the VIRK playbooks?

It seems to me as the connection of the user for installation, as sudoer, the sas group, the sas/cas users and memberships are missing. But we would need to know more through the verbose and debug outputs.

The VIRK playbooks can help you at least to do even more checks and give you more info. Also to automate pre-requisites.

[boemskats · Accepted solution]

RC 126 means that you're unable to execute that shell script, create_sas_user_group.sh that Ansible copies over to the /tmp filesystem as part of the deployment because the execute bit isn't set. That's what the Permission Denied bit also indicates.

This will be because your /tmp filesystem is mounted with the noexec flag, therefore Ansible is unable to set the execute bit on that script before running it. You will need to talk to your sysadmins to remove the noexec flag from your /tmp mount in /etc/fstab.

You can verify that this is the case by running the mount command on the target machine. You'll see noexec as one of the mount flags for the /tmp filesystem.

Nik

[sascodequestion]

Hello NIk,

Yes you were write. In all of my servers /tmp was set to non executable. Changing that to exec fixed the issue. Now after the assessment i went ahead with the deployment and now i am facing the below error. Please take a look.

fatal: [deployTarget]: FAILED! => {
"changed": true,
"cmd": [
"bash",
"-c",
"source /opt/sas/viya/config/consul.conf && /opt/sas/viya/home/bin/sas-bootstrap-config status leader"
],
"delta": "0:00:00.094242",
"end": "2018-11-23 06:48:24.463456",
"invocation": {
"module_args": {
"_raw_params": "bash -c 'source /opt/sas/viya/config/consul.conf && /opt/sas/viya/home/bin/sas-bootstrap-config status leader'",
"_uses_shell": false,
"argv": null,
"chdir": null,
"creates": null,
"executable": null,
"removes": null,
"stdin": null,
"warn": true
}
},
"msg": "non-zero return code",
"rc": 1,
"start": "2018-11-23 06:48:24.369214",
"stderr": "Get https://localhost:8501/v1/status/leader: dial tcp [::1]:8501: getsockopt: connection refused\nERROR: Unable to determine the address of the Raft leader for the data center in which the Consul agent is running.",
"stderr_lines": [
"Get https://localhost:8501/v1/status/leader: dial tcp [::1]:8501: getsockopt: connection refused",
"ERROR: Unable to determine the address of the Raft leader for the data center in which the Consul agent is running."
],
"stdout": "",
"stdout_lines": []
}

PLAY RECAP ***********************************************************************************************************************************************************************************************************************************
cas-controller : ok=126 changed=26 unreachable=0 failed=0
cas-worker1 : ok=125 changed=22 unreachable=0 failed=0
cas-worker2 : ok=125 changed=22 unreachable=0 failed=0
deployTarget : ok=187 changed=54 unreachable=0 failed=1
localhost : ok=14 changed=1 unreachable=0 failed=0

[boemskats]

Glad it fixed it.

Make sure that you run the deployment_cleanup.yml playbook between install attempts, and then try again. If you get this error again then at least it's a more meaningful Consul error with which someone else should be able to help. It might be an idea to start a separate thread for it.

[sascodequestion]

Thanks Nik. The issue was coming because the linux servers are having more than 1 NIC cards. Mentioning which one to use in the inventory.ini file fixed the issue.