Hello:

UPDATE
I was finally able to get to the bottom of all this exim4 hassle.

Please bear with me, I'll try to be as brief as possible.

When a number of important security failures (dubbed 21 Nails by the IT press) were discovered in exim4 earlier this year, the maintainers were very fast on their feet and an upgraded version 4.94.2 was released almost right away, albeit not without some uproar from the community as this new fixed version actually broke a lot of things for many a sysadmin, things that had been working perfectly well for years.

To the extent that a great many considered opting to downgrade or write risky workarounds.
I have written about this in previous posts, read and check the links if you need more info.

Bottom line?

exim 4.94.2 effectively broke any and all configurations that had been set up with previous versions, whether they used 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 Devuan or by running dpkg-reconfigure exim4-config later on.

As a result, from stand alone desktops to production environments to server farms, absolutely everyone updating to exim 4.94.2 was affected.

As mentioned, the default non-split configuration scheme, probably used by 99% of all Devuan/Debian desktops, uses the /etc/exim4/exim4.conf.template which is part of the exim-config package, in turn a dependency of the exim-base package.

The problem I have been bitching about all this time was generated when I updated to exim 4.94.2, something I expected to be a straightforward affaire, without any hassles.

And as (most) any other update, it was.

Half way through, the installer popped up a warning in my terminal informing me that the configuration file being installed ie: the previously mentioned exim4.conf.template was different to the one I had in place and prompted me to choose what to do:

1. keep the installed configuration (default)
2. install the new configuration
3. check and compare the differences.

I chose the default option and in doing so broke my exim4 installation.

As a result my Devuan Beowulf ceased to have a working MTA, all system mail was being held back.
ie: not delivered to my /var/mail/user folder while /var/log/exim4/paniclog slowly grew in size.

I found out about the cause of all this rather by accident.
After not being able to find a solution and fed up with looking, I decided to downgrade exim4 to the previous version and just risk it.

Then, looking at the installed packages, I noticed a discrepancy in their versions ie: exim-config had the previous package version number.

I downloaded and installed the proper version and when the installer warning described above popped up in my terminal, I realised what had happened when I upgraded to 4.94.2.

exim4 is now working as before.

----

Now, after feeling like an idiot for a whole afternoon, I asked myself:

1.
Why would I not choose the default option offered by the installer?

After all, WTF do I know about exim4?
Save that it is the default MTA in Devuan and it keeps me informed as to what is going on via the system mails I get in my /var/mail/user folder, nothing much.

I am not running a mail server from my box and if I add another box to my ADSL router, I believe sending mails between the two boxes is a simple affaire.

Like probably 99% of the Devuan desktops out there, a working default MTA is all I need.

In any case and just like the people who run them, I am just an average user and as such have an inherent trust in everything I download and install from the Devuan repositories, so I had absolutely no reason to choose anything but the default option recommended by the installer.

If I did not have this trust, my box would have something else running inside.

2.
Taking into account that exim 4.94.2 breaks all configurations set up with previous versions of the package ...

rant --->
How is it possible that the exim 4.94.2 installer offers me (as the default and recommended option, no less) to keep a configuration file that, belonging to a previous version, will effectively break it and make it useless?
<--- /rant

From https://www.exim.org/docs.html

From https://git.exim.org/exim.git/blob/HEAD … E.UPDATING

The /etc/exim4/exim4.conf.template file has 2200 lines of code contains a number of $local_part and check_local_user bits.
Unfortunately, editing it by hand did not help me when I did it, so evidently something else was needed.

That's about it.

Best,

A.

Hello:

Done.

Best,

A.

Hello:

One at a time, please, there's room for everyone ...

I think that the problem may lie in the fact that (according to apt) the installed exim4 configuration package ie: exim4-config is not the same version as the rest of the exim4 files in the stable-backports repository:

groucho@devuan:~$ apt list | grep installed | grep exim4

exim4-base/stable-backports,now 4.94.2-5~bpo10+1 amd64 [installed,automatic]
exim4-config/stable,stable,stable-security,stable-security,now 4.92-8+deb10u6 all [installed,automatic]  # <---  | X |    
exim4-daemon-light/stable-backports,now 4.94.2-5~bpo10+1 amd64 [installed,automatic]
exim4/stable-backports,stable-backports,now 4.94.2-5~bpo10+1 all [installed]
groucho@devuan:~$ 

All files are 4.94.2-5~bpo10+1 with the exception of exim4-config which is 4.92-8+deb10u6.

It does not seem to be available:

groucho@devuan:~$ apt list | grep exim4-config
exim4-config/stable,stable,stable-security,stable-security,now 4.92-8+deb10u6 all [installed,automatic]
groucho@devuan:~$ 

[root@devuan groucho]# apt install exim4-config
Reading package lists... Done
Building dependency tree       
Reading state information... Done
exim4-config is already the newest version (4.92-8+deb10u6).
exim4-config set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[root@devuan groucho]# 

The strange thing is that version 4.94.2-5~bpo10+1 is available in http://deb.devuan.org/merged  beowulf-backports/main which is in my sources.list file.

groucho@devuan:~$ cat /etc/apt/sources.list
## package repositories
# Changed - 20210218 - upgrade to Beowulf

# beowulf stable
deb http://deb.devuan.org/merged/ beowulf main contrib non-free 
deb http://deb.devuan.org/merged/ beowulf-security main contrib non-free 
deb http://deb.devuan.org/merged/ beowulf-updates main contrib non-free 

