SASL rimap auth without combine

[engelant]

With a single domain setup backed by a Samba4 AD i'm unable to auth trough kopano gateway (an IMAP server/Gateway).

Found out the reason for this behaviour is /etc/supervisor/conf.d/saslauth.conf, which has the -r flag set.

I was unable to find a smart way to alter this via the existing mechanisms, so I would like to aks if it would fit the project to expose this flag to a boolean ENV like
SASLAUTHD_RIMAP_COMBINE=0

[casperklein]

Regarding a smart way to alter this, take a look at: https://github.com/tomav/docker-mailserver/wiki/FAQ-and-Tips#howto-adjust-settings-with-the-user-patchessh-script

Putting something like this in user-patches.sh should work:

sed -i 's/rimap -r/rimap/' /etc/supervisor/conf.d/saslauth.conf

[engelant]

Ok, the sed command seems to work, but my user-patches.sh doesn't get exectued.

root@mail:/# ls -lah /tmp/docker-mailserver/user-patches.sh 
-rwxr-xr-x 1 root root 103 Sep 14 18:20 /tmp/docker-mailserver/user-patches.sh
root@mail:/# cat /tmp/docker-mailserver/user-patches.sh
#!/bin/bash

sed -i 's/rimap -r/rimap/' /etc/supervisor/conf.d/saslauth.conf 2>&1 >> /tmp/user-patches

[casperklein]

Did you restart the container? docker-compose down; docker-compose up

On container startup, you should see (2nd line in snippet below):

  * Creating daily cron job for logwatch reports
  * Executing user-patches.sh
Customize Amavis..
Customize dovecot..

[engelant]

Wait a second, Kopano docker includes v6.2.0, and let me guess, there is no user-patches.sh in that version.

Sry, my bad, didn't assue they used such an old release

[engelant]

Is it possible, that user-patches.sh is executed after supervisord is launched?

I can see the changes in my saslauth.conf after the container hast started and user-patches.sh were appied
sed -i 's/rimap -r/rimap/' /etc/supervisor/conf.d/saslauth.conf
but the running process output from inside the docker still gives me the old config. If I restart the docker image it works as expected.

[erik-wramner]

The script should be executed after supervisord is launched, but before all the individual services run.

[engelant]

@erik-wramner I don't know If I understood your reply.

Should the user-patches.sh be able to modify supervisord related configs or should one take a different approach?

@aendeavor tagged this as a bug, so it actually should execute before supervisord?

From my side I would replace the Docker start command with a script, which first executes the user-patches.sh (if exist) and then runs supervisord. And of course remove the user-patches.sh from wherever it gets called right now.
If that's an acceptable solution I would prepare a PR in the evening.

[georglauterbach]

@engelant I just read over it quickly and the response from @erik-wramner indicated a bug for me. If this is not the case, I will of course remove this label.

[casperklein]

Is it possible, that user-patches.sh is executed after supervisord is launched?

Yes, that's the case. As @erik-wramner wrote, on container start, supervisord is executed, which then calls start-mailserver.sh. This script do several things, including customizations (user-patches.sh) and after that, it starts the different daemons.

You can see this in the console log on container start. You probably have to set DMS_DEBUG=1 to see the full startup information.

From my point of view, there is no race condition or something similar, which could cause the problem you describe. I would check all again and/or start from scratch. If that doesn't help, post your complete setup/config, to see if it is reproducible.

[engelant]

@casperklein ok, but then it makes perfect sense, doesn't it?
My file I want to patch is /etc/supervisor/conf.d/saslauth.conf, which itself is included from /etc/supervisor/conf.d/supervisord.conf.
Now, from my understanding supervisord will read its config at start (including the config I need to patch), and then execute the patcher.
Resttarting the container makes supervisord load my config.
docker-compose down && docker-compose up -d will bring it back to vanilla, so no patched supervisord config on the first run.

Main question here is: is it by design that user-patches.sh can't patch supervisord config or is it a bug?

[casperklein]

Yes, you are absolutely right! I was too focused on, when user-patches.sh is called and not what you are actually trying to achieve.

Main question here is: is it by design that user-patches.sh can't patch supervisord config or is it a bug?

I guess when user-patches.sh was introduced, that special use case (modifying supervisord configs) was not considered. So at the moment, it's by design.

From my side I would replace the Docker start command with a script, which first executes the user-patches.sh (if exist) and then runs supervisord.

I think, that's the way to go. Or you can build a custom docker image with the config file already patched to your needs.

[casperklein]

@engelant

What happens if you append the following to your user-patches.sh

# supervisorctl reread # probably not needed in your use case
supervisorctl update

I think that should work.

[erik-wramner]

At present the user patches script runs right before starting the daemons. That means all the other configuration is in place, so the user patches script can make final adjustments. If we move it and run it before starting supervisor we risk breaking existing scripts out there that rely on the startup script to do its work fist. If the solution by @casperklein above works that is better.

[engelant]

@casperklein Yepp, that seems to do it, it's so simple.
@erik-wramner Exactly those kind of side effects I was afaraid of.

I guess It would be a good Idea to add that info to the wiki page, so that's what I did.