https://bugs.exim.org/show_bug.cgi?id=2941
Bug ID: 2941
Summary: More convenient option behavior for containerized
environments
Product: Exim
Version: 4.96
Hardware: x86
OS: Linux
Status: NEW
Severity: wishlist
Priority: medium
Component: String expansion
Assignee: unallocated@exim.org
Reporter: ivanov+bugs@anarhist.net
CC: exim-dev@exim.org
I tried to build Exim container image for docker/podman based on CentOS/Fedora
and found that the usual containerization practices don't work with the Exim
configuration. I think this is a problem, because it makes building Exim images
very difficult. Container images building is possible only for simple smarthost
configuration.
The main idea is to use some configuration inside container for multiple
installations on different hosts. Options that can be changed are defined using
environment variables. These options can be overriden for the container
environment if needed.
Unfortunately, Exim is not very friendly to use of environment variables.
First, I found that primary_hostname and qualify_domain options don't work with
expansions. Any expansion is interpreted as a string.
If I set the variable
exim__primary_hostname=domain.tld
and set the option
primary_hostname =
${env{exim__primary_hostname}{$value}{localhost.localdomain}}
I get the result:
[root@6242eed3cd90 /]# exim -bt user
user@${env{exim__primary_hostname}{$value}{localhost.localdomain}} is
undeliverable: mail domain
"${env{exim__primary_hostname}{$value}{localhost.localdomain}}" is
syntactically invalid
There is no simple solution. Using macros or includes doesn't make sense,
because they do the exact same thing. I can only run a shell script that will
read the variable and edit the configuration before Exim running, e.g. with
sed. But if I want to run the script as an unprivileged user, I also have to
change the owner of the configuration file. This doesn't seem like a good idea.
Some other main options don't work with expansions either.
For example, using an string expansion for prdr_enable option resuls in an
error:
"" is not a valid value for the "prdr_enable"
Using string expansion for dns_dnssec_ok option also results in an error:
integer expected for dns_dnssec_ok
I think there is no security reason for this behaviour. I hope that in future
releases this will be changed and the use of string expansions will be
available for each option.
Exim is great, I think we will use its power in containerized environments as
well.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Bug ID: 2941
Summary: More convenient option behavior for containerized
environments
Product: Exim
Version: 4.96
Hardware: x86
OS: Linux
Status: NEW
Severity: wishlist
Priority: medium
Component: String expansion
Assignee: unallocated@exim.org
Reporter: ivanov+bugs@anarhist.net
CC: exim-dev@exim.org
I tried to build Exim container image for docker/podman based on CentOS/Fedora
and found that the usual containerization practices don't work with the Exim
configuration. I think this is a problem, because it makes building Exim images
very difficult. Container images building is possible only for simple smarthost
configuration.
The main idea is to use some configuration inside container for multiple
installations on different hosts. Options that can be changed are defined using
environment variables. These options can be overriden for the container
environment if needed.
Unfortunately, Exim is not very friendly to use of environment variables.
First, I found that primary_hostname and qualify_domain options don't work with
expansions. Any expansion is interpreted as a string.
If I set the variable
exim__primary_hostname=domain.tld
and set the option
primary_hostname =
${env{exim__primary_hostname}{$value}{localhost.localdomain}}
I get the result:
[root@6242eed3cd90 /]# exim -bt user
user@${env{exim__primary_hostname}{$value}{localhost.localdomain}} is
undeliverable: mail domain
"${env{exim__primary_hostname}{$value}{localhost.localdomain}}" is
syntactically invalid
There is no simple solution. Using macros or includes doesn't make sense,
because they do the exact same thing. I can only run a shell script that will
read the variable and edit the configuration before Exim running, e.g. with
sed. But if I want to run the script as an unprivileged user, I also have to
change the owner of the configuration file. This doesn't seem like a good idea.
Some other main options don't work with expansions either.
For example, using an string expansion for prdr_enable option resuls in an
error:
"" is not a valid value for the "prdr_enable"
Using string expansion for dns_dnssec_ok option also results in an error:
integer expected for dns_dnssec_ok
I think there is no security reason for this behaviour. I hope that in future
releases this will be changed and the use of string expansions will be
available for each option.
Exim is great, I think we will use its power in containerized environments as
well.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##