iRedMail blocking Mattermost sites

What does green-rainbow.party resolve to for you? For me, it’s 86.38.217.68

I would remove it from DataSource and replace it with 127.0.0.1

John, I changed 127.0.1.1 to ‘localhost’: then systemctl start mattemost.service returned no errors.
But browsing to neither (IP#s):8065 nor to green-rainbow.party:8065 works.
Thanks for your attention to this.
I also put my home ip#, from which I ssh, into the ignore list of fail2ban.
I can get to https://green-rainbow.party/mail/ successfully, but not https://green-rainbow.party:8065

So, sudo systemctl status mattermost.service shows the service is running with no errors?

What is ListenAddress and SiteURL in config.json?

What IP address(es) does your host have? If you have a browser on that host, can you http://127.0.0.1:8065 and get a response? From another host on the same segment, can you http://<ip.address>:8065 where ip.address is your Ethernet or wifi intefrace?

Open up two terminals. In one, sudo systemctl stop mattermost.service In the other, tail -f /opt/mattermost/logs/mattermost.log Hit enter a few times to open up some white space. In the first, sudo systemctl start mattermost.service Watch what goes by in the second terminal. Look for errors.

Hi John,
“SiteURL”: “https://green-rainbow.party”,
“ListenAddress”: “:8065”,
I think I can not browse through this ssh on the VPS, but I can now curl (VPS IP#):8065 and get some html that looks to be mattermost login page.
In my home machine browser (VPS IP#):8065 times out, while (VPS IP#)/mattermost brings up a 404 page.

I did the two windows thing: The only thing looking like an error is a warn…
{“timestamp”:“2024-03-28 20:16:24.198 Z”,“level”:“warn”,“msg”:“failed to get public IP address for local interface”,“caller”:“app/plugin_api.go:1006”,“plugin_id”:“com.mattermost.calls”,“origin”:“main.(*logger).Warn log.go:108”,“localAddr”:“127.0.0.1”,“error”:“failed to get public address: write udp4 127.0.0.1:8443->52.72.139.62:3478: sendto: invalid argument”}
{“timestamp”:“2024-03-28 20:16:24.262 Z”,“level”:“info”,“msg”:“got public IP address for local interface”,“caller”:“app/plugin_api.go:1000”,“plugin_id”:“com.mattermost.calls”,“origin”:“main.(*logger).Info log.go:104”,“localAddr”:“86.38.217.68”,“remoteAddr”:“86.38.217.68”}

Correction: On shutdown, a plugin failed to behave.
{“timestamp”:“2024-03-28 20:15:43.205 Z”,“level”:“info”,“msg”:“Shutting down plugins”,“caller”:“app/plugin.go:389”}
{“timestamp”:“2024-03-28 20:15:43.206 Z”,“level”:“error”,“msg”:“RPC call OnDeactivate to plugin failed.”,“caller”:“plugin/client_rpc_generated.go:33”,“plugin_id”:“com.mattermost.nps”,“error”:“connection is shut down”}
{“timestamp”:“2024-03-28 20:15:43.206 Z”,“level”:“warn”,“msg”:“error closing client during Kill”,“caller”:“plugin/hclog_adapter.go:70”,“plugin_id”:“com.mattermost.nps”,“wrapped_extras”:“errconnection is shut down”}
{“timestamp”:“2024-03-28 20:15:43.206 Z”,“level”:“warn”,“msg”:“plugin failed to exit gracefully”,“caller”:“plugin/hclog_adapter.go:72”,“plugin_id”:“com.mattermost.nps”}
{“timestamp”:“2024-03-28 20:15:43.206 Z”,“level”:“error”,“msg”:“RPC call OnDeactivate to plugin failed.”,“caller”:“plugin/client_rpc_generated.go:33”,“plugin_id”:“com.mattermost.calls”,“error”:“connection is shut down”}
{“timestamp”:“2024-03-28 20:15:43.206 Z”,“level”:“warn”,“msg”:“error closing client during Kill”,“caller”:“plugin/hclog_adapter.go:70”,“plugin_id”:“com.mattermost.calls”,“wrapped_extras”:“errconnection is shut down”}
{“timestamp”:“2024-03-28 20:15:43.206 Z”,“level”:“warn”,“msg”:“plugin failed to exit gracefully”,“caller”:“plugin/hclog_adapter.go:72”,“plugin_id”:“com.mattermost.calls”}
{“timestamp”:“2024-03-28 20:15:43.206 Z”,“level”:“warn”,“msg”:“error closing client during Kill”,“caller”:“plugin/hclog_adapter.go:70”,“plugin_id”:“playbooks”,“wrapped_extras”:“errconnection is shut down”}
{“timestamp”:“2024-03-28 20:15:43.206 Z”,“level”:“warn”,“msg”:“plugin failed to exit gracefully”,“caller”:“plugin/hclog_adapter.go:72”,“plugin_id”:“playbooks”}
{“timestamp”:“2024-03-28 20:15:43.207 Z”,“level”:“info”,“msg”:“stopping websocket hub connections”,“caller”:“platform/web_hub.go:120”}
{“timestamp”:“2024-03-28 20:15:43.212 Z”,“level”:“info”,“msg”:“Server stopped”,“caller”:“app/server.go:786”}

What is the output of ip link sh and ip a?

root@green-rainbow:/opt/mattermost/config# ip link sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 0a:56:0d:da:9f:2f brd ff:ff:ff:ff:ff:ff
root@green-rainbow:/opt/mattermost/config# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 0a:56:0d:da:9f:2f brd ff:ff:ff:ff:ff:ff
inet 86.38.217.68/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 2a02:4780:10:e50c::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::856:dff:feda:9f2f/64 scope link
valid_lft forever preferred_lft forever

You mentioned VPS (Virtual Private Server?) There has to be some layer of abstraction between your VM and the Internet. 443 and 80 are showing as open but with no valid cert. 8065 doesn’t show as open at all. All I can think, either there’s hypervisor networking, or a firewall, or some kind of load balancer or something in front of your VM.

I would get the simplest possible setup going. Two VMs with no weird networking, no firewalls, nothing impeding traffic. get Mattermost started and running without error, where you can curl http://127.0.0,1:8065 and get a response. then be able to hit 8065 via curl or browser from the other VM. Then start worrying about firewalls or whatever.

John, I appreciate your taking this time. I’m reluctant to leave anything without a firewall open for any period of time. The Hostinger firewall has 443, 80 open, as well as a few more. I have yet to get a cert from let’sencrypt this time - that’s the next step after getting mattermost running. Your last note got me to notice that 8065 wasn’t open yet - I opened it. It still times out going from 75.68.204.180 to: https://86.38.217.68:8065/
I have curled 127.0.0.1:8065 and get what looks like a mattermost page - that’s done.
This may now be not a mattermost question, but a nginx/debian/html one, I understand.
I don’t see how to make things simpler - I have just one Virtual Private Server. Two VMs seem to me to add complexity.
I’ve gotten mattermost working by itself. What’s difficult is integrating iRedMail and Mattermost. But this is potentially valuable: iRedMail provides sophisticated spam and virus control; Spam Assassin, fresh clam, and such. Mattermost competes with slack, and extensions offer full email participation, through Mailermost. If we can figure this out, and write it up as a through step-by-step configuration guide, with steps and tests to show that each step was successfully completed, it could be a boon to both. I think we are nearly there. I expect that the next step is conferring with nginx and debian docs and forums.

At least now I can see that 8065 is available, but still filtered:

sudo nmap -p 8065 86.38.217.68
Starting Nmap 7.80 ( https://nmap.org ) at 2024-03-28 19:24 CDT
Nmap scan report for 86.38.217.68
Host is up (0.056s latency).

PORT     STATE    SERVICE
8065/tcp filtered unknown

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

I stopped the fail2ban server: I got the same result you did with nmap.

“Filtered” usually means a firewall. There may be a firewall not on your host but in front of it. I would test by temporarily disabling the firewall on your host. Maybe check system logs for something like SELinux or AppArmor or fapolicy issues.