Assuming you are operating a NAT, have you opened the email ports (25, 143, 443, 587, 993) in your external (router's) firewall and forwarded them to your mail server's ip?

Horses for courses. If a drive is rated for 70C I'd not want to load it to run at that continuously.
I have a BX500 myself in my email server but its very lightly, if continuously, loaded and currently sits at 28C (max 31C). Hopefully it will continue to provide good service. Maybe I should add disk monitoring (currently I just monitor the CPU).

Rolfie, on my box selecting open reverts the sidebar to show my home but the main pane still shows what's in /var/log/. You can then still open another log by double-clicking on it in the main pane, and the updated list of those you have opened reappears in the side pane.
It is all very olde-worlde gnome as I remember it though.
No doubt the newer systemd alternative is slicker - though I gather the binary blob they have made of logs is apparently more fragile if things crash.

These might be on some help:

https://dev1galaxy.org/viewtopic.php?pid=20903#p20903
- my fixed version of /etc/init.d/nvidia-persistenced.
and
https://dev1galaxy.org/viewtopic.php?pid=20917#p20917
- which explains that you can probably also get away with simply removing or disabling nvidia-persistenced as for most use cases it's not needed unless you want to use CUDA.

Devuan Beowulf, like Debian Buster is the stable version, so doesn't get the latest and shiniest version of applications automatically.

Mint and Ubuntu are based on the unstable versions. If you really want new and shiny in everthing then you need to upgrade to Ceres.

Beowulf does however receive any security fixes, albeit with a slight delay, which isn't always bad since security fixes can also have bugs (vide the latest fiasco with grub).

For example the version of Firefox supplied on Devuan is Firefox-esr (the 'enterprise' version), which only resyncs with the latest Firefox once a year. However it does get all the monthly security fixes inbetween. At the moment, although there is a  newly resyced version we will continue to get the security fixed older version for an overlap period.

You can configure Devuan to install updates automatically using the unattended-upgrades package.
This can be configured to run daily from cron, or if you don't keep your computer on all the time but hibernate or suspend , from anacron. which runs a daily check and conditional install when you first resume. You get a email notification if it upgrades anything. I use it but only for security upgrades.

There is also a notifier package (not part of the official Devuan repositories) written by MiyoLinux (see https://dev1galaxy.org/viewtopic.php?pid=22152#p22152) that notifies you, and allows you to install upgrades. It's not quite as slick as the applets in Mint and Ubuntu but is quite flexible. However it doesn't yet work in Ceres: another example of how the Unstable version may break things.

Also if you find you really need a feature in a more recent version you can often get something newer from backports. I  use a LibreOffice backport as its an application where I'm always looking for new shiny but wouldn't search for a postfix backport as I value the stability of the latter. I did backport dnscrypt-proxy as I needed a fix in a feature I used and the backport had it.

Bit surprised by you find that

as that's not my experience with either Ascii or Beowulf (albeit I use Cinnamon rather than Xfce). Which hardware is your system not recognising?

My own choice is to use dnscrypt-proxy, which:

1) Gives you a wide choice of DNS provider, including Cloudflare, using either DoH or Dnscrypt. You can choose from a large number of non-logging (or at least services that say they are) and/or DNSSEC and/or filtered/non-filtered DNS providers.

2) You get periodically to randomise your DNS provider, so no one service sees it all.

3) You will usually choose nearer DNS providers with a lower RTT than Cloudflare (at least here where Ii am in the UK).

4) You can cache your queries, reducing what hits your provider and proving near-instant lookups on your most used sites.

5) You can select from multiple blocklists.

6) it works for all your internet traffic, not just your browser. On mine I also provide a DNS service for other nodes on my network.

7) In the latest versions you can set up a (set of) DNS relays between you and the DNS provider, which masks your IP from them and your query form the relays.

In Firefox (about:config) you set your Network.TRR.mode to 5, so bypass the internal DoH with /etc/resolv.conf pointing to your dnscrypt-proxy. There is also an option that allows you to provide a DoH server for Firefox, which then connects to the internet using any of the other dnscrypt-proxy options.

Just to provide another example.

Beowulf/Cinnamon, default terminal is gnome-terminal and I've not noticed any issues using it (including a display from the xpra server over ssh on another machine), but I'm running it from an applet, so I don't see any messages.

However:

marjorie@grendel:~$ gnome-terminal
# watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)
# unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1)
# watch_established: "/org/gnome/terminal/legacy/" (establishing: 0)

and child terminal opens OK.

marjorie@grendel:~$   

And then as sudo:

marjorie@grendel:~$ sudo gnome-terminal
# posix_spawn avoided (fd close requested) 
# watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)
# unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1)
# watch_established: "/org/gnome/terminal/legacy/" (establishing: 0)

and child terminal opens OK as root in my home directory.

root@grendel:/home/marjorie#      

I don't have ash, nor xterm for that matter.

Logged on this afternoon and unattended-upgrade has just updated grub-common.

