Hi Erwan,
Thanks for taking the time to provide such detailed comments and advice. That will be very helpful indeed.
It's good to hear that a dedicated service account for the deployment is the way to go. I went with it having sudo access with no password on all the machines too. I imagine that some customers will want to constrain this, but for my dev/test environment it simplifies things. In my initial sudo setup there was a subtle flaw in the way I had it configured that showed up with a no-sudo-to-sas error at one of the playbook steps. In the end what worked for me was to have the following in /etc/sudoers.d/casinstall
casinstall ALL=(ALL) NOPASSWD: ALL
Which would of course need be adjusted if a different deployment user id was used. Using viyadep does sound a bit better than casinstall so I might use that too in future (I like consistency).
I like the sound of the sas and cas accounts being service accounts with no ability to login with a password. I had created them with passwords (sas had one from the standard OS image I had), but I use SSH key based access to them (and casinstall) from my personal workstation account anyway. I will disable the password, for cas at least, in future deployments.
After I wrote my original question I did another deployment for a different product set and a different playbook. For that one I used all AD accounts rather than local accounts (for consistent UID, GID, passwords etc). I also tried to use the same Ansible controller. I was planning on also using it as a mirror repository, however, looking at the mirror repo instructions for this 2nd deployment they seemed different which got me wondering if an Ansible controller and mirror repo can be shared between different SAS Viya deployments or not. I ran into some difficulties with that deployment and, even after undeploying, am unable to re-deploy now, getting very odd errors about directories not existing when they would have been created by the playbook before. It sounds like there is some left over config that is being used to skip some initial playbook steps, but I'm not sure where it is yet. I'm going to start over with a new OS image and this time have a dedicated Ansible controller on the same machine as the SAS Viya deployment for simplicity.
That does leave me with some questions about Ansible controllers for SAS Viya deployments:
1) Can an Ansible controller be used for multiple differently configured Viya playbooks/deployments, or does the Ansible controller effectively become tied to that deployment, meaning a new controller for each different deployment?
2) If the Ansible controller can be shared is it intended that a mirror repo can service multiple different product mixes/playbooks/deployments? i.e. somewhat akin to having multiple orders in a SAS9 depot.
Any thoughts you have on that would be much appreciated.
With my AD-accounts only setup, I ran into an interesting issue: AD does not allow a user and group to have the same name, so whilst I had a sas user in AD, I had to name the AD group something other than sas - I use sassys. The Viya doc and playbook assumes the group is named sas. I saw that vars.yml had a casenv_group setting that I could change to sassys to set the group for the cas user. For the sas user I saw that I could edit the file group_vars/all and set INSTALL_GROUP to sassys. However that file has a comment saying "Do not alter the values in this file without the guidance of SAS Technical Support" so I was not sure how well it was going to work. In the end I decided to add a local group with the name sas but with the same GID as the sassys group in AD. The AD users cas, sas, and casinstall had their AD primaryGroupID set such that the sas/sassys group was their primary group. BTW I use realmd to setup my Linux images for AD auth - it makes it very easy - see https://platformadmin.com/blogs/paul/2015/07/active-directory-authentication-for-sas-on-linux-with-realmd/ This method, by default, has UID and GID vaues derived from objectSid and so the numbers are largish but avoids the need to set unix/posix attributes for all users and groups in AD. Since that sas/sassys group only has members via the users primary group setting I also don't have to worry about keeping the local and AD group sas/sassys membership in sync (the local group has no real members just those primary group members).
So another question I have is: 3) Is it supported to name the cas/sas/casinstall primary group something other than sas and is it sufficient to just change just the 2 settings mentioned above, or are there other things that need to be done.
Thanks for confirming that sasboot is not an OS account. That explains why I couldn't find it post install 😉 I think it would be helpful if the SAS Viya 3.2 Deployment Guide clarified that this was an internal account and not an OS account. I also find this interesting because I had previously though that Viya only did AD/LDAP auth for users and I didn't know that it to ability to have internal users (only custom groups). I assume this is for SAS internal product use only and not for SAS customers to take advantage of?
I'm certainly looking forward to finding out more about Ansible and how I might be able to use it to automate some pre-req tasks and more!
Once again thanks for posting your thoughts and advice.
Cheers Paul
... View more
![SASGF 2020 [Virtual] Attendee](/html/@A53A708409112314CE528E074D4C8C1F/badge_icons/badge_sasgf20_attendee.png "SASGF 2020 [Virtual] Attendee"){kind=icon}
