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.

     If there is an application on Debian that you need and is not present on one of these other servers, please e-mail support@eskimo.com or submit a ticket with https://www.eskimo.com/support/osTicket/.

     There will be multiple interruptions to Debian while I troubleshoot this issue further.

     Seem to be going down one rabbit hole after another.  I think somehow the system image for Debian has gotten severely corrupted, so I am restoring it from backups made on May 3rd, then will apply updates and bring it current.

     I expect Debian to be operational around 1700 Pacific Daylight Time.