TIPS Incredible PBX installer breaks deployed CentOS 7 systems

[litebit]

Hi,

it seems that the installerscript
./IncrediblePBX2020.sh
breaks my Lan deployed Centos 7 machine(s)
1/
Amongst others, by overwriting and locking the resolv.conf. Once it does that, nothing towards internet works anymore on the machine (as it needs to pass via a preset order of DNS servers, and not Google DNS), as well as monitoring and management (OS level) of the machine.

Why the forced use of Google DNS? Why not allowing the use of either proper internal DNS servers, or even alternatives to Google like the Cloudflare DNS ?



Thanks,

 

[markieb]

I was kind of wondering this myself?

Incidentally, found this HERE and this HERE which may help you

 

[wardmundy]

Just to repeat, the reason for the lock was because some cloud providers were trashing DNS. It's easy enough to fix to meet your local requirements.

cd /etc
chattr -i resolv.conf
# then set it any way you like and reboot
nano -w resolv.conf

For the record, Incredible PBX 2020 is designed to run on a dedicated CentOS 7 platform and setting DNS to a publicly available DNS server should never "break" Internet connectivity unless you've deployed CentOS 7 behind a router in a non-standard way that blocks certain outbound network traffic.

 

[litebit]

The reason for the lock is because some cloud providers were trashing DNS. It's easy enough to fix.

cd /etc
chattr -i resolv.conf
# then set it any way you like and reboot
nano -w resolv.conf

I had to remove it from the installscript so it does not change in the first place. Because it also breaks the install script, as the Google DNS are not available here, so the rest of the installscript will be unable to do any further downloads.

As a suggestion, if you want to lock it down, maybe add more options (Google DNS, Cloudflare, OpenDNS) in additiona (in front of) the resolvers already present. That way it should not break things.

I just found out it also overwrites the hostname with noreply.incrediblepbx.com
What is the reason for that? Because that breaks things again.

 

[wardmundy]

The hostname is hard-coded to support outbound email traffic with SendMail which requires a working FQDN. If you prefer a different resolvable FQDN, that's perfectly fine. Change it.

As noted above, the Incredible PBX design requires Internet connectivity and assumes no blockage of outbound network traffic.

We've been offering PBX in a Flash and Incredible PBX servers for more than a decade, and I believe you are the first complaint we've had suggesting that use of a public DNS server or fully-resolvable FQDN broke things. Sorry, but this may not be the right product with your special network design.

 

[litebit]

Regarding the DNS, I may be the first who complains about it here, but it is dangerous to assume that Google DNS is always reachable. So there I would suggest to at least add one more option.

 

[krzykat]

Set your DNS however you like. Everyone can do how they like, but I prefer to use google's DNS as well as my own DNS server that hosts my FQDN's. FQDN is another mandatory for me. To have a public facing server and to keep the undesirables out, get your FQDN (and even Let's Encrypt) - and you can have a nice solid system.

 

[wardmundy]

I think the bottom line is we try to build an aggregation where everything will work for almost everybody out of the box without having to learn anything about DNS, FQDNs, email routing, and Linux in general. The real beauty of OPEN SOURCE code is that none of this is set in stone and anyone can tweak the installer or their configuration in any way they like to meet individual needs.

With literally hundreds of thousands of implementations, this really is the first time I've heard of a server that couldn't use Google's DNS servers. We will look at providing other options down the road, but I think it's fair to say this is an edge case, and that's being charitable. Once folks have to choose DNS servers, the level of complexity for novices goes up considerably but we will give it some thought.

 

[litebit]

To include some automation for DNS server selection, you could include something like this in the script :

#!/bin/bash
DNSTEST="untested"
DNSFOUND=0
declare -a dnservers=("8.8.8.8" "8.8.4.4" "1.1.1.1" "1.0.0.1" "208.67.222.123" "208.67.220.123")
echo "## Generated by Incredible PBX install script" > /etc/resolv.conf
for i in "${dnservers[@]}"
do
    echo "DEBUG: Testing $i"
    TESTDNS=`dig +short @$i www.google.com`
    echo "DEBUG: Result for $i : $TESTDNS"
    if [[ ! "$TESTDNS" == *"no servers could be reached" ]]; then
        DNSFOUND=$((DNSFOUND+1))
        echo "nameserver $i" >> /etc/resolv.conf
    fi
    if [[ "$DNSFOUND" -eq 2 ]]; then
        echo "Found 2 active DNS servers, all done"
        break
    fi
done

I've heard similar comments from others in the field when software hardcodes Google DNS only. I guess we normally don't complain, as we can solve these things ourselves, which I did here also.
In my case, I was not complaining, just questioning the "why".
Restricting Google DNS can have many reasons, many are security related.

Anyway, that is a different discussion. I've got my answer, I made a suggestion for improvement.
So we don't need to keep the discussion going.