ansible is an agent-less configuration management tool with Infrastructure_as_Code (IaC), but high-level with a declarative syntax that is aimed to ordinary people to understand (or at least get a glimpse of the idea).

• https://docs.ansible.com/ansible/latest/reference_appendices/faq.html
  • Perhaps the canonical place talking about cowsay and how to turn it off.
  • At one point, it references mkpasswd – this, on Debian, seems to be part of the whois package… O_o (For historical reasons.)
    For me (canvon), at the time of writing (2022-10-10), seems quite as odd as “hundreds”(?) of Debian packages depending on library com_err built from the e2fsprogs sources. …

(The ansible “controller” node cannot run on Windows (native Win32 API etc.; it seems possible with WSL). A Linux/UNIX ansible controller can configure/manage Windows nodes, though.)

Correlation of ansible version with ansible-core version… ansible-core version requirements – maybe replace “devel” in the URL with a version number, like, 2.10… (N.B.: Anchor #node-requirement-summary was #prerequisites, back then.)

According to rmadison ansible and … python3:

• Debian 10 “buster”: ansible 2.7.7+dfsg-1+deb10u1 (or 2.9.16+dfsg-1~bpo10+2 with backports), while there is python3 3.7.3-1.
  • This is too old, as ansible changed module delivery radically since 2.10…
  • Although buster already is oldstable by the time of writing, it may well still be in use on some of my machines…
• Debian 11 “bullseye”: ansible 2.10.7+merged+base+2.10.8+dfsg-1, while there is python3 3.9.2-3.
  • This may be slightly new enough!
  • Real-world installations may still be before current stable (and may normally not be updated that easy), so we'd need to install it from some kind of external source, there…

• Official ansible documentation says to use a PPA (Personal Package Archive) for Ubuntu, and to use the same PPA with “fake”/translated release names for/from Debian, too.

• On Debian 11 “bullseye”, it should suffice to do apt install ansible, maybe?
• On Debian 10 “buster”, let's try something like python3 -m pip install ansible-core=2.10.8? Maybe with –user? Maybe in a venv? (Shipped Python should be enough, though; ansible-core 2.10 docs (linked above) state that Python 3.5 should be enough, while we have 3.7.)
  • Well, the problem seems to be getting at ansible-core 2.10… pypi.org release history seems to (roughly) begin at 2.11… :-S

Okay, it turned out using ansible-core 2.11.y with ansible 4.x would be installable on a python3 3.7.3 venv on a Debian 10 “buster”, like so:

• OS: Debian 10 “buster”
• Setup virtual environment for python:
  

  $ python3 -m venv NAME_OF_ENV

For the next steps, first run this in your current shell:

$ . NAME_OF_ENV/bin/activate

This sets up your current shell to use the virtual environment; keep running that shell so that software from the virtual environment will be used.

As said, the next steps are to be run in the virtual environment:

• Upgrade pip:
  

  (NAME_OF_ENV) $ python3 -m pip install --upgrade pip

• Install ansible sufficiently old for our Debian 10 python3 3.7.3:

  (NAME_OF_ENV) $ python3 -m pip install 'ansible>=4,<5'

This is meant to install Ansible (with community-curated collections) version 4.x, which should in turn pull in ansible-core ~2.11, which is the last core 2.x version to not require python3 3.8.

On my (canvon’s) system, this is expected to lead to the following installed versions:

• python3 3.7.3
• pip 22.2.2
• ansible 4.10.0
• ansible-core 2.11.12

• https://www.redhat.com/sysadmin/faster-ansible-playbook-execution mentions:
  • Activate callback plugins in ansible.cfg: [defaults] callbacks_enabled = timer, profile_tasks, profile_roles
    This will measure each task's execution time and output all of them ordered by time taken, at the end of the play. (At least I think that is what it does.)
  • Disable fact gathering to speed things up at start of play.
  • A lot more. I (canvon) don't need (or even don't understand) much of the rest…