We currently utilize Salt to manage Ubuntu, Debian, CentOS, and Windows servers.
The salt master is on 3003 and most of the salt minions are on 3002.6. A set of glaring exceptions: the VoIP servers. They are currently on CentOS-6 but we’re going to upgrade all of them to what our test machine is running right now: 12.7.8-2104-1.sng7
The problem is that I can’t seem to get salt-minion to install any way I try. The CentOS-6 servers have old versions that I can’t seem to upgrade past version 2016.11.3 but while that’s weird, since we’re moving everything to the version above, it’s not really a pressing issue.
But that’s a moot point at the moment since I can’t get salt installed any way I try.
Bootstrap? Nope.
error: Failed dependencies:
epel-release is obsoleted by (installed) sangoma-release-7-8.2003.3.el7.sangoma.x86_64
Retrieving dl dot fedoraproject dot org /pub/epel/epel-release-latest-7.noarch.rpm (had to trim this since I’m a new user and can’t post links)
ERROR: Failed to run install_red_hat_linux_stable_deps()!!!
CentOS repo from saltstack? Nope. Salt wants a very specific python3 and all I get when trying to install that way is a bunch of transaction errors about one version of python fighting another. Looks like a whole bunch of this:
file /usr/include/python3.6m/pyconfig-64.h from install of python3-libs-3.6.8-13.el7.x86_64 conflicts with file from package python36u-libs-3.6.7-1.ius.centos7.x86_64
file /usr/lib64/libpython3.6m.so.1.0 from install of python3-libs-3.6.8-13.el7.x86_64 conflicts with file from package python36u-libs-3.6.7-1.ius.centos7.x86_64
wget-ing the RPMs and installing with -ivh --nodeps flags? Also nope.
I’m at a bit of a loss and would appreciate anyone pointing me in the right direction.
I would get that far and then after I hit Y, it would give me that list of transaction errors. I tried both the 3002.6 version repo and then the latest (the one you had linked above).
Might have to start fresh and use just that command above (without the other attempts) to see how it goes. Yay for having a testbed server…
It has it’s own repositories with its own versions of things which align with what is tested/needed for Sangoma products. While most 3rd party EL stuff should work adding EL repos from any source may cause your machine to have issues and become unusable.
Back in the day there was a hard fast rule to NEVER yum update. This hasn’t been an issue with SNG because of the version management. Their repo is not a mirror of the upstream.
Your best bet is to build from source on things when possible. This is a PITA but prevents causing yum issues.
Well, it installed! It’s an older version (3000.9) but that’s significantly better than the version we were running before and much better than not having a version at all.