I apologize for the brief interruption of mail.eskimo.com around 9pm tonight.

     I have encountered in the past several delays when I went to post mail but I could not find a resource shortage to explain it and I had set no upper bounds on the number of processes postfix could launch so that should not have been an issue.

     Tonight I happened to have an xterm open on mail when it did this and I was able to determine the issue was that it was running out of RAM and had to swap other processes out to make room.

     I increased the amount of RAM allocated to this machine from 2GB to 8GB to address this issue but it required a shut down and reboot to make it effective.

     OpenSuse.eskimo.com is now available to you again.

     It is no longer “Leap”, it is now “Tumbleweed”, a rolling distribution which will keep it current and up to date unlike Leap.

     There is a bug in the mesa-libGL library used in the Debian derived Linux’s presently that may either break your ability to connect via x2go or break some desktop functionality.  This is because when the screen size is queried the library is incorrectly returning a rectangle of 0x0.  I know the developers are aware but no idea how long it will take to be fixed.

     In the meantime you can try a different desktop or use the web terminal or graphics console function under web apps to get a remote desktop.

     Please make note of the following URL: https://pocketnet.app/nanookeskimocom

     This replaces the page on Facebook for status when our website is down.

     It is hard to say if our Facebook page will remain.  I referred to Mark Zuckerberg as Fuckerberg after he denied a post in which I stated that I had used Kratom to relieve diabetic neuropathy because nothing that the doctors would give me worked and if it had not been for that I might have well taken my life.

     Kratom is not illegal, neither is it particularly dangerous.  So I find no excuse for having my post banned and it was information that could help others in the same boat and perhaps save a life.

     So I am looking for another alternative to post status to when our website is down.

     I have found that what kernel resource ran out on the client mail server was the number of open files.  I’ve bumped that up by 5x, hopefully that will be sufficient.

Dec 3 08:57:22 mail kernel: [371342.776244] VFS: file-max limit 194527 reached
Dec 3 09:43:33 mail kernel: [374113.872327] VFS: file-max limit 194527 reached
Dec 3 09:43:33 mail kernel: [374113.905264] VFS: file-max limit 194527 reached
Dec 3 09:45:17 mail kernel: [374217.999876] VFS: file-max limit 194527 reached
Dec 3 09:45:23 mail kernel: [374223.425007] VFS: file-max limit 194527 reached
Dec 3 09:45:24 mail kernel: [374224.590837] VFS: file-max limit 194527 reached
Dec 3 10:21:11 mail kernel: [376372.038404] VFS: file-max limit 194527 reached
Dec 3 10:21:24 mail kernel: [376385.096118] VFS: file-max limit 194527 reached

     Our client mail server got flaky between around 11AM and 1PM today.

     I am pretty sure the cause is brute force password attacks exhausting some kernel resource but I have not been able to identify the resource being exhausted.

     The reason I believe this is the cause is that in the last two days the number of IP addresses we lock out for these sorts of attacks has increased from a typical number of several hundred to over 15,000.  This is probably the result of a new Windows virus that is allowing the creation of huge botnets.  This is something we see periodically.

     I rebooted the server which restored it to normal functionality and will continue to try to determine what is being exhausted and correct it.

Last night I was up until 6AM doing reboots and backups. It is not
unusual for NFS mount points to not mount or NIS to not bind after a reboot.  Those are bugs I am used to and always check for.

But postfix not starting is unusual, I didn’t check, didn’t notice,
went to sleep and so it didn’t get fixed until someone called around 2PM.

I’ll work on some sort of automated monitoring solution.

     I will be rebooting the physical host machines Friday morning around 2AM.  This will affect most everything.  Downtime should be less than about 15 minutes if everything goes as planned.  This is to load new 5.4 kernels.