"I think the answer is still shell scripts and then add on CM afterwards."
I'm genuinely curious. Why? Ansible, in particular, provides the same value (easy) but has existing modules to do a bunch of the things you'd have to script.
you gotta setup the ssh user, modify/install ssh keys, install python if it's not there, possibly adjust firewalls, setup the hostnames, possibly tell the machine where to find the private dns servers, etc.
Isn't that what Redhat's kickstart (and it's equivalents in other distros) is for? Give you the minimum base you've decided your org wants systems installed with? It's trivial to add users, keys, initial firewall config, etc.
If you deploy more than a few systems a year and don't have a PXE boot environment (or at least the equivalent of a network accessible kickstart config to be manually selected) or a golden image to deploy from, then I can see how CM tools may seem a pain, because you haven't tackled the initial manual pain point yet, the actual install.
I haven't really used any CM tools, so maybe I'm getting the point where kickstart would traditionally leave off and ansible or chef would take over slightly wrong, but I can't see it being all that complex to automate configuring one after install.
No, you obviously have console access, all you need is the ansible scripts and ansible. If you want to push from a central repository, then yes, you'd have to have a way for ansible to reach the box. But we're taking as a given that there's a way to run commands on the box here (and get script files via the network).
There's a difference if you want to run the scripts automatically on install (non-interactively).
Actually, to use Ansible you need only ssh access (with password or public key) to root user. Everything else can be done easily in a simple Ansible role.
In my experience, there's a huge amount of work involved in just getting Ansible (and other CM systems) to work right in the first place, especially if you're relatively new to CM.
Sometimes you're working on a scrappy prototype and it's just quicker to use shell scripts initially and then go back to solidify the setup into CM scripts afterwards, once you know what you actually need.
Of course that approach will fall to hell if one never gets back around to making the CM scripts.
I'm genuinely curious. Why? Ansible, in particular, provides the same value (easy) but has existing modules to do a bunch of the things you'd have to script.