Update config after container creation.

[SamMousa]

Ideally there should be a way to update the configuration of the forwarder after creation.
For example an forward configuration file could be mounted and watched for changes as an alternative to the environment variable.

[huan]

Hi @SamMousa ,

SMF is a docker image, which is designed to be simple and easy to use.

All the configuration of the SMF is only an environment variable: SMF_CONFIG, and that's all.

So I suggest the best practice of use SMF for update configuration is just stop the docker, set the new SMF_CONFIG, and start it again.

This kind of restart will not be an issue because the SMTP service is designed well to deal with this kind of restart, so your need no worry about any email lost.

[SamMousa]

I cant change the env when stopping / starting a container; I need to
recreate the container. For that to work I need to mount the spool folder
as a volume (so i can connect it to the new container later).

The problem is that the environment variable value is only specified on the
commandline and it is not persisted anywhere. Adding a support for an
(optional) mount in the same way as the certificate files would be simple
and useful.
You could even just do something as simple as loading the config file into
the environment variable on startup; that way you support both!

On Wed, Nov 9, 2016 at 1:57 PM, Zhuohuan LI [email protected]
wrote:

Hi @SamMousa https://github.com/SamMousa ,

SMF is a docker image, which is designed to be simple and easy to use.

All the configuration of the SMF is only an environment variable:
SMF_CONFIG, and that's all.

So I suggest the best practice of use SMF for update configuration is just
stop the docker, set the new SMF_CONFIG, and start it again.

This kind of restart will not be an issue because the SMTP service is
designed well to deal with this kind of restart, so your need no worry
about any email lost.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhYzYKyu-ID0AhkQtGyfPI8x9K1x0lWks5q8cNBgaJpZM4KtXc5
.

[SamMousa]

The problem is as follows:

Day 1: Add redirect "@a.com:[email protected]"

Day 100: Add redirect "@c.com:[email protected]"

Now on day 100 I will have to figure out the current redirects; I can of course extract them in several ways, but none of these are easy:

1. Use docker exec to inspect the environment.
2. Use docker exec to inspect the postfix configuration.

Instead if I can use a config file that I can mount, all I would need to do is update the config file and restart the container.

[huan]

I guess you just start the docker on Day 1 using the command line, then at Day 100 you forgot the SMF_CONFIG?

In my case, I use https://cloud.docker.com(former Tutum.co) to run SMF. It has a well-designed docker management UI and can manage your containers very effectively. Also, it can restart your container very easy, which you can modify environment varaiables on the web. (It creates new containers each time for me).

I recommend you to have a try of docker cloud, it's free for the first host.

And in the other way, why do you not to try a shell script like this:

#!/usr/bin/env bash

SMF_CONFIG="@a.com:[email protected]"

docker run  -e SMF_CONFIG="$SMF_CONFIG" -p 25:25 zixia/simple-mail-forwarder

Then at Day 100, you can just stop the old container, modify the script, add "@c.com:[email protected]" to SMF_CONFIG, and run the script again?

Hope my suggestion helps.

[SamMousa]

Thanks for the feedback, I'm using that approach with rancher now.

[huan]

Rancher is great. cheers!

[SamMousa]

This kind of restart will not be an issue because the SMTP service is designed well to deal with this kind of restart, so your need no worry about any email lost.

Just to clarify; SMTP does not allow for dropping emails after they have been sent. The protocol handles servers going down before they receive the email, but if server A sends mail to C via B and B confirms the receival to A and then loses it, A will never resend it.

Just an FYI. If you stop this container while there are mails in the queue, you will lose emails!

[huan]

Yes, I agree.

That's the reason why SMF has VOLUME ["/var/spool/postfix"] at https://github.com/zixia/docker-simple-mail-forwarder/blob/ca86e2048cc2120aaef8dbdc6113b0df7ab44355/Dockerfile#L56

If we start SMF with this volume set, then there's not necessary to care about the container, either stop or delete it should not be an issue because before B confirm the receival, the email should already have been written to the postfix spool directory.

I'm not 100% sure, please correct me if there have other race conditions.

[SamMousa]

If the user doesn't explicitly map a host folder to the volume, docker will generate a volume for the container.
This means that if the container is deleted, that volume will become a dangling volume and the mail will be stuck. A new container will get a new volume.

[huan]

Yes, it is.

So you must binding VOLUME for spool directly to make sure you can delete your container without any mail lost problem.

Or, exec inside the container, stop SMTP server, flush all the emails in the spool directly before you delete it.

[SamMousa]

Ah okay, think there was a miscommunication. As long as you properly mount the volume it is fine; if you don't you risk losing stuff!

[huan]

Thanks, @SamMousa , I think you are right, this should write into the document.

Could you please help me adding this notice to README? Because you are right in this issue, a Pull Request will be very appreciated.