I am discontinuing opensuse.eskimo.com shell server because users have been unable to authenticate for several months owing to a broken library in opensuse that incorrectly attempts to originate connections to ypserv on an unprivileged port.

     I filed a bug report with Suse several months ago, nothing has come of it in the way of a fix.

     I attempted to login to the bug reporting system but was informed that authentication methods had changed and I would have to convert my password.  I’ve tried to do that many times but their system keeps telling me the system module is down.

     Obviously maintenance is not happening there anymore so I’m going to abandon OpenSuse and take suggestions for a new Linux distro to replace it.  I prefer distros that are based upon .deb packages verses RPM’s given the choice, the former just has much less tendency to scramble it’s database and have problems with dependencies.

     Iglulik spontaneously booted today.

     NFS partitions did not properly remount on one mail server, this may result in some spam not being properly filtered and mail that should have gone to spam and/or other folders, instead being placed in your INBOX.  I apologize for this inconvenience.

     I have modified systemd unit files for postfix to make these mounts a requirement for postfix to start but unfortunately there is no provision to kill postfix if they go away.  I may be able to script something if I can find a way to check a mount point without the check itself hanging.

     5.7.6 appears to have resolved NFS issues that came into being in 5.7.0 through 5.7.4 and is now the active kernel on our server and debian based systems.

     Going to take the mail subsystem down for about 1/2 hour to troubleshoot kernel problem as well as vps1-7 virtual private servers.  Had planned this for yesterday but problems building kernels delayed.

      This evening I will be booting ice into a new kernel to test NFS.

      I am working with a Linux kernel developer to debug some kernel nfs server issues that are new to the 5.7.x kernels.  I plan to boot into the new kernel around 11pm, then things may or may not be interrupted for some time if NFS does not work while I gather information that may be helpful to the kernel developers before reverting to a known good kernel.

     This will affect mail, and also vps1 through vps7 but not higher numbered virtual  machines.  The virtual machines will only be down for minutes during the boot, mail be unavailable for a longer period as it is what is affected by the NFS problems and it may take some time to gather all of the necessary information to allow a fix to be developed.

     Between 11PM Sunday June 21st and 2AM Monday June 22nd:

     vps2, vps3, vps4, vps5, and vps7 about 1/2 hour each for imaging.

     scientific7, uucp, and mx1 about 1/2 hour for scientific7 and about 15 minutes for the other two.  mx1 will not be service affecting as mx2 will handle the traffic while it is down.  You can use centos7 as an alternative to scientific7 during it’s downtime, they are essentially the same code base.

     mint, ubuntu about an hour each, ftp/web about 1/2 hour.

     Mint and Ubuntu have similar code base to Debian, Julinux, and Zorin, suggest using one of those as alternate during this work.

     Webmail, imap, and pop were unavailable from 7:15PM to approximately 8:30PM.

     I restarted mail to test a new kernel before I restart the large servers tonight.  For some reason dovecot automatic start failed and I did not realize it at the time.

     I got a call just before 8:30, checked, and found it was not running and restarted and it started fine so no idea what went wrong earlier.

     An update; I discovered what went wrong earlier is that at some point Ubuntu changed where dovecot / systemd expected the PID file to be and it required manually editing the unit file.  I did that so it should be okay in future restarts.

     Saturday morning just after midnight Pacific time, I will be rebooting servers into a new kernel.  If this kernel behaves properly we will remain on 5.7.4, if not I will need to reboot again to 5.6.0.  5.7.0-5.7.2 has not functioned properly as NFS server.

     The reboot did not in and of itself fix the problem but everything restarted did point me at the source so I could fix it.  It is completed, everything should be functional again.

     I have to reboot a machine because the NIS subsystem, which is how authentication information is pushed to all machines, is not working properly on this machine.

     This will briefly make e-mail unavailable as well as the shell servers centos7, centos8, scientific7, and fedora.