Start-Date: 2020-07-31  12:10:26                                       
Commandline: /usr/bin/unattended-upgrade
Requested-By: marjorie (1000)
Upgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u1, 2.02+dfsg1-20+deb10u2)
End-Date: 2020-07-31  12:10:28 

Maybe this fixes the problem?

https://linuxsecurity.com/advisories/de … e-17-52-37

Package        : grub2
Debian Bug     : 966554

The update for grub2 released as DSA 4735-1 caused a boot-regression
when chainloading another bootlaoder and breaking notably dual-boot with
Windows. Updated grub2 packages are now available to correct this issue.

For the stable distribution (buster), this problem has been fixed in
version 2.02+dfsg1-20+deb10u2.

We recommend that you upgrade your grub2 packages.

For the detailed security status of grub2 please refer to its security
tracker page at:
https://security-tracker.debian.org/tracker/grub2

Oddly 'grub-common' is the only grub package I have on this PC, my other (my mail server) has 'grub-common', 'grub2-common', 'grub-pc' and and 'grub-pc-bin'. Both were fresh Beowulf Beta installs.

As I understand it the correct way is to re-build the .deb package from the source using deb_helper.
There a tutorial on the overall process here: https://wiki.debian.org/BuildingTutorial.
Though the tutorial uses an example where you want to change the source code (and recompile) not just the packaging.

Essentially to create a Devuan compatible .deb you need to:
1) add a suitable init script to the files tree (your /etc/init.d/zoneminder). As has been pointed out by Head_on_a_Stick you can generate one from the systemd service file using the sysv2d.sh script.
2) Adding a Debian rule to generate the sysvinit additions to the postinst and postrm scripts.
The rule will be a parametrisation of the deb helper program dh_installinit.
3) Change the version number and annotate the change.
4) If you then want to submit as a bug to Debian create a diff on the original and submit  it with the bug report.

When you've recreated your .deb you might see in your postinst file something like this :

# Automatically added by dh_installinit/12.1.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
	if [ -x "/etc/init.d/chrony" ]; then
		update-rc.d chrony defaults >/dev/null
		if [ -n "$2" ]; then
			_dh_action=restart
		else
			_dh_action=start
		fi
		invoke-rc.d --skip-systemd-native chrony $_dh_action || exit 1
	fi
fi
# End automatically added section

This example (for chrony) enables (using update-rc.d) and starts (using invoke-rc.d) the init.

The corresponding addition to postrm is:

# Automatically added by dh_installinit/12.1.1
if [ "$1" = "purge" ] ; then
	update-rc.d chrony remove >/dev/null
fi
# End automatically added section

However some maintainers don't provide an init file and don't run dh_installinit, which is where we get problems.

Here is an example of the rules for another deb (nftables) that doesn't. As you can see, dh_installinit is called but just with the -n parameter and so doesn'r run. Run without any parameters it will create the postinst code to enable and start the init and the postrm code to remove it. For some programs you might not want to have enable or start (in this case for dh_installsystemd they are turned off by parameters --no-enable- -no-start).

#!/usr/bin/make -f

ifeq (,$(filter terse,$(DEB_BUILD_OPTIONS)))
export DH_VERBOSE=1
endif
export PYBUILD_NAME = nftables
export DEB_BUILD_MAINT_OPTIONS = hardening=+all

configure_opts	:= --with-xtables --with-json --with-python-bin=/usr/bin/python3

override_dh_auto_configure:
	dh_auto_configure -- $(configure_opts) --

%:
	dh $@ --with python3

override_dh_fixperms:
	dh_fixperms
	chmod a+x debian/nftables/etc/nftables.conf

override_dh_installsystemd:
	dh_installsystemd --no-enable --no-start

override_dh_installinit:
	# dh_installinit will try to mess with /etc/init.d/nftables in
	# the maintainer scripts, but we don't ship it
	dh_installinit -n

override_dh_installexamples:
	dh_installexamples -XMakefile
	# upstream examples are installed in by the 'install' target to '/etc/nftables'
	mv debian/tmp/etc/nftables/*.nft debian/nftables/usr/share/doc/nftables/examples/
	rm -rf debian/nftables/etc/nftables

Amen.

If you're a system admin and don't want to use/don't have a root login/ password (I don't) then open a user terminal and type:

~$ sudo nemo

or whatever's your graphical file manager and then at the prompt enter your user password..
This work just as well.

nb. I use Cinnamon (I'm another pre-systemd Mint refugee) so my main file manager is nemo and my file editor is gedit.

I find this a particularly useful way of finding my way around/editing system files when I've ssh -X in order to work on a remote PC.

Then copy your_init_script to /etc/init.d/ Make it executable (+x). Change the owner:group to root:root.

You'll then need to run:

sudo update-rc.d your_init_script defaults

to set up the /etc/rc* files (which are symlinks back to your_init_script)

and

sudo invoke-rc.d your_init_script start

to start the daemon immediately.

sudo service your_init_script start

should also work.