Hello Ross, On 2021-11-21 22:09+1300, Ross Younger via users wrote: The short version is, they're like glorified Makefiles, only proceeding with other bits if the first bit succeeds. For a single instance, you can use Ansible against the localhost. I do something like this for that: $ ansible -i localhost, -b playbook_file.yaml Well, git is what most people use, but use what you're happy with. I tend to put these in a tree in say, /home/ed/git/config/etc, then push that to the remote places with Ansible, one way or another rather than put /etc under version control itself. Promotional warning, 'please' exists too, thoughts welcomed :) <https://gitlab.com/edneville/please> I prefer the design of Ansible, things start of in an area of high privilege and trickle down into areas of doubt and lower security. In the puppet model, lower privilege and lower trust areas connect into the areas of higher trust, the area that keeps all the secrets. I don't like that much and there have been issues due to this design. It is more popular though I will always fight the corner of Ansible as I prefer the way that high trust area initiates communication with the lower trust. Ansible can work in a stand alone environment without /much/ work. I think I have an idea of what you're trying to do, maybe this helps, in my search bubble there were usage examples from others, which might match what you're trying to do: <https://www.google.com/search?q=ansible-playbook+localhost> Ed

Firstly, a ringing endorsement for Ansible here. I've used Puppet before, and while that's useful for large fleets of machines which need to be policed on their configuration, it's not so great for ad-hoc machines. My worry is the second part of your email where you mix several items into one block: * Config files (managed with Ansible) under revision control (um, perhaps manage the Config files with Ansible, and your ansible scripts with Git) and convenient auto backup (Or, use etckeeper, and have a cronjob which does a git push to a central repo store?) * All superuser actions fully logged (um, auditd is your friend here, so you'd then need a central syslogd to push those logs to it) and replayable (yehr, that's not going to happen... - the way to enforce this is to completely prevent all logins to the box, and manage it entirely with some automation tooling - like Ansible - but your ops teams [*] will HATE this) * Nobody gets direct sudo access, but I can give out admin access (yep, ansible can change user groups and /etc/sudoers files) Regarding that second item, my employer used https://www.ssh.com/academy/iam/pam in the past which basically you put in front of your managed device, and it's the only box with SSH keys to access it, but it's got a service that records all the TTY while you're logged into the box. That said, it's a commercial service, and means you've got another device to manage too. Regarding learning Ansible, it's pretty straightforward. I've done a few podcasts about it (shameless plug for the podcast I'm a regular co-host on - https://www.adminadminpodcast.co.uk/ep63/ and one where I just joined them to talk about Ansible - https://lhspodcast.info/2019/10/lhs-episode-307-ansible-deep-dive/) but you'll also find lots of videos on Youtube, Udemy and A Cloud Guru about Ansible. If this really is a one-off event, then disable password login from your host, and have it calling out every 30 minutes (to a github repo for playbook changes using ansible-pull) to enable it again. Your build process should be: 1. Install OS (any Linux distro will do, but I'd suggest one of the commercially supportable ones, like RHEL, Ubuntu, etc) 2. Set a LONG password for the root user. Sign in as root. 3. Remove your user account. 4. Install git and python3-pip then `pip install ansible`. 5. git clone https://some.git.service/yourOrgAccount/OfficeHubMachinePlaybook to somewhere sensible (changing URL, natch) 6. ansible-playbook /opt/OfficeHubMachinePlaybook/setup.yml To create your OfficeHubMachinePlaybook, I'd suggest using Vagrant to rapidly provision and destroy a VM with the configuration on it. That way, if you want to see what the current state of your deployed host is, you can just issue `vagrant up` and then it'll be operating like your deployed node. If you don't mind having a little bit of SSH access into the host - you could setup and run Ansible Tower (a commercial product from RedHat and requires a RHEL device to run Tower on) or AWX (the open source upstream project), as this will record your Ansible activities, including all the logs from your playbook. It will also schedule regular deployment activities (e.g. every day, run the security-updates playbook, or every week, run the full-upgrade playbook, or every time the git repo is updated, run the provision playbook)... but again, this is another machine you have to feed and water and manage and maintain. This gives you a friendly web interface, and as your ops [*] get more capable, they can be trusted to run more activities on this node, and it keeps all your "secrets". [*] Obviously, if you don't have an ops team, then ... ignore this part :) -- Jon "The Nice Guy" Spriggs @jontheniceguy everywhere... https://jon.sprig.gs On Sun, 21 Nov 2021 at 09:18, Ross Younger via users < users(a)lists.bitfolk.com&gt; wrote: