Last night’s upgrade broke something in the postfix configuration of the mail client server used for sending mail. Unfortunately it is giving only an extremely generic error making identifying what it is difficult. It claims the server is misconfigured yet postfix check shows no errors. Argh!
I am working on it.
All Debian based kernels were upgraded to 5.12.4.
This took an hour and 15 minutes to complete on the physical server hosting the web server because the iomemory drivers did not want to compile under 5.12.4. After much pulling of hair I found that it was a libc6 version mismatch between the machine that I installed the kernel on and the one I built it on. The DKMS module for iomemory required this.
Mail has been upgraded to ubuntu 21.04. Most of the servers here are on long term releases but dovecot was barely usable on the 20.04 release prompting a rapid upgrade to a short-term intermediate release.
The web server will be down longer than normal after tonight’s kernel updates because I have to recompile a driver used with the flash drive for the newer kernel.
The client mail server, mail.eskimo.com, will be intermittently available for several hours after the kernel update as I will also be performing an operating system update.
We will be doing kernel upgrades on all of our servers. Expected time frame 11PM-11:30PM with perhaps a straggler machine or two. We’ve had a lot of systemd issues recently that has made startup less than 100% reliable.
This will affect all of our shell customers and web hosting customers as well as https://friendica.eskimo.com/, https://hubzilla.eskimo.com/, and https://nextcloud.eskimo.com/
Expect mail issues from outlook.jp and perhaps outlook in general, I do not know to what degree they share services, but outlook.jp appears hacked to death recently and we’ve been receiving a lot of phishing scams from it. I’m blocking scam addresses as I become aware but this sort of thing will eventually cause a lot of crap to back up on their servers, mail errors to result, and ultimately fail2ban will ban affected servers. I’ve also sent them to their abuse address but I’ve never received other than a bot response and these continue so obviously they are not addressing the problem.
Outgoing mail is fixed except it is still shy on memory. I meant to reboot last night to increase memory but issues with Debian kept me preoccupied. I will reboot mail later tonight to double the memory allocation.
I made some changes to the client mail server yesterday in an attempt to relieve some memory overload issues without rebooting and in the process broke mail in a way that it is causing mail to get stuck in queue. I’m working on correcting this. Your mail is not lost and will get sent on it’s way out of queue as soon as I determine what is misconfigured.
Debian is back up, with home directories and mail spool this time.
I made an error in editing the /etc/fstab to fix the swap partition and edited out the NFS mounts for home directory and mail spool. I’ve fixed that but I’m making a backup of the fixed machine before I bring it back into service.
Debian is restored to service and available.