After successfully installing the latest Distro, I have been migrating the PBX settings across. This went reasonably well, apart from a few glitches.
However, yesterday I installed a cloud backup solution called SpiderOakOne which is an rsync type of service which can run headless when called by CRON from a user account. For security, I created a new ‘backup’ User and set Read and Execute ACL permissions on all the folders that I wished to back up, for the “backup” user only. To do this I used the command:
setfacl -R -m u:"backup":rX /etc .
To ensure that new files and directories will have proper rights too, I also used the set the default ACL:
setfacl -R -m d:u:"backup":rX /etc
…then did the same again for /home, /root and /usr and /var, which were the other folders I chose to backup.
So far so good… The backup works and I can monitor the backup state remotely from a graphical client on my laptop.
At this point I then decided to download and install GNOME and TigerVNC, according to these instructions (but not the firewall) which provided some neat GUI admin tools plus I could use the GUI version of the SpiderOakONE control panel on the linux box itself.
I also installed phpMyAdmin, to give me better control of the database for a later job of adding Postfix user tables.
I should mention that everything went well during and after installation and without I was able to VNC into the client using my VPN connection, keeping the GUI nice and secure.
…UNTIL, that is, I rebooted the machine.
When I did so, I was immediately confronted with the dreaded MYSQL Connection Error. No Firewall started, and no amount of fwconsole chown and fwconsole restart would fix the problem. Eventually I just had to shut the whole thing down, rather than leave it exposed to the interwebs.
It has taken me nearly all day to figure out what has happened. I have uninstalled GNOME and TigerVNC and even removed the ACLs from key file locations such as /var/lib/mysql. I spent most of the day playing with file permissions, ensuring that “asterisk” has rights to the mysql socket, changing Database Passwords all to no avail. The fact was that as the ‘root’ user, I could log into the MySQL prompt using the “freepbxuser” username and password:
#mysql -u freepbxuser -p
Password:
However, if I switched to the ‘asterisk’ user #su asterisk, then the login was unceremoniously rejected by MariaDB.
Eventually, the solution was to add a new host ‘127.0.0.1’ to the asterisk user in the mysql ‘user’ table, and modify the /etc/freepbx.conf file to change “AMPDBHOST” from “localhost” to “127.0.0.1”:
<?php
// This file was generated at 2018-06-22T06:36:31+00:00
$amp_conf["AMPDBUSER"] = "freepbxuser";
$amp_conf["AMPDBPASS"] = "xxxx";
$amp_conf["AMPDBHOST"] = "localhost";
$amp_conf["AMPDBNAME"] = "asterisk";
$amp_conf["AMPDBENGINE"] = "mysql";
$amp_conf["datasource"] = "";
require_once "/var/www/html/admin/bootstrap.php";
?>
to:
<?php
// This file was generated at 2018-06-22T06:36:31+00:00
$amp_conf["AMPDBUSER"] = "freepbxuser";
$amp_conf["AMPDBPASS"] = "xxxx";
$amp_conf["AMPDBHOST"] = "127.0.0.1";
$amp_conf["AMPDBNAME"] = "asterisk";
$amp_conf["AMPDBENGINE"] = "mysql";
$amp_conf["datasource"] = "";
require_once "/var/www/html/admin/bootstrap.php";
?>
This being done, everything started working normally again.
I then found a similar issue plagued phpMyAdmin. All logins were prevented and the solution was to modify the /etc/phpMyAdmin/config.inc.php file from:
$cfg['Servers'][$i]['host'] = 'localhost'; // MySQL hostname or IP address
to
$cfg['Servers'][$i]['host'] = 'mydomain.co.uk'; // MySQL hostname or IP address
Note that in this case 127.0.0.1 did not work either.
Now, I know this all points to an issue with the /etc/hosts file, but I cannot see anything wrong with it.
/etc/hosts:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 mydomain.co.uk
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
The IP6 line is deliberately commented out, as part of my troubleshooting because there was a report that the IP6 address was causing this kind of error… a bug which was apparently patched in MySQL but not in the MariaDB, which I am using. Even so, this did not bring back the name resolution for localhost.
It seems that localhost is not being resolved by any user other than ‘root’, so any other user needs to use an alternative such as the local IP address or the machine global hostname.
I have beaten myself up considerably for breaking this, I just don’t understand how… whether it was messing around with setfacl, or installing Gnome or what…
Any insight would be gratefully received, because all I have done is to find a workaround by using alternative hostnames, which not a solution to the underlying issue.
Kind regards
Andy