DEFAULT_URL_PATTERN variable line added to /etc/mm_cfg.py each time the container is restarted

Hi,

First of all I am very impressed by your Mailman 2.1 container, works very nicely thank you :)

I have noticed that the below section adds a new line every time the container is restarted to /etc/mailman/mm_cfg.py

Lines 23 to 28 in 8a2e459

    
           # define the URL pattern for mailman 
        
           if [ $URL_PATTERN != "http" ]; then 
        
               echo "DEFAULT_URL_PATTERN = 'https://%s/${URL_ROOT}'" >> $mailmancfg 
        
           else 
        
               echo "DEFAULT_URL_PATTERN = 'http://%s/${URL_ROOT}'" >> $mailmancfg 
        
           fi

I have tested a fix locally that resolves this:

if ! grep 'DEFAULT_URL_PATTERN' $mailmancfg; then
   if [ $URL_PATTERN != "http" ]; then
      echo "DEFAULT_URL_PATTERN = 'https://%s/${URL_ROOT}'" >> $mailmancfg
   else
      echo "DEFAULT_URL_PATTERN = 'http://%s/${URL_ROOT}'" >> $mailmancfg
   fi
fi

Thanks

Daniel

Hi Daniel,

Thanks for your feedback!

You're right, as the container default CMD is the run.sh script, each container stop/start cycle will go through the whole run.sh script again. It includes several files modifications, initialization & settings and it currently only makes exception for the files that are intended to be kept as with the TLS and DKIM keys that are located in the volumes to preserve them from destruction.

I agree that it would speed up the stop/start cycle to detect new start for the whole script and that avoiding to append again content to files may preserve from file growing considerably in case of a long term uncontrolled restart loop.

However resetting the container from scratch has the advantage of overwriting any "unintended" modification.

May I ask you what is your use case for stop/start of your container repeatedly?

I'm asking because, except for crash loops, dev/tests, and cases where you need to retrieve some content from your container that is not in your volumes, it is rather a better practice to destroy (i.e., stop and remove) a container and to recreate a new one instead of using stop/start:
The destroy/recreate process largely benefits from the container image immutability properties and will bring you more stability and reproducibility.

As the "/etc/mailman/mm_cfg.py" is not in your volumes (except if you specifically declared it), it should not be impacted by multiple lines appending with multiple destroy/recreate cycles.

I'll think about your suggestion or a slightly different implementation to improve this container stop/start cycles case, but to my knowledge, they are pretty rare use cases of this container in production, except for crash loops that might alert on a design issue or issues coming from outside of the containers.

Let me know.

Hi Angatar,

Thanks for your response and clarifying the intended usage of run.sh, I completely agree in regards to immutability and resetting any unintended modifitcation. For containers that we use in production if they stop working as intended some are restarted and others are recreated (we use Ansible). I'll make a note that this container should be stopped, removed and re-deployed, that is following good container principles.

I was restarting (see if it could be and what occurred) because I am currently in the process of testing the container for a migration of Mailman2.1 from a VM.

The file /etc/mailman/mm_cfg.py is being specifically declared for certain setting such as:

DEFAULT_LIST_ADVERTISED = No

Enhancement suggestions based on my testing so far:

Make the above available via an environment variable
We also use list creator option, I believe it would be useful to have this available as well via an environment variable.

Many thanks

Daniel

Sorry for the delay, I've finally had a look at it and ended up with a simplification of restart cycles.

The fix has just been pushed and you can docker pull d3fk/mailman2 to get the last container version so that your next restart cycles won't append the lines again to that file.

I've considered the addition of the new environment variables you suggested, and they for sure have their interest, but I won't add them as the point of this container is to provide a rapid and simple set up avoiding to make it more complex with too many options that can be defined in a config file if required. There are so many interesting options available, see:

docker run --rm --name mailman -d d3fk/mailman2 && \
docker exec mailman more /usr/lib/mailman/Mailman/Defaults.py && \
docker stop mailman

Moreover the DEFAULT_ options only impacts default behavior of the next created lists and not of the existing lists. The existing lists can be configured from different ways including the interfaces.

As in your case it seems you require a more specific configuration it is advised for your production to create your own docker image from the d3fk/mailman2 image copying your specific config file into the image of the container and not mounting them to the container with volumes:

Here is a simple example of a Dockerfile that contains a more specific config file:

FROM d3fk/mailman2

COPY {LOCAL_PATH}/mm_cfg.py /etc/mailman/mm_cfg.py

The build:
docker build -t danielmailman .

The run:
docker run danielmailman

Hope this helps.

Very sorry for the long delay in responding, it's been a busy time and then the Christmas break :)

Thanks for taking the time to do that involved fix of run.sh, much appreciated.

That's makes absolute sense in regards to the new environment variables and your example to view the Defaults.py file is very useful.

The advice and example for my configuration will be very helpful, I can certainly create my own docker image based on d3fk/mailman2.

I'll close issue and again many thanks for all your time and effort on this :)

	# define the URL pattern for mailman
	if [ $URL_PATTERN != "http" ]; then
	echo "DEFAULT_URL_PATTERN = 'https://%s/${URL_ROOT}'" >> $mailmancfg
	else
	echo "DEFAULT_URL_PATTERN = 'http://%s/${URL_ROOT}'" >> $mailmancfg
	fi