SMTP configuration for Invitations

[ncaycedo]

Hello, I'm getting started with LDAP and after learning the basics I decided to try FusionDirectory to get some more features. I'd like to use the Invitations plugin, which seems fairly straightforward. However I haven't been able to figure out how to properly configure an SMTP server to actually send the invitations.

I have an external mail server running Mailu which uses Postfix and Dovecot. I installed the plugins in both the frontend and the openldap instance but the configuration is like nothing I've seen before. I tried creating a server entry with a dovecot service and using it as the IMAP server for the admin account, sadly without success. There's no documentation for the Postfix plugin so I'm at a loss.

Can you give me a hand? =)

[tiredofit]

I've no experience with the invitations plugin personally but the base image includes SMTP support. Have a peek here: https://github.com/tiredofit/docker-alpine#messaging-options for the SMTP options available. You would simply want to just set the SMTP_HOST to your Postfix server and an optional SMTP_PORT and SMTP_USER/SMTP_PASS. The container should auto configure with those settings.

If you wanted to try without restarting the container over and over again finding the right settings you can go inside the fusiondirectory frontend container and edit /etc/msmtprc directly and the php engine will immediately use those settings.

I used to have a feature in these images which caught the mail so you could see it actually going out. I took it out a few months ago as there wasn't much purpose in my use case, but here is a definite use case :)

[ncaycedo]

Thanks for pointing me into the right direction! I managed to make it work but it did take some tinkering. This is what I did:

• set the variables for smtp as described in the docs for the Alpine image. Here it's important to set SMTP_AUTO_FROM=off as the default will make it so the requests are done with the local username instead of the one provided in the config. My server kept rejecting nginx@example.com and it took me a while to figure out where that was coming from.
• manually change the owner and permissions for the msmtprc file with chown nginx:www-data /etc/msmtprc and chmod 600 /etc/msmtprc. Without this, msmtp won't let php call it and it will result in an error.

I think it's important to change the documentation to reflect the actual values for the environment variables. For some options like tls and auto_from it states TRUE or FALSE but this will write that to the config file, which expects on or off in these options and will therefore fail to execute msmtp. I'll open an issue for this in the right repo.

[tiredofit]

OK, I will actually set default to FALSE for SMTP_AUTO_FROM anyways in a future build. I am doing a bit of transformation in the images to use the on/off syntax in the final configuration, and last week only changed the README to support the TLS options moving from off/on to TRUE/FALSE, so I apologize, you are getting caught in a bit of a update scenario where the downstream images aren't fully up to date with whats happening at the top. Lots of things have changed recently as I introduce more features for my usage scenarios.

Thank you for the heads up on the permissions as well - This again was because the upstream image changed syntax and I never followed up on it in another image right before we add the fusiondirectory components. FWIW - with the version that you are on if you set ENABLE_SMTP=TRUE it would have set it properly for you. But, lets not think about the past, and let me get some bug fixes in place for you and get you onto a freshly build fusiondirectory and openldap-fusiondirectory. I should be done in the next 48 hours with the other work I am working on which is causing massive builds of many images and then we should be back in a stable state.

I think what I will also do is for the time being since fusiondirectory 1.4 is still in beta, is setup some sort of automatic monthly build of both images so that we don't run into something like what we saw with your schema issue.