grommunio / gromox-container

Docker deployments for gromox, and grommunio (in progress)
7 stars 7 forks source link

Rspamd not starting #1

Closed kbekus closed 1 year ago

kbekus commented 1 year ago

hi there, many thanks for putting together a docker-compose environment for Grommunio. I've been trying to get this going and have run into an issue:

#31530(main) rspamd_inet_address_listen: bind 127.0.0.1:11332 failed: 98, 'Address already in use'
#31530(main) rspamd_inet_address_listen: bind [::1]:11332 failed: 98, 'Address already in use'

my docker-compose.yml is largely the same as in your example, and inside the container I do have IPv6 enabled:

5f36c6e335a:/ # ip addr show
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
865: eth0@if866: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:c0:a8:30:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.48.2/24 brd 192.168.48.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:c0ff:fea8:3002/64 scope link 
       valid_lft forever preferred_lft forever
    inet6 fe80::1/64 scope link nodad 
       valid_lft forever preferred_lft forever

This container is running in it's own subnet with it's own unique IPv4 address. It does not appear that 11332 is open either inside the container or on the host machine. Hunting through logs and experimenting I'm wondering if perhaps having 2 IPv6 addresses assigned to eth0 might cause an issue?

cheers, Kristan

fmos commented 1 year ago

Hi Kristan, I have the same issue even when IPv6 is disabled and the configuration rewritten to "127.0.0.1" instead of "localhost" in all instances. I suppose the 2 IPv6 addresses are not the cause.

In my case, rspamd is restarted so fast it eats the complete resources of the host system and effectively halts all other services. In order to avoid this issue, I have added a finish script to the s6 config to make the system sleep for 30 seconds before restarting rspamd:

$ cat /etc/s6-overlay/s6-rc.d/gromox-antispam/finish
#!/command/execlineb -P
sleep 4s

My hope was that given additional time the 'Address already in use' error would go away. It does not.

fmos commented 1 year ago

Have been playing with this and have an image that reaches a working admin interface. You can find my changes in this fork, as well a my compose file. If you have the opportunity to test, feedback is welcome.

kbekus commented 1 year ago

awesome job! Thank you, I'll check it out. Though to be honest I'm going a bit cold on Grommunio.... as a long time Kopano user I was looking for an alternative since they decided to cut the community edition but I'm starting to have my doubts about Grommunio, there seem to be many issues with it.

fmos commented 1 year ago

I'm also (still) using the Kopano community edition. In my case since 2020. Before that I have been using Tine 2.0 for several years. I switched because of their lack of a shared calendar that syncs to mobile devices and can be edited by anyone (something I find invaluable for family organisation) and also because the mailbox search on mobile was not reliable (something I now also see with Kopano, unfortunately). What are you planning to use, if not Grommunio?

I don't give up on Grommunio yet. Yes, it seems they focus on VM or bare-metal deployments using their own distribution. But I think that is reasonable, because they target users for whom the additional cost of a full VM is not an issue. For my private use, however, I would prefer to use the weakest host possible, which is typically KVM with only a limited choice of possible distributions. Thus, Docker (or, ideally, Podman) should help to abstract the distribution away.

Btw., installing their distribution in a fully privileged container also works, but has to be setup manually inside the container. I would prefer to achieve an automated Ansible deployment of the Grommunio applicance, which I can test at home before rolling it to my VPS (and replacing Kopano). This should also facilitate updates and allow me to test my backups more often with a private mirror at home.

grammola commented 1 year ago

@fmos, thank you for your phenomenal work on the gromox container and helping out @kbekus. We merged your fork into the main repo with some additions. We are moving into using confd for environment configuration probably in the next release.

However, you mentioned that you would like an automated ansible deployment. We have an initial set up for that but if you would like to contribute, that would be great as well. If you would like to discuss that, please reply here and mention me. I will reach out to you.

Thank you!

fmos commented 1 year ago

@grammola , great to hear that my fork was useful! Did not test your new image, but intend to do so very soon. I do not know confd, but always enjoy learning.

Yes, ideally, I would like to have a reproducible deployment to reliably mirror my hosted production instance on a local machine (e.g. on my NAS). This should be possible when as much as possible is implemented with Ansible playbooks. My motivation is that I want to test my backups and have a local mirror as a fallback.

At the moment, my strategy has been to use Ansible to deploy everything up to a running Portainer instance and deploy with docker compose from there. However, I'm thinking about changing this in favour of Podman, which does not have compose afaik, and thus use Ansible also for the database and Grommunio instance setup, and Cockpit for status and management access. Cockpit and Grommunio admin should be accessible only via Wireguard. Grommunio web, SMTP and other user services should be accessible directly, naturally.

And yes, I would always like to contribute, if I can.