Bug#990344: exim 4.94.2 update default configuration option breaks MTA
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
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
On Tue, Jun 29, 2021 at 08:17:16AM -0300, sawb...@xsmail.com wrote: > It would make a lot more sense (and would have saved me a lot of > grief) if the exim 4.94.2 installer would have popped up something > like this: The "exim installer" is called dpkg and is a core package of Debian. You can file bugs against it using "reportbug dpkg". The dpkg-conffile prompts are issued by dpkg, and it is neither possible to influence those prompts from a package nor are we allowed by policy to "manually" tamper with dpkg-conffiles from within a package maintainer script. This probably concludes what we as exim maintainers can say and/or do. You have a point, but you should take this up to the dpkg maintainer who would be in a position to change a user interface that has been mainly unchanged for two decades. Personally, I think it would be a very bad idea to change this three weeks for a planned release date. I apologize, but there is nothing the Debian exim maintainers can to other than to pop up a warning which we actually already do. And no, three weeks before a planned release date we are not going to change the wording of this warning. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
Hello: Thank you for taking the time to write. > ... exim packages do not change/edit the file, if it was changed > then manually. Right. The userland cannot change it, it's only through *manual* edition. Now I'm *sure* I didn't change anything. I had never seen the insides of an exim config file till I had this problem. > > ... 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. > Sounds reasonable, yes. I thought as much also. > If you are not sure what you did change ... No. What I wrote was that I did not remember *ever* changing anything. But that I was *not absolutely certain* of not having done it. Not the same thing. I any case, it is a moot point. ie: it has no relevance with respect to the case I have been attempting to make which is this: Whether *any* of the configuration files were changed or not, a basic fact (which you find attendable/reasonable) remains: *Any* configuration file belonging to a version *previous* to exim 4.94.2, modified or not, will effectively break exim 4.94.2. eg: any configuration file containing *$local_part* instead of *$local_part_data*. If the dpkg installer considers no config file have been modified, it will overwrite then and everything will be allright. But ... If (for whatever reason) the dpkg installer considers some config file has been modified, it will recommend a default option that will break the MTA. If I may suggest: It would make a lot more sense (and would have saved me a lot of grief) if the exim 4.94.2 installer would have popped up something like this: - WARNING All exim versions prior to version 4.94.2 are now obsolete. As a result, *all* existing configurations set up with versions prior to exim 4.94.2 will effectively break this installation. The exim installation being updated is prior to exim version 4.94.2. It is emphatically recommended that you do not keep the present configuration. What do you want to do? 1. Replace the present configuration (recommended default) 2. Keep the present configuration 3. Open a terminal and compare the configuration files Thanks for your input.
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
On 2021-06-26 sawb...@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, 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. Sounds reasonable, yes. 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'
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
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.
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
On 2021-06-26 sawb...@xsmail.com wrote: > Hello: > Please excuse me, it happens that english is not my native language > so it is quite probable that I may not have expressed myself > correctly. > > Overwriting local customizations is not an option. > I was referring to whatever files are installed by *default* by the > exim-config package. > As I understand it, these files are *not* local customizations. [...] Hello, 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. cu Andreas
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
Hello: Please excuse me, it happens that english is not my native language so it is quite probable that I may not have expressed myself correctly. > Overwriting local customizations is not an option. I was referring to whatever files are installed by *default* by the exim-config package. As I understand it, these files are *not* local customizations. Of these files, the one probably used my most desktop installations is the /etc/exim4/exim4.conf.template file used for the basic non-split configuration. Using an exim4.conf.template file from any version prior to exim 4.94.2 *will* break exim 4.94.2. Now, when I upgraded to exim 4.94.2 the installer asked me to make a choice with respect to the configuration. I chose the *default* (recommended) option. ie: to keep the existing configuration. But this *existing configuration* included the default exim4.conf.template file from the previous version of exim4. Making that choice (recommended) resulted in the installer keeping back the updated exim-config 4.94.2 package and leaving the installed version in place. Leaving the installed version in place broke the exim 4.94.2. Thanks in advance,
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
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,
