SOLVED IncrediblePBX on CentOS 7

[ajonate]

None of the IncrediblePBX installation shell scripts work with CentOS 7 because a bogus Linux policy kit (polkit) is installed early in the script, which breaks systemctl. With systemctl broken, services can't be started or stopped on Centos 7. This isn't an issue with CentOS 6 because the "service" command isn't broken with polkit. The fix is to uninstall polkit sometime after the yum groupinstall runs, using this command:

yum -y remove polkit

For example, in the IncrediblePBX13-12R.sh file, add that command sometime after the preliminary yum installs. Most likely polkit comes from the groupinstall in line 213 in the following image.

http://entomy.com/polkit.jpg

Line 217 was left blank in the original file, so that's where I added the yum remove command, which you can see highlighted in the image. Save the file and your install will run fine using this install recipe.

http://nerdvittles.com/?p=14208

I edited incrediblepbx-13-13-LEAN.tar.gz similarly and the install ran fine with these instructions.

http://nerdvittles.com/?p=23948

Unfortunately it's pretty clear that 13-13-LEAN will need a lot of work to be compatible with CentOS 7, since it kicked a lot of errors after the install. But 13-12.2 looks pretty good.

****Edited to Add****

It turns out that polkit is installed sometime after line 217, so the above fix is inaccurate. In a previous install I removed polkit in a second SSH window and it worked, but I'm not sure where the install was when it happened.

I'm running it again at line 344 to see if that fixes it.

Yes, it seemed to work fine to remove polkit at line 344, the line before:

#install Asterisk packages

But I confirmed that polkit is installed in line 213. Maybe it's installed twice, or maybe I made a syntax error in my earlier edit. I'm not sure.

 

[wardmundy]

@ajonate: Updated and uploaded new 13-13 installer. THANKS very much for the tip.

 

[ajonate]

Ok, I took the time to try a reinstall of IncrediblePBX13-12R.sh with removing polkit at line 217, as described in the original post above. It worked fine. I must have made a syntax error the first time.

I'm happy we can move ahead with CentOS 7 installations. CentOS 6 end of life is coming Nov 2020.

 

[wardmundy]

@ajonate: You really should move to Incredible PBX 13-13. We stopped updating 13-12 more than a year ago because FreePBX 12 no longer is supported. If you find bugs in 13-13, we'll be glad to address them. The 13-13 code base started exactly the same as 13-12 and added the FreePBX 13 GPL modules.

 

[ajonate]

I'll try that again later today. I'll let you know how it goes.

 

[ajonate]

@ajonate: You really should move to Incredible PBX 13-13. We stopped updating 13-12 more than a year ago because FreePBX 12 no longer is supported. If you find bugs in 13-13, we'll be glad to address them. The 13-13 code base started exactly the same as 13-12 and added the FreePBX 13 GPL modules.

I stand corrected Incredible 13 13 looks great on CentOS 7. I prefer the condensed appearance of FreePBX 12, but I can get used to it.

Can updates be started with a sudo command? I prefer not to allow root logins with ssh.

 

[wardmundy]

I stand corrected Incredible 13 13 looks great on CentOS 7. I prefer the condensed appearance of FreePBX 12, but I can get used to it.

Can updates be started with a sudo command? I prefer not to allow root logins with ssh.

We use a firewall whitelist. The whole Asterisk design always has centered around a root login so I'm not sure what would get broken by switching to sudo.

 

[ajonate]

We use a firewall whitelist. The whole Asterisk design always has centered around a root login so I'm not sure what would get broken by switching to sudo.

Root logins aren't that big of a deal, but common wisdom says that allowing root logins makes a system somewhat easier to compromise. With root logins a hacker has to find an unknown password. Without root logins a hacker has to find both an unknown username and an unknown password, adding a dimension of complication to compromising the machine.

I allowed root logins for years and never had a problem. I started doing it because I used to attend the annual DEF CON conference here in Las Vegas. That would have been 10 to 15 years ago. All they talked about was Linux & network security. After hearing stories about intrusions and learning about newly discovered vulnerabilities for several days straight, I started to become really anal retentive about Linux security. Maybe too anal retentive.

Without root logins I create an unprivileged user, make him a member of the wheel group, and add him to the sudoers file. To avoid using the sudo command over & over I issue the command "sudo bash" right after logging in, effectively making me root. But I see how to update when not root.

sudo bash
cd /root
./update-IncrediblePBX

 

[wardmundy]

@ajonate: Understand completely, but with Travelin' Man 3 firewall, SSH and HTTP access is only available to IP addresses in the whitelist so other users can't even see your server. Otherwise, I would agree.

 

[ajonate]

@ajonate: Understand completely, but with Travelin' Man 3 firewall, SSH and HTTP access is only available to IP addresses in the whitelist so other users can't even see your server. Otherwise, I would agree.

Yes, I see that Travelin' Man security is definitely the way to go for a corporate pbx. My uses are a little different, so known IP addresses aren't going to work well. Likewise, dynamic DNS updates aren't going to work either.

