I will be rebooting all Intel-based servers later this evening or very early Saturday morning (near midnight), in order to load new kernels that address yet another newly discovered Intel exploit.

     When I recompiled the client mail server the day before yesterday, it overwrote the existing aliases file breaking all aliases and mail lists.  This has been fixed.

     If all goes well, and it hasn’t the last two nights, I hope to replace the client mail server, currently based upon Centos6, with a new mail server based upon Ubuntu 19.10.  This will come with some newer spam tools that hopefully will result in fewer abuses like the forgery from mail.eskimo.com alleging that your mail quota was full.

     At some point, Canonical, the folks behind the Ubuntu Linux distribution that we use on most of our servers, opted to move where firewalld looks for iptables, iptables-restore, ip6tables, and ip6tables-restore from /sbin to /usr/sbin but neglected to move the actual commands there, thus causing firewalld to fail upon startup.  And rather than no firewall being started it seemed to result in random ports being blocked.

     This condition broke the ftp server ftp.eskimo.com so that it would not function in active mode and sometimes not even in passive mode.  This has been repaired.

     If you are sitting behind NAT on a personal home router and do not have a static IP, you still may need to use passive mode but at least that will work now.

     I also want to remind people that IF you have a public incoming or uploads directory, the mode must NOT offer public read permissions or it will not work.  Our ftp daemon will not allow the use of mode 777 directories since this is used and abused to distribute viruses, pirated software, child porn, and other nefarious content.  Instead these directories should be mode 733, chmod 733 incoming.

     Mail.eskimo.com should be completely fixed now but I will be replacing it entirely shortly as it is an old server based upon CentOS6, the only one not modernized, and I am preparing a new server to completely replace it which will be based upon the current release of Ubuntu and upgraded as Ubuntu upgrades.

      In the meantime however, I have replaced postfix with the most current version, 3.4.7, as well as openssl with 3.0.0, so all modern encryption protocols should now be supported.

     Authentication was broken, that is now fixed.  Sending mail will work from local shell servers, from web mail, but NOT from devices off of our local network with encryption.

     I am working on fixing this but unfortunately it is somewhat involved so will take a little bit yet.

     I have discovered that what happened is that last night I recompiled postfix in order to add a needed feature to make it work in some situations that previously it did not.  I was missing a necessary library on the system when I first compiled it and this caused it to omit adding that feature.

     What I did not realize at the time was that installing the newly compiled version would rudely overwrite my existing configuration files.

     I can not boot the backup because init, the master daemon is damaged.  So I am trying to extract the configuration files from the backup.

Last night I made some changes to postfix and inadvertently broke start tls and tls.  I am working on correcting this.  You can send mail from shell using alpine but presently web mail and portable devices using encryption will fail.

      Upgrade is failing to get packages from the repository and so I am going to re-install OpenSuse.  It will be down until some time tomorrow evening.

     Ran out of disk during an attempted update of OpenSuse from 15.0 to 15.1.  Had to halt machine in order to resize the disk image and partitions to accommodate the update requirements.

     All the planned reboots have been completed and NIS/NFS connectivity verified, but Centos7, Scientific7, and MxLinux were all a little slow out the gate with kernel updates so I have to reboot those today.

     Sometime after tonight I’ll be rebooting the majority of servers to install kernel upgrades that address some newly discovered security concerns in Intel processors.  Not all services will be down at once except for a brief period when we reboot the server with the /home user partition.  That should take about fifteen minutes.  This will happen sometime after midnight, probably closer to 2AM.