Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
142 views
Skip to first unread message
saw...@xsmail.com
Jun 26, 2021, 7:40:03 AM6/26/21
to
Package: exim4
Version: 4.94
Severity: grave
Half way through the update to exim 4.94.2, the installer pops up a
warning in the terminal informing that the configuration file being
installed is different to the one in place and prompts to choose
what to do:
1. keep the installed configuration (default)
2. install the new configuration
3. check and compare the differences in order to choose.
In most default Debian installations the installer will be
referring to the [c]/etc/exim4/exim4.conf.template[/c] which is used
by the default non-split configuration scheme used by most anyone
running a Debian desktop box.
Most users will choose the (recommended) default option.
In doing so they will unknowingly break their exim4 installation.
The result is a non-working MTA, with system mail being held.
ie: not delivered to /var/mail/user folder while at the same time
/var/log/exim4/paniclog slowly grows in size.
With all versions of exim previous to version 4.94.2 now rendered
obsolete, exim 4.94.2 will break any and all configurations set up
with previous versions of the package.
This happens whether it uses the default configuration ie: the
non-split configuration scheme which uses the
/etc/exim4/exim4.conf.template file or the split configuration scheme
used in more complex installations and which you can eventually opt
for when installing Debian or by running dpkg-reconfigure
exim4-config later on.
---
exim 4.94.2 is absolutely incompatible with any configuration files
used/generated with versions previous to version 4.94.2.
Worse yet, it is absolutely incompatible with *any* configuration
file contained in the exim-config package from versions preceding
exim 4.94.2.
Presenting the option to keep *any* existing configuration file when
updating to exim version 4.94.2 generates a big problem.
---
Presenting the options to keep installed files is *always* quite
reasonable but not in *this* very significant update.
Thanks in advance,
Version: 4.94
Severity: grave
Half way through the update to exim 4.94.2, the installer pops up a
warning in the terminal informing that the configuration file being
installed is different to the one in place and prompts to choose
what to do:
1. keep the installed configuration (default)
2. install the new configuration
3. check and compare the differences in order to choose.
In most default Debian installations the installer will be
referring to the [c]/etc/exim4/exim4.conf.template[/c] which is used
by the default non-split configuration scheme used by most anyone
running a Debian desktop box.
Most users will choose the (recommended) default option.
In doing so they will unknowingly break their exim4 installation.
The result is a non-working MTA, with system mail being held.
ie: not delivered to /var/mail/user folder while at the same time
/var/log/exim4/paniclog slowly grows in size.
With all versions of exim previous to version 4.94.2 now rendered
obsolete, exim 4.94.2 will break any and all configurations set up
with previous versions of the package.
This happens whether it uses the default configuration ie: the
non-split configuration scheme which uses the
/etc/exim4/exim4.conf.template file or the split configuration scheme
used in more complex installations and which you can eventually opt
for when installing Debian or by running dpkg-reconfigure
exim4-config later on.
---
exim 4.94.2 is absolutely incompatible with any configuration files
used/generated with versions previous to version 4.94.2.
Worse yet, it is absolutely incompatible with *any* configuration
file contained in the exim-config package from versions preceding
exim 4.94.2.
Presenting the option to keep *any* existing configuration file when
updating to exim version 4.94.2 generates a big problem.
---
Presenting the options to keep installed files is *always* quite
reasonable but not in *this* very significant update.
Thanks in advance,
saw...@xsmail.com
Jun 26, 2021, 1:30:02 PM6/26/21
to
Hello:
On 26 Jun 2021 at 15:12, Andreas Metzler wrote:
> I think that assumption is not correct. dpkg will (should) only ask
> about the confffile if it *was* locally changed, otherwise the files are
> overwritten without asking.
I see ...
The thing is that I don't remember *ever* changing any exim
configuration.
Unfortunately I cannot be categorical about it.
ie: I am not absolutely certain.
Right.
Please bear with me, I'll try to be as brief as possible.
Let us assume for the sake of the argument that I (on purpose or
inadvertently) changed something in the configuration.
What could I have possibly changed?
Is there any user/userland configurable setting which would be then
reflected or change *anything* in the exim4.conf.template file
itself?
Specifically, any of the settings mentioned in the readme.updating
file:
https://git.exim.org/exim.git/blob/HEAD:/src/README.UPDATING
--- snip --->
Exim version 4.94
---------------------------
Some Transports now refuse to use tainted data in constructing their
delivery location; this WILL BREAK configurations which are not
updated accordingly. In particular: any Transport use of $local_part
which has been relying upon check_local_user far away in the Router
to make it safe, should be updated to replace $local_part with
$local_part_data.
<--- snip ---
eg: $local_part
I have checked and my pre-4.94.2 version reads *$local_part* and the
4.94.2 version reads *$local_part_data*.
So, if the original configuration file *was* changed by me (on
purpose or inadvertently), whatever change I could have made does not
seem to be related to (at least one) of the settings that need to be
changed for the exim4 configuration to be compatible with exim
4.94.2.
Thank you very much for your input.
On 26 Jun 2021 at 15:12, Andreas Metzler wrote:
> I think that assumption is not correct. dpkg will (should) only ask
> about the confffile if it *was* locally changed, otherwise the files are
> overwritten without asking.
I see ...
The thing is that I don't remember *ever* changing any exim
configuration.
Unfortunately I cannot be categorical about it.
ie: I am not absolutely certain.
Right.
Please bear with me, I'll try to be as brief as possible.
Let us assume for the sake of the argument that I (on purpose or
inadvertently) changed something in the configuration.
What could I have possibly changed?
Is there any user/userland configurable setting which would be then
reflected or change *anything* in the exim4.conf.template file
itself?
Specifically, any of the settings mentioned in the readme.updating
file:
https://git.exim.org/exim.git/blob/HEAD:/src/README.UPDATING
--- snip --->
Exim version 4.94
---------------------------
Some Transports now refuse to use tainted data in constructing their
delivery location; this WILL BREAK configurations which are not
updated accordingly. In particular: any Transport use of $local_part
which has been relying upon check_local_user far away in the Router
to make it safe, should be updated to replace $local_part with
$local_part_data.
<--- snip ---
eg: $local_part
I have checked and my pre-4.94.2 version reads *$local_part* and the
4.94.2 version reads *$local_part_data*.
So, if the original configuration file *was* changed by me (on
purpose or inadvertently), whatever change I could have made does not
seem to be related to (at least one) of the settings that need to be
changed for the exim4 configuration to be compatible with exim
4.94.2.
Thank you very much for your input.
Andreas Metzler
Jun 27, 2021, 12:20:03 PM6/27/21
to
On 2021-06-26 saw...@xsmail.com wrote:
> On 26 Jun 2021 at 15:12, Andreas Metzler wrote:
> > I think that assumption is not correct. dpkg will (should) only ask
> > about the confffile if it *was* locally changed, otherwise the files are
> > overwritten without asking.
> I see ...
> The thing is that I don't remember *ever* changing any exim
> configuration.
> Unfortunately I cannot be categorical about it.
> ie: I am not absolutely certain.
> Right.
> Please bear with me, I'll try to be as brief as possible.
> Let us assume for the sake of the argument that I (on purpose or
> inadvertently) changed something in the configuration.
> What could I have possibly changed?
> Is there any user/userland configurable setting which would be then
> reflected or change *anything* in the exim4.conf.template file
> itself?
Hello,
> On 26 Jun 2021 at 15:12, Andreas Metzler wrote:
> > I think that assumption is not correct. dpkg will (should) only ask
> > about the confffile if it *was* locally changed, otherwise the files are
> > overwritten without asking.
> I see ...
> The thing is that I don't remember *ever* changing any exim
> configuration.
> Unfortunately I cannot be categorical about it.
> ie: I am not absolutely certain.
> Right.
> Please bear with me, I'll try to be as brief as possible.
> Let us assume for the sake of the argument that I (on purpose or
> inadvertently) changed something in the configuration.
> What could I have possibly changed?
> Is there any user/userland configurable setting which would be then
> reflected or change *anything* in the exim4.conf.template file
> itself?
the exim packages do not change/edit the file, if it was changed then
manually.
> Specifically, any of the settings mentioned in the readme.updating
> file:
> https://git.exim.org/exim.git/blob/HEAD:/src/README.UPDATING
> --- snip --->
> Exim version 4.94
> ---------------------------
> Some Transports now refuse to use tainted data in constructing their
> delivery location; this WILL BREAK configurations which are not
> updated accordingly. In particular: any Transport use of $local_part
> which has been relying upon check_local_user far away in the Router
> to make it safe, should be updated to replace $local_part with
> $local_part_data.
> <--- snip ---
> eg: $local_part
> I have checked and my pre-4.94.2 version reads *$local_part* and the
> 4.94.2 version reads *$local_part_data*.
> So, if the original configuration file *was* changed by me (on
> purpose or inadvertently), whatever change I could have made does not
> seem to be related to (at least one) of the settings that need to be
> changed for the exim4 configuration to be compatible with exim
> 4.94.2.
If you are not sure what you did change, you can download older versions
of exim4-config from https://snapshot.debian.org/binary/exim4-config/
extract the file with e.g.
ametzler@argenau:~$ dpkg --fsys-tarfile /path/to/exim4-config_4.91-9_all.deb | tar -f - --one-top-level=/tmp -v -x ./etc/exim4/exim4.conf.template
and use e.g. diff or tkdiff to find local changes.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
saw...@xsmail.com
Jun 29, 2021, 4:10:03 PM6/29/21
to
Hello:
Thank you very much for taking the time to write.
On 29 Jun 2021 at 19:05, Marc Haber wrote:
> The "exim installer" is called dpkg and is a core package ...
Yes, I am quite aware of that.
Which is *exactly* the reason I did not file a bug against dpkg.
If anything, in the many years I have been using Linux, dpkg has
always worked seamlessly every time and never shown me a bug.
Kudos for that. 8^)
But the bug I filed is against exim 4.94.2.
> You have a point ...
Yes, I *do* have a point.
But unfortunately I am not being able to get it across.
That dpkg pop up a *different* warning was meant to be an example of
sorts, not to be taken literally.
To drive home the concept, so to speak.
Maybe the wrong example as I am not versed in the inner workings of
dpkg (or anything Linux for that matter) although today I learnt
something about how dpkg works.
Like I have said previously:
The problem is with the exim 4.94.2 package.
It should *not* be able/allowed to use *any* of a previously
installed version's configuration files when updated.
Much less (and yes, it *is* a bug) offer the user the choice of
keeping *any* of them when it gets installed by dpkg.
Now, *how* it does that, whether through a well written script, a
previous [c]apt-get purge exim4[/c] or dev-magic (joke!) should be
absolutely transparent to the end user and result in a properly
installed MTA.
And not a hopelessly broken one piling up warnings in paniclog.
> I apologize, but there is nothing the Debian exim maintainers ...
So I gather.
Well, that's that.
I did my part and reported the problem.
It is now up to the exim maintainers to do what they think is best.
Greetings.
CIV
Thank you very much for taking the time to write.
On 29 Jun 2021 at 19:05, Marc Haber wrote:
> The "exim installer" is called dpkg and is a core package ...
Yes, I am quite aware of that.
Which is *exactly* the reason I did not file a bug against dpkg.
If anything, in the many years I have been using Linux, dpkg has
always worked seamlessly every time and never shown me a bug.
Kudos for that. 8^)
But the bug I filed is against exim 4.94.2.
> You have a point ...
Yes, I *do* have a point.
But unfortunately I am not being able to get it across.
That dpkg pop up a *different* warning was meant to be an example of
sorts, not to be taken literally.
To drive home the concept, so to speak.
Maybe the wrong example as I am not versed in the inner workings of
dpkg (or anything Linux for that matter) although today I learnt
something about how dpkg works.
Like I have said previously:
The problem is with the exim 4.94.2 package.
It should *not* be able/allowed to use *any* of a previously
installed version's configuration files when updated.
Much less (and yes, it *is* a bug) offer the user the choice of
keeping *any* of them when it gets installed by dpkg.
Now, *how* it does that, whether through a well written script, a
previous [c]apt-get purge exim4[/c] or dev-magic (joke!) should be
absolutely transparent to the end user and result in a properly
installed MTA.
And not a hopelessly broken one piling up warnings in paniclog.
> I apologize, but there is nothing the Debian exim maintainers ...
So I gather.
Well, that's that.
I did my part and reported the problem.
It is now up to the exim maintainers to do what they think is best.
Greetings.
CIV
saw...@xsmail.com
Jul 14, 2021, 4:20:03 PM7/14/21
to
Package: backintime
Version: 1.1.24-0.1
Severity: normal
I have received yet another notification in my system mail related to
an unhandled exception in a backintime Python script.
Here is the transcript:
---
Date: Wed, 14 Jul 2021 16:45:01 -0300
Unhandled exception in thread started by <function
__log_keyring_warning at 0x7f87bbb63488>
Traceback (most recent call last):
File "/usr/share/backintime/common/tools.py", line 1458, in
__log_keyring_warning
TypeError: 'NoneType' object is not callable
---
As you will gather from the transcript, it is the same problem (line
1458) in file "/usr/share/backintime/common/tools.py".
FYI, here are the last 12 lines from the file file metioned above:
[code]
1456
1457 def __log_keyring_warning():
1458 from time import sleep
1459 sleep(0.1)
1460 logger.warning('import keyring failed')
1461
1462 if keyring is None and keyring_warn:
1463 #delay warning to give logger some time to import
1464 import _thread
1465 _thread.start_new_thread(__log_keyring_warning, ())
1466 # logger.warning('import keyring failed')
1467
[/code]
Thanks in advance,
sawbona
Version: 1.1.24-0.1
Severity: normal
I have received yet another notification in my system mail related to
an unhandled exception in a backintime Python script.
Here is the transcript:
---
Date: Wed, 14 Jul 2021 16:45:01 -0300
Unhandled exception in thread started by <function
__log_keyring_warning at 0x7f87bbb63488>
Traceback (most recent call last):
File "/usr/share/backintime/common/tools.py", line 1458, in
__log_keyring_warning
TypeError: 'NoneType' object is not callable
---
As you will gather from the transcript, it is the same problem (line
1458) in file "/usr/share/backintime/common/tools.py".
FYI, here are the last 12 lines from the file file metioned above:
[code]
1456
1457 def __log_keyring_warning():
1458 from time import sleep
1459 sleep(0.1)
1460 logger.warning('import keyring failed')
1461
1462 if keyring is None and keyring_warn:
1463 #delay warning to give logger some time to import
1464 import _thread
1465 _thread.start_new_thread(__log_keyring_warning, ())
1466 # logger.warning('import keyring failed')
1467
[/code]
Thanks in advance,
sawbona
0 new messages