| SYSTEM INFORMATION|
| PHP 7.4.3-|
Trying to use a MariaDB10 instance on a Synology DSM7 box, now Virtual Servers on Virtualmin will not communicate with the Synology Box on the same C Subnet LAN segment.
I originally migrated 7 Websites to an internal Virtualmin installation from a HostUpon Server at YE 2021 and used a LAN based Synology box for the Database server without a problem. Then about a month ago I moved all of the websites to a fresh install ot Virtualmin on Ubuntu 20.04.2 … which updated to version 20.04.5 since then … now I have noticed that the Websites on the ‘new’ Virtualmin server are unable to communicate with the Synology Box on the same LAN segment using the same C Subnet.
I cannot remember what I changed on the original Virtualmin installation to cause it to NOT use the internal MySQL server but the External MariaDB10 Snyology … but it worked for several months.
Can anyone point me to some documentation that will help me understand how to make this work again.
The PHP Scripts have not changed since they worked last … just the Linux OS andVirtualmin updates. And probably my configuration settings. I have wiped out the older working Virtualmin installation and installed Ubuntu 22.04 in order to prepare for the next Server move so I cannot revisit that configuration to see what is different. There seems to be only the Internal MySQL server available to the Domains on the Virtualmin server, I have not been able to add an external DB Server for them to access yet.
I tried to add a ‘remote Database server’ to the Virtualmin page System Settings → Database Servers … but that page will not accept the LAN Name of the Server (error = invalid hostname) or it’s IP Address (error = must be hostname, not an IP Address)
I think, but am not sure that I had disabled the internal MySQL on the instance of Virtualmin that was working with the External Database server a few months ago … but I don’t want to just keep guessing.
Is there an explanation of how to do this that I can read, instead of blundering around until I stumble upon how to make it work?
Why not fix this?
Obviously if you can’t add the database, you can’t use it. So, make the name resolve (either via DNS or adding it to hosts file).
Thank you, Joe … this is a good idea and I did try it to see if it gets me closer to making it work again.
For now … I did add an entry into the hosts file … but still got an error. This time the clue seems to indicate a possible firewall issue.
new error message after adding DB Server IP to hosts file:
Failed to add database server : Connection failed : DBI connect failed : Lost connection to MySQL server at ‘reading initial communication packet’, system error: 22
I regard the server with this particular problem as ‘live’ and want to avoid experimenting with it. I think that I managed to create this problem because of my incomplete understanding of what Virtualmin does and how it works. I most likely made a bad guess when installing it. I am very impressed with Virtualmin and do want to make much better use of it. I will allocate another server to experiment with and hopefully learn more about Virtualmin … later, probably after YE. I haven’t figured out how to deal with the problem of SSL certificates for a ‘Test Server’ not accessible through a Public IP address yet.
Yeah, that could be firewall. Could also be that the server you’re trying to connect to simply isn’t listening on the IP:port you’re trying to connect on.
The local firewall (the one on the Virtualmin server) has no impact on this. Outgoing connections are not filtered in a default configuration.
Start with basic network troubleshooting. Can you ping the database server from the Virtualmin server? Does
nmap show an open MySQL port? Can you connect to it with the
mysql CLI client?
Any of those fail, and you know it’s nothing to do with Virtualmin configuration. It can never work if you simply don’t have connectivity, no matter how you configure Virtualmin.
Extremely doubtful. I mean, you may have made a bad guess, but there are only a tiny number of decisions you can make during installation and none would alter how Virtualmin connects to other systems for MySQL.
Generate them on a server with a public IP, and copy them to the private dev server. Or purchase a traditional cert, which may validate ownership differently.
External MariaDB 10 server now working with Virtualmin. I think this problem was my mistake when migrating initial Virtualmin Hardware system to current Hardware system.
Original installation had only 1 active LAN interface and worked. There is no WAN IP used by either of the Virtualmin configurations. Current system has 4 LAN IPs, 1 Static and 3 DHCP. DHCP server is a PFSense router which manages the WAN interace. Virtualmin automatic install assigned Static IP address as default for Shared Servers. I changed the default IP assignment to one of the DHCP assigned IPs and set PFSense to use reserved IPs for the Virtualmin server. I think this is what caused the problem.
DB server had only 1 active IP on the the C-Subnet as the Virtualmin Static IP … and it did work with original Virtualmin instllation as well as several other systems.
But, for some reason that I do not yet understand the Virtualmin Virtual Servers used ONLY the default IP for PHP scripts within those Virtual System hosted Domain Names.
When I added a 2nd LAN interface to the DB Server and assigned it an IP within the C-Subnet of the default IP (not the Static IP) for the Virtualmin Virtual servers all of the PHP Scripts within the Domains hosted on the Virtualmin server were once again able to use the external DB Server.
Throughout all of this my PCs on the same C-Subnet as the static IP on the current Virtualmin system and the DB Server were able to use port 10000 on the Virtualmin Server as well as PHPMyAdmin on the DB Server, it was only the PHP Scripts within the Domains on the Current Virtualmin server that were unable to communicate with the DB Server on the ‘non-default’ IP address for the Virtualmin Virtual Servers.
I learned something … that others might benefit from. I hope this helps someone else.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.