FreePBX seasoned with a dash of Salt

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.

You have extra repositories installed creating conflicts. Namely EPEL and IUS it looks like.

Sadly, it seems you get an even older version on SNG7 than you do on CentOS 6.

Without those repos, I have no issue with installing the latest salt repo directly, and then installing salt-minion.

sudo yum install https://repo.saltproject.io/yum/redhat/salt-repo-latest.el7.noarch.rpm

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…

Let me actually run it. The boss is on vacation anyway. Who needs a test bed?

Appreciate that. Thanks.

Works.

I se the IUS dep in there? Maybe that is from Sangoma. So you likely jsut need to not use EPEL.

Going back to the link you posted in your sudo yum install, I think I see where I went wrong. The directions I followed for the repo were:

sudo rpm --import https://repo.saltproject.io/py3/redhat/7/x86_64/latest/SALTSTACK-GPG-KEY.pub
curl -fsSL https://repo.saltproject.io/py3/redhat/7/x86_64/latest.repo | sudo tee /etc/yum.repos.d/salt.repo

I will try it the other way and see what I get. Thanks!

I just went here: https://repo.saltproject.io/yum/redhat/

Because the first link I found was for an old version.

Note: SNG7 is derived from EL7 but IS NOT EL7

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.

1 Like

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.

Thanks!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.