# needed x virtualbox backport - enable to update package
deb http://deb.devuan.org/merged/ beowulf-backports non-free contrib main  

# virtual box repository x installation
# deb http://download.virtualbox.org/virtualbox/debian/ buster non-free contrib 
groucho@devuan:~$ 

Could anyone explain what's going on with my sources.list?

Thanks in advance,

A.

Hello:

For? 8^)

And that's what I understood.
ie: one thing is executing the command listed in crontab from a shell and another is when cron actually executes that command.

Got it.
That command is set up by the application and I have not touched it.
Hence the warning:

#Back In Time system entry, this will be edited by the gui:

Yes, I've seen that some time ago.

In any case, up to now, cron.log has shown no issues with respect to the backintime script.
We'll see if I get some feedback from the GitHub site, it dos not seem to have much activity on behalf of the maintainers.
But it does not seem to be dead.

Thanks so much lot for your input.

Best,

A.

Hello:

It just dawned on me that the solution I linked to comes from the OP comparing his exim.conf with another file called exim.conf.rpmnew.
Very smart.

This other configuration file is included in a distribution (manjaro?) that detected the problem created by the exim4 update and edited the original file accordingly.

Maybe the Devuan/Debian (or better yet, the exim4 packagers may want to consider doing the same with the /etc/exim4/exim4.conf.template file.

Q: should a bug report be filed somewhere?

Best,

A.

Hello:

I think I have found a solution.
I say think because I don't have a clue as to how all this works.
ie: if this is just a workaround or a proper configuration option.

If it is just a workaround the new security schemes in exim4, then it is bound to be temporary and we'll have to be alert.
If it is a proper configuration option, WTF is it not properly documented somewhere?

I found it here:
https://www.linuxquestions.org/question … ost6136422

In this case, the problem seems to be that exim4 now does not like the directory name for my mail folder.
I think it has to do with the backlashes in /var/mail/username.

It would be really nice if whoever came up with this (must be necessary, they know how it all works) just wrote up a small bit or a proper comment inside this file informing that the solution was to edit the file /etc/exim4/exim4.conf.template which is used for the most basic exim4 configuration.
ie: the non-split configuration scheme I expect is used by most of us here at Dev1.

Evidently too much to ask.  8^/

To the point:

The part of this huge 2122 line configuration file that must be edited is the one concerning mail spool configuration.

#####################################################
 ### transport/30_exim4-config_mail_spool
 #####################################################
 
 ### transport/30_exim4-config_mail_spool
 
 # This transport is used for local delivery to user mailboxes in traditional
 # BSD mailbox format.
 #
 mail_spool:
   debug_print = "T: appendfile for $local_part@$domain"
   driver = appendfile
   file = /var/mail/$local_part # <----- this is the line that has to be edited 
   delivery_date_add
   envelope_to_add
   return_path_add
   group = mail
   mode = 0660
   mode_fail_narrower = false
 
 #####################################################
 ### end transport/30_exim4-config_mail_spool
 #####################################################

It seems that the line file = /var/mail/$local_part has to be edited to read  file = /var/mail/$local_part_data.

Sort of makes me wonder if there is any reason for the edited line not being there by default.

Caveat emptor:
I have not tested this yet, the post where I got it had a following one saying that it works.

----> EDIT
For this to work properly the exim4 configuration has to be updated.
BTW: did you see anything about it in the comments at the start of the exim4.conf.template file?
No?
I thought as much ...

As root run:

[root@devuan groucho]# update-exim4.conf -v
using non-split configuration scheme from /etc/exim4/exim4.conf.template
[root@devuan groucho]# jed /etc/exim4/exim4.conf.template

/EDIT <----

I'll post back in a couple of days reboots with the results.

Best,

A.

Hello:

That didn't show anything

Good to know.
Thanks for the heads up.  8^)

I can now continue with the housekeeping.

Best,

A.

Hello:

You're welcome.

Quite so.

But check the installed version anyhow.
You may already have the latest one available for that board.

I don't like it either.

The usual lack of properly written BIOSs aside, gigabyte is a reputed brand and their hardware can be considered trustworthy.
They may also have BIOS recovery tools in case something goes wrong.
Unless the board is very old, it is quite straightforward to flash a BIOS.

You may have seen that I run a Sun MS U24 workstation, very expensive when it hit the market in 2007.
My present full monty configuration would have cost me well over $4.000 at the time.
Obviously, I got my box second hand.

Well ...
The BIOS on this box was a real POS from day one.

As it is not a laptop, does not need to run on solar panels or be up 24/7, I have disabled all the power management settings I could disable.
Processor throttling is taken care of by cpuidle but the rest is off or disabled.
Curiously enough, attempting to disable S states in BIOS put the box in an unusable state, requiring a BIOS wipe and reflash. (!)

In any case, you may want to consider if having any S states enabled (ie: standby/sleep/hibernate) is really necessary for you.

Best,

A.

Hello:

This is where it all starts.
It's a sign of Things To Come©.    ---> 8^/

A.

Hello:

Well ...
The Linux kernel has quite a few things enabled by default which (imho) are not needed, save in a server setup.
eg: apparmor, etc.

Nonsense ...
You were skilled enough to write a script to make it work, the first time around.  8^D

That's certainly not my case.
I would not have been able to use a package installed from the Devuan repository due to its (apparently) missing a vital part.

So ...
Does it make sense that it be in the repository if it is (apparently) incomplete?

Then it is a very good thing that you discovered this, wrote and shared the necessary script.
Like I said earlier, maybe it is a slip-up on behalf of the packagers.

Best,

A.