All services are fully operational.

     At 12:54 kernel upgrades are completed.  Sorry this took so long but one physical host failed to boot properly.  The Nvidia graphics card did not initialize properly and systemd brought the machine up into single user mode but not multi-user mode so I could not access from here.  I had to drive to the Co-Location facility which is 22 miles away and there was construction work at the I-5 / I-90 interface that made that take longer than it should have.

     I am still checking NIS/NFS mounts, but all the basic subsystems are up and running.

     I’ve tested 6.07 and 6.08 and both seemed to have resolved the issue with squashfs, so will be doing kernel upgrades.  Provided they haven’t introduced new bugs, this should eliminate all bugs of any operational consequence.  There still is an issue with startup of centos7 and scientific7 but that only generates an error message and is of no operational consequence and, according to developers, that bug will be addressed in 6.2, so still a ways off.

     This will affect off of Eskimo North’s services including our public services https://friendica.eskimo.com/, https://hubzilla.eskimo.com/, https://nextcloud.eskimo.com/, and https://yacy.eskimo.com/ as well as our own website, all the sites we host and virtual private servers.

     Downtime for any one service should not exceed about ten minutes except for yacy which takes around 40 minutes to rebuild it’s database after a reboot.  This operation should be completed by midnight.

     The FTP server is restored and somewhat better secured.

     I do not know what exploit they used because all of the known exploits for wu-ftpd I had fixed, so this is one not known, however, it would appear they only had anonymous user permissions as nothing outside of the ftp directory was disturbed.  Since the server mounts the ftp directory off of another file server via NFS, I have chattr +i the files and directories they should not be allowed to change on the host machine.  Since chattr does not work across NFS there is no way for them to change it even if they were to somehow get root access so this should largely secure the server.  I am going to create a apparmor profile for it just as an additional security measure.

     Someone apparently found an exploit that allowed them to really trash the public directory of our ftp server.  Consequently, anonymous access is extremely restricted until I’ve been able to restore the directories from backups, modify some file permissions and create an apparmor profile to limit potential damage in the future.

     6.0.6 did not fix either of the outstanding bugs affecting the current kernel on our servers, therefore I will NOT be doing a kernel upgrade this Friday.

If you have received an e-mail like this, DO NOT RESPOND to it.  It is what is known as as phishing scam, an attempt by a third party to obtain your authentication information and hack your account.  There has been a recent significant uptick in these, mostly originating in foreign countries such as Iran and Bahrain.  We do not use a password aging system here.  My personal experience with such systems is they cause more problems than they are worth.  If passwords are poorly chosen, a system that forces you to choose a new one on the spot is not likely to result in stronger passwords.

     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.