Can connect to admin UI or SOGo after update

tapp

Hello.
After updating mailcow with the update.sh script, I’ve found out that I can’t connect to the admin UI or SOGo. The https service is not accessible from outside the server.
The command netstat -plnt shows me the following:

netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:19991         0.0.0.0:*               LISTEN      2339/docker-proxy   
tcp        0      0 127.0.0.1:13306         0.0.0.0:*               LISTEN      2482/docker-proxy   
tcp        0      0 127.0.0.1:8443          0.0.0.0:*               LISTEN      1965/docker-proxy   
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      870/httpd           
tcp        0      0 127.0.0.1:7654          0.0.0.0:*               LISTEN      2411/docker-proxy   
tcp        0      0 127.0.0.1:18983         0.0.0.0:*               LISTEN      1740/docker-proxy   
tcp        0      0 0.0.0.0:873             0.0.0.0:*               LISTEN      527/rsync           
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      2099/docker-proxy   
tcp        0      0 0.0.0.0:10000           0.0.0.0:*               LISTEN      1423/perl           
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      870/httpd           
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      869/sshd            
tcp6       0      0 :::25                   :::*                    LISTEN      2596/docker-proxy   
tcp6       0      0 :::9980                 :::*                    LISTEN      1834/docker-proxy   
tcp6       0      0 :::4190                 :::*                    LISTEN      2726/docker-proxy   
tcp6       0      0 :::8000                 :::*                    LISTEN      1766/docker-proxy   
tcp6       0      0 :::993                  :::*                    LISTEN      3299/docker-proxy   
tcp6       0      0 :::995                  :::*                    LISTEN      2839/docker-proxy   
tcp6       0      0 :::9000                 :::*                    LISTEN      1710/docker-proxy   
tcp6       0      0 :::873                  :::*                    LISTEN      527/rsync           
tcp6       0      0 :::23306                :::*                    LISTEN      1181/mariadbd       
tcp6       0      0 :::587                  :::*                    LISTEN      2176/docker-proxy   
tcp6       0      0 :::110                  :::*                    LISTEN      3601/docker-proxy   
tcp6       0      0 :::143                  :::*                    LISTEN      3582/docker-proxy   
tcp6       0      0 :::465                  :::*                    LISTEN      2251/docker-proxy   
tcp6       0      0 :::22                   :::*                    LISTEN      869/sshd

The system is Centos 7 with firewalld. What concerns me (but maybe I’m wrong) is that some containers are exposed to 127.0.0.1. In fact, I see that f.i. the port 8443 is accessible through 127.0.0.1, but not through the IP address assigned to eth0.
It’s not a firewall related issue, because with the firewall stopped, it’s not working. Moreover, the admin UI was working just before the update, so I’m 100% that it’s an issue related to the update.
Apart from this, the server seems to be working, at least I can send and receive email.
Any suggestions?
Thanks for your attention.
Best regards,

p0wer

Docker ps
Shows you which port the Containers listening to
Check that and then try again

tapp

Hi.
Thanks for your reply. Nginx container is listening to 127.0.0.1:8443:
29cbff593131 nginx:mainline-alpine "/docker-entrypoint.…" About an hour ago Up 57 minutes 127.0.0.1:8080->8080/tcp, 80/tcp, 127.0.0.1:8443->8443/tcp mailcowdockerized_nginx-mailcow_1
Best regards,

p0wer

Go to
Mailcow.conf
Correct the settings in the Ports section

tapp

Hello.
Thanks for your reply.
Just modifying mailcow.conf and restarting mailcow is not enough. The same IP address (127.0.0.1) is exposed, although I’ve changed the settings:

HTTP_PORT=8080
HTTP_BIND=0.0.0.0

HTTPS_PORT=8443
HTTPS_BIND=0.0.0.0

And the same IP address is exposed, (127.0.0.1 instead of 0.0.0.0) as docker ps shows:

29cbff593131 nginx:mainline-alpine "/docker-entrypoint.…" 18 hours ago Up 9 hours 127.0.0.1:8080->8080/tcp, 80/tcp, 127.0.0.1:8443->8443/tcp mailcowdockerized_nginx-mailcow_1

I thought that maybe I should reinstall the server, or regenerate the config. I’ve tried to run again generate_config.sh, but I see that it recreates mailcow.conf, so I quitted. My concern is if I would lose all my server’s data and config.
Any suggestions?
Thanks in advance.
Best regards,

p0wer

set up an proxy ?
a nginx to catch 0.0.0.0 80 443 for proxying to 127.0.0.1 8080 8443 ?

tapp

I have set up the following in docker-compose.yml, in the nginx section:

      ports:
#        - "${HTTPS_BIND:-0.0.0.0}:${HTTPS_PORT:-443}:${HTTPS_PORT:-443}"
        - "0.0.0.0:8443:8443"
#        - "${HTTP_BIND:-0.0.0.0}:${HTTP_PORT:-80}:${HTTP_PORT:-80}"
        - "0.0.0.0:8080:8080"

But this is a workaround, not a fix to a possible bug in the upgrade process.
p0wer Your solution would also work, but it’s also a workaround.
Thanks for your attention.

p0wer

If setting the Binding IP directly in .yml works, then maybe docker cannot read the .conf or Something is misspelled. I guess

tapp

Only to clarify things (as I think I’ll stay with my modified docker-compose.yml file), in order to read the variables defined in mailcow.conf, AFAIK there should be any env_file option in docker-compose.yml referencing mailcow.conf.
Well, in my docker-composer.yml there’s no such option, so I think it won’t be able to read the variables set in mailcow.conf.
I don’t have any backup of docker-compose.yml previous to the update (big mistake by my side), so I can’t check if there were such option in the old docker-compose.yml file (the previous to the update).

MAGIC

Can you do a ls -lah in your mailcow folder? There should be a .env file which is linked to mailcow.conf

tapp

MAGIC Yes, that file exists

MAGIC

But is it linked to mailcow.conf?
If you are not sure if so, you can do a screenshot

tapp

Sorry MAGIC here it is:

ls -alh
total 430M
drwxr-xr-x  7 root root 4,0K ago  6 19:16 .
drwxr-xr-x. 5 root root 4,0K jul  9 14:53 ..
-rw-r--r--  1 root root 3,2K jul  9 12:18 CODE_OF_CONDUCT.md
-rw-r--r--  1 root root  954 jul  9 12:18 CONTRIBUTING.md
drwxr-xr-x  7 root root 4,0K jul  9 12:18 data
-rw-r--r--  1 root root  19K ago  6 19:16 docker-compose.yml
-rw-r--r--  1 root root  19K jul 31 22:14 docker-compose.yml.200731
-rw-r--r--  1 root root 2,3K jul  9 12:18 .drone.yml
-rw-r--r--  1 root root  414 jul  9 12:18 .editorconfig
lrwxrwxrwx  1 root root   12 jul  9 12:18 .env -> mailcow.conf
-rwxr-xr-x  1 root root 9,3K jul 31 15:46 generate_config.sh
drwxr-xr-x  8 root root 4,0K ago  6 19:16 .git
drwxr-xr-x  3 root root 4,0K jul  9 12:18 .github
-rw-r--r--  1 root root 1,5K jul 31 15:46 .gitignore
drwxr-xr-x  3 root root 4,0K jul  9 12:18 helper-scripts
-rw-r--r--  1 root root  35K jul  9 12:18 LICENSE
-rw-r--r--  1 root root 405M jul 30 22:17 logs
-rw-r--r--  1 root root  26M ago  4 16:52 logs.au
-rw-------  1 root root 5,6K ago  6 19:16 mailcow.conf
-rw-------  1 root root 5,6K jul 31 22:03 mailcow.conf.200731
-rw-------  1 root root 5,6K jul 31 22:04 mailcow.conf_backup
-rw-r--r--  1 root root 1,3K jul  9 12:18 README.md
-rw-r--r--  1 root root 1,8K jul  9 12:18 .travis.yml
drwxr-xr-x  2 root root 4,0K ago  6 19:15 update_diffs
-rwxr-xr-x  1 root root  23K ago  6 19:15 update.sh

Thanks for your attention.

MAGIC

Hm weird, I wonder why the variables are not working then…

diekuh

There does not need to be such a file and the variables are read just fine in a default installation.

If you change things in mailcow, expect errors to happen. We cannot support that.

And yes, it works absolutly fine in mailcow. Don’t you think someone would have noticed if the variables were ignored? 🙂

tapp

diekuh

There does not need to be such a file and the variables are read just fine in a default installation.

Yes, I think so, that’s was why I posted this discussion, in case there’s a bug in the update process.

If you change things in mailcow, expect errors to happen. We cannot support that.

The change was a workaround to be able to connect to the admin UI. I’m planning to migrate mailcow to a fresh server, because I think that something broke mailcow.

And yes, it works absolutly fine in mailcow. Don’t you think someone would have noticed if the variables were ignored?

Of course I know that this should work. Anyway, I don’t see the point of your question. I wrote this post because I had some problem, and after investigating some time, I wasn’t able to fix it. Do you think I was bored at home and decided to write this post to spend some spare time?

As I told previously, I’m going to migrate mailcow to a new server, because I’m also having another issue, and I think that something else (firewalld? ) broke my system.

Thanks for your attention and your time.
Best regards.