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.
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.
I am planning on rebooting mail client server around midnight tonight in order to increase memory allocation because there were still a few failures resulting from being unable to allocate enough memory.
Debian will be back up in about an hour. I identified the problem as a bug in systemd-sysusers which causes it to hang if NIS is used with containers and avahi is not present.
Avahi is not present because I do not want it “discovering” potentially insecure machines on the network and prefer the machine knows only about what I tell it.
Since NIS is not optional and snap is, I’ve removed snap and that made Debian boot properly. I am now making a backup to capture the current working configuration. That will conclude in about an hour at which point the machine will be returned to service.
Even after restoring from backup, debian still has problems, please use one of the other Debian based servers such as Ubuntu, Mint, Julinux, or Zorin while I sort this out.
There will be multiple interruptions to Debian while I troubleshoot this issue further.