We will be upgrading all servers to 5.11.12 on Friday at 11pm.  This will take about an hour.

     I will also be adding some debugging code in Debian to try to gather more information with respect to problems with the systemd configuration so it may be down for a longer period while I go through a few tweak / reboot / examine debug log cycles.

     I have received notice that there is a failure of some HVAC equipment at the Isomedia facility where our equipment is located.

     Unlike Integra, they have people monitoring these things and have already dispatched personal to repair.

     I have temperature monitors in the servers and so far they haven’t shown any increase in temperature.  Not too worried about the servers since I have a very large amount of fan in each cabinet except for the old UltraSparc machines used for dial-up radius authentication still.  They will tolerate 104F max, right now it is 82F so still a good margin of safety.

     Debian Bullseye is UP.  The systemd configuration still is not correct so it is very slow to boot but it does eventually start everything just not in the correct order and only after various timeouts.  I will figure out systemd eventually.  I keep hoping Poettering will give up and go away but he seems determined to ruin Linux.

     After upgrade to bulleys, debian will not boot with NIS enabled.  NIS (Network Information Services) is required in order for you to be able to login.  This seems to be yet another Poettering systemd induced snafu.  I am looking for a solution.

     I am in the process of upgrading debian.eskimo.com from Buster to Bullseye.

     During this process ssh sessions may be terminated and new connections will not be accepted until completion.  At least one reboot will be required.

     System maintenance completed.  There were minor issues but no major problems, everything is up and running.

     We will be performing kernel upgrades tonight between 11pm and midnight.  All machines will be rebooted at some point during that interval.

     The kernels we use are the most recent upstream kernels compiled for tickless operation.  They are available to you at:

     https://www.eskimo.com/kernel or ftp://pub/kernel

     They are available in both .deb packages and .rpm packages.  The config files are there should you care to see how I’ve configured them or in case you don’t trust me, want these features but prefer to build yourself.

     All eskimo services will be interrupted during this interval.  This includes https://friendica.eskimo.com/, https://hubzilla.eskimo.com/ and https://nextcloud.eskimo.com/.

     All the machines had finished booting by around 11:20PM however there were several that did not boot correctly and required manual intervention to bring them back up fully and there were some NFS mounts that did not mount automatically.  Everything was resolved by midnight.

     Everything was back up by 12:35 except the machine I  use for system accounting.  For some reason the virtual host network interface would not work.  I ended up deleting and re-installing the network interface, that finally got it to talk with a new Mac address.  Don’t really have any idea why the old one stopped working but after an hour and a half of hair pulling I got it running again.

     The mail server is fixed, though I still have to check NFS mount points of various servers, however, the CAUSE of the issue with mail was not, as I had suspected, the new kernel.

     Something has changed the behavior of the system such that the order of data in nsswitch.conf is being ignored, and if there is a conflict in NIS UID verses local password file, the NIS overrules.  As it happens, we had a postfix entry in NIS from a gazillion years ago when postfix was running on SPARC servers and that was conflicting with the local password file.  The order of data in nsswitch.conf was files then NIS so it should not have, and further it did not show in ls, the output of ls was correct, but postfix interpreted the NIS version.

     I booted off the old kernel and it still exhibited the same behavior so it was not caused by the new kernel as I had suspected.  Removing the entry from the NIS database, which is no longer legitimately used anyway, resolved the issue so that the server works properly, still the issue remains that nsswitch.conf is being ignored in some contexts and this is not good.