Not sure whether we want to clear the /etc/dms-settings files beforehand - that's why I did not directly commit the changes :D

I think clearing the files is a good practice to avoid duplicate entrys, when the container is restarted.

Entrypoint = PID1. If entrypoint is a bash script, it will not take care of signal forwarding, reaping processes etc. An init-system must be PID1.

-ENTRYPOINT ["/usr/bin/dumb-init", "--"]
+ENTRYPOINT ["/usr/bin/dumb-init", "/entrypoint.sh"]

CMD ["supervisord", "-c", "/etc/supervisor/supervisord.conf"]

Supposedly that would work fine, but allow conditional logic based on the CMD used?

But I think we can skip this discussion. If a script like listmailuser needs ENVs, it can just source /etc/dms-settings now 😎

I only bring it up because of docker run ... setup email list would not know about /etc/dms-settings or /root/.bashrc as neither exist.

I guess if docker run is never used with a CMD override it's a non-issue and any other commands should be run via docker exec on an existing instance instead.

I have had interest with adding an entrypoint script in the past, but start-mailserver.sh being started via supervisord via the mailserver service is for the most part equivalent, and anything I would add via an entrypoint should be ok there instead? (eg: there's been interest to support initializing with a dummy account instead of requiring separate external script/files to provide an account up front)

I can definitely understand how always setting up ENV could be an issue (eg: the open-dkim utility script has generic var existence checks like DOMAINS which aren't scoped to local vars/unset upfront), but there's also stuff like this in our tests (added in 2016 by original project author):

That's just running the container and echoing the ENV that was set on it. The echo CMD overrides the default supervisord command since this is docker run and not docker exec, thus none of the startup scripts are run. I guess that's fine, as VIRUSMAILS_DELETE_DELAY is only:

• Dockerfile: ENV default to 7 (added in 2017 for cron, did not work but was retained)
• start-mailserver.sh: default to 7 (makes the Dockerfile ENV a bit redundant? When the Dockerfile ENV was added in 2017 this var was removed, but then added back in 2018 to resolve an issue)
• setup-stack.sh: writes it to /etc/environment (cron, same 2017 PR)

Likewise two tests that use delmailuser and addmailuser also call themselves via docker run, if they ever need to rely on something like /etc/dms-settings that won't exist.

Just a caveat to be aware of, doesn't seem like it would cause any problems for the project atm though 👍

@polarathene

I only bring it up because of docker run ... setup email list would not know about /etc/dms-settings or /root/.bashrc as neither exist.

Correct. Haven't consider this till now. The script will throw an error "/usr/local/bin/listmailuser: line 5: /etc/dms-settings: No such file or directory" but then continues flawless, which I didn't understand at first. See below why.

@georglauterbach

Some time back, you wanted us to use [[ expresssion ]], instead of [ expression ], which was used until then. I thought, there were only benefits and no drawbacks. However, today I noticed something that did not work as expected for me:

     1  #!/bin/bash
     2
     3  if [ "$SOME_UNSET_VARIABLE" -eq 0 ]; then
     4          echo "foo"
     5  fi
     6
     7  if [[ "$SOME_UNSET_VARIABLE" -eq 0 ]]; then
     8          echo "bar"
     9  fi

./test.sh: line 3: [: : integer expression expected
bar

I stumpled upon this, because I wondered, why listmailuser didn't fail, when $ENABLE_QUOTA was unset (called via setup.sh and no container running).

However, today I noticed something that did not work as expected for me

That works how I'd expect tbh.

The value is unset/null/false, so I expect the it to evaluate to equivalent of 0 (falsey). Some programming languages at least behave that way. Although ${SOME_UNSET_VARIABLE} == 0 will evaluate to false.. 🤷‍♂️

I guess this is some kind of Bashism, but it also kind of makes sense to me. What you brought up a sh specific error, and bash evaluates variables whose values are null to falsy and I guess therefore equal to zero. I wouldn't see this as a drawback with Bash to be honest, because the type system (haha, as if Bash had a real type system) is somewhat weird with shells in general.

If this was a programming language like C or Rust or something else with a strict typing discipline, I'd consider this a drawback too, but with Bash, I've learned to just accept it :D