We will may be doing kernel upgrades again this Friday November 4th at the traditional time starting at 11PM pending testing of Linux-6.0.6 and possibly 6.0.7 if it should come out before then.

     There are presently two kernel bugs that are impacting us, neither very severely.  One is that there are still CPU stall splats on centos7 and scientific7 but these occur only at boot at other than slowing the boot process by a few milliseconds do not seem to have any operational impact.  This bug is known and expected to be fixed in 6.2, several months away yet.

     The other bug is more problematic.  It is an issue with squashfs that just stops working after some period of time.  Snap applications depend upon squashfs, and the one snap application that we have is Firefox on Ubuntu.  So I am testing 6.0.6 on my workstation, if squashfs continues to work throughout the week then I will be installing it next Friday on Ubuntu at least.  If there are no other fixes I probably will not do all the servers this time around since most do not use snap versions of FIrefox.  If it is not fixed then I will not be doing upgrades at all.

     Starting at 11PM, I will be performing a kernel upgrade to linux-6.0.5 on all machines requiring reboots of all Eskimo North machines.  This process should be completed by about 11:30PM.  With the exception of https://yacy.eskimo.com/, no service should be down more than about ten minutes.  Yacy will take longer because it rebuilds it’s index every time it is restarted and this takes approximately 45 minutes.

     This affects all of Eskimo North’s services, virtual private servers, shared web hosting, shell servers, e-mail, and public cloud services including https://friendica.eskimo.com/, https://hubzilla.eskimo.com/, https://nextcloud.eskimo.com/, and https://yacy.eskimo.com/.

     The 6.0 kernel has performed exceptionally well, but there is a bug that causes squashfs to fail after some time and this breaks snap applications (which are kind of broken by definition anyway). This principally affects Firefox on Ubuntu.  I have been testing 6.0.3 on my workstation and this appears to be fixed, so hopefully it will remain fixed in 6.0.5.  There is also a bug that causes a splat on boot-up on centos7 and scientific linux 7, but it does not affect the machines operationally and will not be corrected until 6.2.x according to the developers.

     If you are looking for a place to host your WordPress website, I believe we have the fastest WordPress host in existence.  Our site will load a WordPress site in under 200ms, our own loads in 148ms, WordPress’s OWN site takes 942ms to load, nearly a full second, and six times slower than ours.  Likewise when you compare us to any other major hosting provide I think you’ll find similar results.  I haven’t found another site that is not more than three times slower than our own at loading WordPress, most 10 or 20 times slower.

     For pricing, see our hosting options.  You can host with a shell with a URL of https://www.eskimo.com/~username where username is your login under our domain.  You can add a domain to an existing shell with a virtual domain, or you can choose dedicated personal web hosting or business web hosting packages.

     In addition to better speed, we also provide better security.  Most shared hosting platforms execute all website code under one user ID, usually http or apache or www-data, and the problem with that is two fold.  One is that for WordPress to be able to alter files, the permissions on those files have to have public write permissions which means ANYONE on that site can overwrite your files.  The other is that any problem with one persons code can give a hacker access to everyone else’s code.  Here, every users code runs under their own UID, this way they do NOT have to give public write access for WordPress or other content management engines to be able to modify files AND if someone’s code has a security exploit, it only exposes THEIR code and not everyone’s on the site.

A few weeks ago, I upgraded roundcube to make it compliant with php 8.x.  I did not notice at the time but this broke compose and settings.  At the heart of the issue were database structural changes that the upgrade script did not address.  To resolve this, I had to re-install with a clean database.  It is fixed now, but anything in the database, settings, signature, etc, are lost so you will need to re-enter these things.

If you get a letter like this:

    It is NOT from Eskimo, it is a phishing scam attempting to obtain your login credentials.  Do NOT respond, or at least do NOT provide them any identifiable information.  If you wish to tell them what orifice in which to insert it that is fine, except even doing that verifies to them that they have a valid spam address so better not to.  Do forward to spamtrap@eskimo.com.

Thank you.

     Kernel upgrades are complete.  Mostly went smoothly, some minor self-inflicted issues on a couple of machines but all good now.

     We will be upgrading the remaining systems including the physical hosts to the 6.0.0 kernel release.  We’ve got it presently installed on about a dozen servers and so far only one expedited RCU CPU Stall and that occurred during boot-up on the physical server with the most guest machines.  This can happen even with a good kernel because systemd’s parallelization results in large numbers of processes in run state simultaneously and this in turn can cause the RCU process not to get CPU in the 30ms allocated, but in the week we got only that one and no others where previous 6.0-rc5 and rc6 kernels generated 20-30 in the first five minutes and were basically unusable.

     No single service should be out for more than about ten minutes EXCEPT for yacy which rebuilds it’s indexes every time it restarts and this process takes about half an hour.

     The 6.0 kernel re-wrote the scheduler in a way that benefits multi-core systems.  Although the changes were largely aimed at AMD’s Ryzen CPU’s, we say substantial improvements on our Intel based servers as well, particularly in the area of scheduling latency.  It reduced the time it took our web server to load a WordPress page from about 280ms to 40ms, a seven fold improvement and the largest improvement I’ve seen from any Linux kernel upgrade since kernel .98.

     This affects all Eskimo North services including shared web hosting, private virtual servers, shell servers, e-mail, and our free federated services https://friendica.eskimo.com/, https://hubzilla.eskimo.com/, https://nextcloud.eskimo.com/, and https://yacy.eskimo.com/.  If you wish to support our free services, please consider signing up for a Linux shell or web hosting account at https://www.eskimo.com/services/free-trial/.

     Just found out a long time customer, Dave Bruels who had Interlake China Tours, passed yesterday.  I’ve spent many lunches with him and enjoyed his photos from China.  Great man and will miss him.  His wife had passed not long before and whatever the medical reason, I’m sure he passed of a broken heart.  She was a wonderful woman who fought cancer with a courage you rarely see in a human being, hiking and doing the things she loved right up to the end.

     Zorin will be down for a few days, well partially. It won’t be fully operational again for several days. Because Zorin 15 is based upon Ubuntu 16.04, there is NO support for bpfilters, and the currently Linux kernel has deprecated the old iptables filtering scheme so fail2ban and other firewall features do not work.

     Because even though Zorin is a complete rip-off of Ubuntu, if one performs a do-release-upgrade it only updates parts and you end up with a Mix of Ubuntu 16.04 and 20.04 that does not play well together.

     Thus the ONLY way to upgrade Zorin to Zorin 16, which is STILL based on a 2-1/2 year old Ubuntu, 20.04, is a fresh install which means re-installing all the applications and re-configuring everything which is several days work.  I paid for the “Pro” version of the previous release under the promise by Zorin developers that they were working on an in-place upgrade but a year and a half later it is still vaporware so I am only installing Zorin core this time around.

     The 6.0 kernel is working well, so far there has been only one expedited RCU CPU stall and that was on a virtual host during boot-up on a machine that has quite a few guests.  These can occur at this time just because ALL of the guests are busy with start-up and it simply exceeds available CPU cycles for a short time during boot-up.  If it continues to run this clean until this Friday then we’ll upgrade the physical servers to this kernel on that date at 11PM.