search

mailcow / mailcow-dockerized

mailcow: dockerized - 🐮 + 🐋 = 💕
https://mailcow.email
GNU General Public License v3.0
9.1k stars 1.19k forks source link

whitelist_forwardinghosts.sh error #229

Closed discofris closed 7 years ago

discofris commented 7 years ago

Could anyone explain what this means?

postfix-mailcow_1    | May  1 06:13:38 mail postfix/postscreen[1222]: CONNECT from [107.150.43.203]:46404 to [172.22.1.6]:25

postfix-mailcow_1    | May  1 06:13:38 mail spawn[1227]: fatal: spawn_comand: execvp /usr/local/bin/whitelist_forwardinghosts.sh: No such file or directory

postfix-mailcow_1    | May  1 06:13:39 mail postfix/spawn[1224]: warning: command /usr/local/bin/whitelist_forwardinghosts.sh exit status 1

postfix-mailcow_1    | May  1 06:13:39 mail postfix/postscreen[1222]: warning: read TCP map reply from 127.0.0.1:10027: unexpected EOF (Connection reset by peer)

postfix-mailcow_1    | May  1 06:13:40 mail spawn[1228]: fatal: spawn_comand: execvp /usr/local/bin/whitelist_forwardinghosts.sh: No such file or directory

postfix-mailcow_1    | May  1 06:13:41 mail postfix/spawn[1224]: warning: command /usr/local/bin/whitelist_forwardinghosts.sh exit status 1

postfix-mailcow_1    | May  1 06:13:41 mail postfix/postscreen[1222]: warning: read TCP map reply from 127.0.0.1:10027: unexpected EOF (Connection reset by peer)

postfix-mailcow_1    | May  1 06:13:42 mail spawn[1229]: fatal: spawn_comand: execvp /usr/local/bin/whitelist_forwardinghosts.sh: No such file or directory

postfix-mailcow_1    | May  1 06:13:43 mail postfix/spawn[1224]: warning: command /usr/local/bin/whitelist_forwardinghosts.sh exit status 1

postfix-mailcow_1    | May  1 06:13:43 mail postfix/postscreen[1222]: warning: read TCP map reply from 127.0.0.1:10027: unexpected EOF (Connection reset by peer)

postfix-mailcow_1    | May  1 06:13:44 mail spawn[1230]: fatal: spawn_comand: execvp /usr/local/bin/whitelist_forwardinghosts.sh: No such file or directory

postfix-mailcow_1    | May  1 06:13:45 mail postfix/spawn[1224]: warning: command /usr/local/bin/whitelist_forwardinghosts.sh exit status 1

postfix-mailcow_1    | May  1 06:13:45 mail postfix/postscreen[1222]: warning: read TCP map reply from 127.0.0.1:10027: unexpected EOF (Connection reset by peer)

postfix-mailcow_1    | May  1 06:13:46 mail spawn[1231]: fatal: spawn_comand: execvp /usr/local/bin/whitelist_forwardinghosts.sh: No such file or directory

postfix-mailcow_1    | May  1 06:13:47 mail postfix/postscreen[1222]: fatal: watchdog timeout

postfix-mailcow_1    | May  1 06:13:47 mail postfix/spawn[1224]: warning: command /usr/local/bin/whitelist_forwardinghosts.sh exit status 1

postfix-mailcow_1    | May  1 06:13:48 mail postfix/master[317]: warning: process /usr/lib/postfix/sbin/postscreen pid 1222 exit status 1

postfix-mailcow_1    | May  1 06:13:48 mail postfix/master[317]: warning: /usr/lib/postfix/sbin/postscreen: bad command startup -- throttling

I did an upgrade yesterday ... I'm having the feeling this blocks some incoming emails ... Every hint is welcome :-)

mkuron commented 7 years ago

Did you do docker-compose pull after the git pull? Sounds like yout Postfix container is outdated.

mkuron commented 7 years ago

Actually, it looks like @andryyy never pushed the updated Postfix container to Docker Hub. It would be great if he could just set up automatic builds, then issues like this would never happen.

@discofris, as a workaround you can do docker-compose build.

andryyy commented 7 years ago

Pushed the image now!

Automatic builds are disabled to not build all images after every push to master (like minor fixes to data/web).

mkuron commented 7 years ago

Automatic builds are disabled to not build all images after every push to master (like minor fixes to data/web).

@andryyy, Docker Hub has sufficient capacities to build all Mailcow images multiple times a day (especially considering that most of your containers take less than a minute to build), even if this is not always needed. Typically you only push to master once or twice a day, so there won't be a whole lot of wasted builds. Just don't set up automatic builds for the dev branch. Most projects use Docker Hub's automatic builds and don't even bother with reducing unnecessary builds.

Automatic builds add a lot of convenience to the deployment process, so why not use them?

andryyy commented 7 years ago

It already builds from master, not dev.

It depends on what I am working on. Sometimes there will be several pushes to master a day, why would I rebuild images then? We also don't know when they stop providing free docker builds. I may add a node sooner or later, then we can change the workflow. But as of today I like to track the builds myself. Some bigger changes to base images can also break behaviours of mailcow.

mkuron commented 7 years ago

Sometimes there will be several pushes to master a day, why would I rebuild images then? We also don't know when they stop providing free docker builds.

I see your point, I'm just saying that you don't need to be shy in consuming Docker Hub's public build resources as everyone else is doing it too. They actually seem to be automatically eliminating unnecessary builds (where neither the base image nor the Dockerfile or any resources it refers to have been changed), though I haven't found documentation on this.

Some bigger changes to base images can also break behaviours of mailcow.

This shouldn't happen. The base images you are using are debian:stretch-slim, debian:jessie-slim, debian:testing-slim (on the Postfix container, should probably be debian:stretch-slim so you don't get a version change once Stretch is released in a few weeks) and php:7.1-fpm. The Debian images are stable and should never introduce regressions as per Debian's support policy. The PHP-FPM container is so widely used that the PHP project cannot afford breaking changes outside of new point releases either.

Docker Hub is used by so many projects that there ought to be a way to make it work for Mailcow too.

discofris commented 7 years ago

After a

docker-compose pull

I got it working again. Because of this I had some chaos in my global DNS entries (changed my MX records and did a booboo meanwhile with a CNAME ...). Think I have it all sorted out now. Thanks all!

Some really interesting input @mkuron , got me scared a bit now. I only have 1 domain running mailcow, but the unavailability of 2 single mailboxes triggered some serious alarms in my family ... Would be great indeed to see a "build status passed" somewhere.

mkuron commented 7 years ago

Would be great indeed to see a "build status passed" somewhere.

It wasn't built, so there wouldn't have been any failed status. Besides, Mailcow doesn't have any automated testing, so this wouldn't have been caught. While automated testing certainly would be possible, it would be a lot of work.

discofris commented 7 years ago

For about 2 months I was a happy cow, but I got burned now ... I really love Rspamd in this, not all have it yet.