Any way to avoid ping test on remote DB?

Troubleshooting
1

I’m installing Mattermost on Debian 10 and using MySQL on a remote server with filtered ports, so ping wouldn’t be allowed even for open doors. I’m not the DB admin - these instances are managed by the hosting provider.

It’s not a limitation tho; I have been using these host-managed databases on other self-hosted services in some of my VPS (which are from the very same provider - it’s Greenhost if it rings any bell). It’s been not long since the last time I used them on homologation by the way. So this doesn’t have nothing to do with the actual connection being made, but the ping test before that, I suppose?

I could run a local instance just for that (as in Posgres New Install on Ubuntu 20.04 - Failed to Ping DB - #5 by XxLilBoPeepsxX), however it would be better for security, management and replication purposes to keep my database away from the Mattermost host server.

Datasource entry should be like:

"DataSource": "mysql://******@213.*.*.*:*************@tcp(213.*.*.*:3306)/self_generated_db_name?charset=utf8mb4,utf8\u0026sslmode=disable\u0026connect_timeout=10"

Console and log are already on debug level and they show no more than this:

{"level":"info","ts":1621363217.4548242,"caller":"app/server.go:245","msg":"Server is initializing...","go_version":"go1.15.5"}
{"level":"info","ts":1621363217.4550266,"caller":"app/web_hub.go:83","msg":"Starting websocket hubs","number_of_hubs":4}
{"level":"debug","ts":1621363217.4623725,"caller":"app/web_hub.go:388","msg":"Hub is starting","index":0}
{"level":"debug","ts":1621363217.4623973,"caller":"app/web_hub.go:388","msg":"Hub is starting","index":1}
{"level":"debug","ts":1621363217.4624314,"caller":"app/web_hub.go:388","msg":"Hub is starting","index":2}
{"level":"debug","ts":1621363217.462482,"caller":"app/web_hub.go:388","msg":"Hub is starting","index":3}
{"level":"info","ts":1621363217.4652076,"caller":"i18n/i18n.go:93","msg":"Loaded system translations","for locale":"en","from locale":"/srv/mattermost/i18n/en.json"}
{"level":"info","ts":1621363217.471392,"caller":"sqlstore/store.go:282","msg":"Pinging SQL","database":"master"}
{"level":"error","ts":1621363227.471789,"caller":"sqlstore/store.go:294","msg":"Failed to ping DB","error":"dial tcp 213.*.*.*:3306: i/o timeout","retrying in seconds":10}
{"level":"info","ts":1621363237.4720788,"caller":"sqlstore/store.go:282","msg":"Pinging SQL","database":"master"}
{"level":"error","ts":1621363247.4725316,"caller":"sqlstore/store.go:294","msg":"Failed to ping DB","error":"dial tcp 213.*.*.*:3306: i/o timeout","retrying in seconds":10}
{"level":"info","ts":1621363257.4728866,"caller":"sqlstore/store.go:282","msg":"Pinging SQL","database":"master"}
{"level":"error","ts":1621363267.4732037,"caller":"sqlstore/store.go:294","msg":"Failed to ping DB","error":"dial tcp 213.*.*.*:3306: i/o timeout","retrying in seconds":10}
{"level":"info","ts":1621363277.4734955,"caller":"sqlstore/store.go:282","msg":"Pinging SQL","database":"master"}

nmap -Pn on the db server:
nmap -Pn 213...*
Host discovery disabled (-Pn). All addresses will be marked ‘up’ and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-05-18 15:29 -03
Nmap scan report for _.greenhost.nl (213...)
Host is up.
All 1000 scanned ports on _.greenhost.nl (213...) are filtered

Nmap done: 1 IP address (1 host up) scanned in 202.46 seconds

I appreciate any thoughts on this (and if a local instance is the only way, I’ll just let it be)

2

Could I perhaps have the full IP address of your remote database? I work as a system administrator and cybersecurity consultant, so I have lots of experience with this type of thing.

It appears to me, given that your nmap scan is saying that all ports are filtered, that the database is configured to only make connections on localhost and not listen to external connection requests.

On that note, I’m curious to scan it myself using nmap and a few other tools I have, to determine if that’s the case. Either way, if the database truly isn’t accepting external connections, we can still work around that by setting up a reverse proxy through Apache that will essentially proxy port 3306 to a domain name, and then instead of using an IP address and port, you could just specify in your Mattermost configuration an HTTP or HTTPS URL and the corresponding port, and send the data that way, since the Apache reverse proxy would then send the data to and from ports 80 or 443, depending on the configuration, to the internal database port 3306.