Miltiserver, and, Database connection failed

Discussion in 'Installation/Configuration' started by GeorgeG, Mar 20, 2024.

  1. GeorgeG

    GeorgeG New Member

    Hi All,

    I am facing a bit of an issue with a multiserver installation that I am trying to upgrade.

    Starting from (across all servers):
    - Ubuntu 18.04.6 LTS (Bionic Beaver) & ISPConfig 3.2.9p1
    - MariaDB 10.4.31 (where applicable)

    I started by upgrading the OS first, with the plan to perform the ISP config installation once everything is done.
    However we kind of hit a wall so we cannot proceed.
    The current state of play is:
    1 Web Server (master)
    (Ubuntu 22.04.3 LTS (Jammy Jellyfish)) ISPConfig 3.2.9p1
    MariaDB 10.6.16

    The slave servers are as follows:
    1 DB Server (Ubuntu 18.04.6 LTS (Bionic Beaver)) ISPConfig 3.2.9p1
    MariaDB 10.4.31
    This is the only server that is set to host databases through the control panel.

    1 Web Server (Ubuntu 18.04.6 LTS (Bionic Beaver)) ISPConfig 3.2.9p1
    MariaDB 10.4.31

    2 Name Servers (Ubuntu 22.04.3 LTS (Jammy Jellyfish)) ISPConfig 3.2.9p1
    MariaDB 10.6.16

    1 Mail server (Ubuntu 22.04.3 LTS (Jammy Jellyfish)) ISPConfig 3.2.9p1
    MariaDB 10.6.16

    All elements are fully functional from the front end.
    Websites working fine. DNS responds as expected. Mail server receives and delivers email as normal.

    We had to postpone the upgrade (reasons not relevant), and now when I tried to reset a user's password from the control panel, "nothing happens".
    By "nothing happens" I mean that the red notification at the top stays at (2).
    When I looked at the logs of the master server there is nothing to report.
    When I looked at the logs of the slave servers, in all cases the same entry is logged multiple times:
    "Database connection failed ... Call to a member function testConnection() ... /usr/local/ispconfig/server/server.php:64"

    I guess... this means that ISPConfig servers are not really "speaking" to each other as expected.
    Note, skip-name-resolve is not enabled in any of the master/slave DBs

    I have the feeling that this may relate to the way passwords are hashed by MariaDB (google searches suggest that a relevant change took place at some point with MariaDB), however I am not sure how to proceed if this is the case.

    Ideally I would like to get the servers talking to each other again before I proceed with the rest of the updates (or rather breaking them any further).

    Any pointers welcome!

    Thanks in advance,
    G.

    p.s.: Edited some typos, but could not correct the subject (duh)
     
    Last edited: Mar 20, 2024
  2. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

  3. GeorgeG

    GeorgeG New Member

    Hi All,
    I think I found the issue.
    The slave servers could not speak to the master server DB because... the MariaDB configuration had the entry:
    bind-address = 127.0.0.1
    Once the setting was commented out, all the queued jobs went through just fine!
    Now I have the issue with ufw...
    I implemented what is described in https://www.howtoforge.com/tutorial...setup-debian-ubuntu/#-setting-up-the-firewall
    But the slaves stop working again.

    Anyway, I consider this solved. The firewall issue is a separate one, and I shall post something after I crawl through the search results.

    Thanks,
    G.
     
    Th0m likes this.

Share This Page