A way to run Ansible 2.19 on old operating systems like Ubuntu 18.04 with working Apt
sigmonsez
nix?
hoistbypetard
I have a possibly stupid question. You say that
It would be nice to manage such servers via (an up to date) Ansible.
Why? I'd be tempted to keep an 18.04 management box with a 3.6-compatible ansible around to manage those systems. That's the kind of thing we used to do when I had to manage RHEL5 boxes as they got to be about that age, though not with Ansible. Keeping an extra management VM around for those seemed like less effort than what you've described, so I wonder if I'm missing an aspect of why it would be nice to use an up-to-date management system.
ine
I don't see a reason to keep ansible up to date version either (if you have old hosts hanging around)
I keep an older ansible-core install in a virtualenv which doesn't need VMs or containers, which is even less effort than a dedicated management machine.
raymii
Ansible has execution environments, that sort of behave like an older version.
But you also have to keep your playbooks up to date for newer ansible, otherwise you're managing multiple collections of playbooks, for different versions. That, for me at least, beats the point, it then doesnt save time over manually doing things. Just as much, or maybe less, work...
And in my case this is the only old server, tied to expensive hardware, so keeping a management machine around is also overhead...
JustinAzoff
Wouldn't it be easier to upgrade or reinstall, and then use ansible to reconfigure the server? I'm confused about the opposing situation of having an old server, but at the same time using ansible (or any IAC software) and the solution not being "rebuild it".
jstoja
Ansible dropped support for Python 2.7 and 3.6 on the target node (where the playbook executes) in Ansible version 2.17.
RHEL 8 which is still supported doesn’t have a Python version recently enough to upgrade to the Ansible version from a few years ago. It’s been broken for a long time.
It’s like Red Hat not event keeping up with their own products…
sigmonsez
nix?
hoistbypetard
I have a possibly stupid question. You say that
It would be nice to manage such servers via (an up to date) Ansible.
Why? I'd be tempted to keep an 18.04 management box with a 3.6-compatible ansible around to manage those systems. That's the kind of thing we used to do when I had to manage RHEL5 boxes as they got to be about that age, though not with Ansible. Keeping an extra management VM around for those seemed like less effort than what you've described, so I wonder if I'm missing an aspect of why it would be nice to use an up-to-date management system.
ine
I don't see a reason to keep ansible up to date version either (if you have old hosts hanging around)
I keep an older ansible-core install in a virtualenv which doesn't need VMs or containers, which is even less effort than a dedicated management machine.
raymii
Ansible has execution environments, that sort of behave like an older version.
But you also have to keep your playbooks up to date for newer ansible, otherwise you're managing multiple collections of playbooks, for different versions. That, for me at least, beats the point, it then doesnt save time over manually doing things. Just as much, or maybe less, work...
And in my case this is the only old server, tied to expensive hardware, so keeping a management machine around is also overhead...
JustinAzoff
Wouldn't it be easier to upgrade or reinstall, and then use ansible to reconfigure the server? I'm confused about the opposing situation of having an old server, but at the same time using ansible (or any IAC software) and the solution not being "rebuild it".
jstoja
Ansible dropped support for Python 2.7 and 3.6 on the target node (where the playbook executes) in Ansible version 2.17.
RHEL 8 which is still supported doesn’t have a Python version recently enough to upgrade to the Ansible version from a few years ago. It’s been broken for a long time.
It’s like Red Hat not event keeping up with their own products…
nix?
I have a possibly stupid question. You say that
Why? I'd be tempted to keep an 18.04 management box with a 3.6-compatible ansible around to manage those systems. That's the kind of thing we used to do when I had to manage RHEL5 boxes as they got to be about that age, though not with Ansible. Keeping an extra management VM around for those seemed like less effort than what you've described, so I wonder if I'm missing an aspect of why it would be nice to use an up-to-date management system.
I don't see a reason to keep ansible up to date version either (if you have old hosts hanging around)
I keep an older ansible-core install in a virtualenv which doesn't need VMs or containers, which is even less effort than a dedicated management machine.
Ansible has execution environments, that sort of behave like an older version.
But you also have to keep your playbooks up to date for newer ansible, otherwise you're managing multiple collections of playbooks, for different versions. That, for me at least, beats the point, it then doesnt save time over manually doing things. Just as much, or maybe less, work...
And in my case this is the only old server, tied to expensive hardware, so keeping a management machine around is also overhead...
Wouldn't it be easier to upgrade or reinstall, and then use ansible to reconfigure the server? I'm confused about the opposing situation of having an old server, but at the same time using ansible (or any IAC software) and the solution not being "rebuild it".
RHEL 8 which is still supported doesn’t have a Python version recently enough to upgrade to the Ansible version from a few years ago. It’s been broken for a long time.
It’s like Red Hat not event keeping up with their own products…
nix?
I have a possibly stupid question. You say that
Why? I'd be tempted to keep an 18.04 management box with a 3.6-compatible ansible around to manage those systems. That's the kind of thing we used to do when I had to manage RHEL5 boxes as they got to be about that age, though not with Ansible. Keeping an extra management VM around for those seemed like less effort than what you've described, so I wonder if I'm missing an aspect of why it would be nice to use an up-to-date management system.
I don't see a reason to keep ansible up to date version either (if you have old hosts hanging around)
I keep an older ansible-core install in a virtualenv which doesn't need VMs or containers, which is even less effort than a dedicated management machine.
Ansible has execution environments, that sort of behave like an older version.
But you also have to keep your playbooks up to date for newer ansible, otherwise you're managing multiple collections of playbooks, for different versions. That, for me at least, beats the point, it then doesnt save time over manually doing things. Just as much, or maybe less, work...
And in my case this is the only old server, tied to expensive hardware, so keeping a management machine around is also overhead...
Wouldn't it be easier to upgrade or reinstall, and then use ansible to reconfigure the server? I'm confused about the opposing situation of having an old server, but at the same time using ansible (or any IAC software) and the solution not being "rebuild it".
RHEL 8 which is still supported doesn’t have a Python version recently enough to upgrade to the Ansible version from a few years ago. It’s been broken for a long time.
It’s like Red Hat not event keeping up with their own products…