I'll probably use apf firewall for security. It can't do what Travelin' Man can do, but it does a lot more than iptables can do. Apf monitors the system for suspicious behavior, uses real-time blacklisting, and a lot more. It's probably the best I can do for my project.

 

[wardmundy]

@ajonate: Changing SSH port number works wonders, too. It reduced hack attacks on our public servers by 99.99%.

 

[ajonate]

@ajonate: Changing SSH port number works wonders, too. It reduced hack attacks on our public servers by 99.99%.

Always. I'm running a non-standard ssh port. I see that you already configured a non-standard webmin port.

But honestly, of all the Linux server applications I've worked with over the years I believe that a voip server is the highest risk of all. The consequences of a hacker racking-up a phone bill of tens of thousands is enough to make anyone anal retentive. Fortunately I get connectivity from Google Voice so my exposure is minimal.

 

[piaftnt]

I typically move SSH to an alternate port, disable password authentication and then use SSH public and private key pairs keys for all logins. We typically rotate ssh keys every 3 months or so. The hard part is managing the keys when you have a lot machines but things like Ansible make that a lot easier.

 

[zaphod2012]

Hi,

So I'm kind of stuck, but I expected this. Far too much documentation to keep relevant in this space, so thankfully there are forums.

Observations:

• VOIP is a great concept (and it's here to stay)
  
• Asterisk is the bulkhead of much of the VOIP progress in the past decade++
• PBX in a Flash is quite literally the "I gotta do this quick" method to get into this space, and has evolved into a robust way to do it at much more than a novice level, including bringing things that many would just not have available by doing it in any other means.

There are expressions of gratitude in the above words, to be certain.

That being said, I have been involved for several years in all of the above, but much more in the latter, enjoying the varied benefits of having a community (and a dedicated SME, Ward) to fall back upon in times like this. What would open-source be without the open-access to support? Rhetorical, at least.

So here goes, as I'm quite literally perplexed, perhaps from not having been 'active' before just literally this morning, when I decided to:

USE CASE: Install 13.13 lean onto an existing Linode Centos 7 instance.

The use case (as I played 'business analyst' in a previous life) helps to develop context, expectations and sometimes procedural explanations and relevant "oh, don't do that" kind of responses, which I'm hoping to actually get today.

I am more than happy to delve back into documentation, to brush up my 15+ years of decent *nix skills, and to 'bite the bullet' and get my head around the concepts, intentions, and generalized use cases which I may not have been aware of before pulling the install-it-now.sh trigger, lol.

Questions:

1. Am I right to assume PIAF (specifically, 13.13 lean installer) is designed to work on Centos 7? This thread kind hints to that degree, and I see the work above. I just don't have a link to a specific statement that it is a supported, updated, and relevant use case.
2. Are there caveats that I should be aware of? For example:
   1. I seem to have lost FirewallD. I had lovingly configured this, and sure, I can expect that an installation of a software suite (PIAF) would do modifications to the *existing* rules/configurations, but replacing the subsystem (the firewall control logic package) and basically falling back to iptables, isn't something I noted in any docs so far.
   2. Compounding the above, I had provided sepolicy instructions to create a custom SSH port (as in the above, with guidance from other sources), so that my ssh was indeed pretty tight as a button, and I was loving it. I now cannot SSH into my server. As it's Linode, I have a very crappily performing Glish/Lish, and it's so painful I'm considering nuking from orbit and starting a different way.

^^ this.

Basically, where are the instructions/documentation that would *warn* an eager user about these types of things? In effect, would I need to review the entire install script, it's configurations and delcarations, and/or the thousands of lines of output (which ideally would be logged somewhere)?

I know that PIAF is designed to be 'turn key' - hence the nomenclature and project goals. I get this.

But *where* are the relevant documents that would describe in a Use Case like my own (install linode with C7, update, slightly tweak, then attempt the install script for 13.13 lean) -- which would warn me about these basic things.

Turning the rhetoric down a bit, I have successfully run previous incantations of the project stack, and for all practical purposes, when it works, it works better than anyone could expect for an Open Source, relevant, and useful project.

Thanks Ward, and all, for any follow up to my (borderline) rant about "What just happened to my lovely, basic, secure, Linode?" lol.

Peace.

 

[ajonate]

Am I right to assume PIAF (specifically, 13.13 lean installer) is designed to work on Centos 7?

I haven't fooled with CentOS 7 for awhile now, mainly because C7 doesn't get along with the current fixes for Google Voice. But it should work as a PBX.

I seem to have lost FirewallD.

As I understand it, IncrediblePBX security is based on iptables. My recollection is that FirewallD is either removed or stopped during the IncrediblePBX install to make way for iptables. But there's no reason why iptables can't provide the security you need.

 

[tbrummell]

Use CentOS 6 for a much smoother experience....

root@IncrediblePBX:~ $ cat /etc/redhat-release
Scientific Linux release 6.7 (Carbon)