We are scheduling a server migration for September 13, 2017. This migration will affect some of our clients.

This migration is scheduled to start on Wednesday, September 13th at 7PM CDT. The total time to complete the migration is unknown, but we are setting aside 24 hours just to be on the safe side. IMPORTANT TO NOTE: Individual accounts will not be down for the full 24 hours. This migration is done on an account-by-account basis. Your account will likely only be down for 15 to 30 minutes (if that long) at some point in this migration window.

START TIME: Wednesday, September 13 7PM CDT
END TIME: Thursday, September 14 7PM CDT (Estimated)
IMPACT TIME: 15 to 30 minutes per account, perhaps less

This migration will consist of an IP address change. However, if your account is using our nameservers or nameservers we have designated for you, then the IP address will change automatically. This is because the IP change will be made in synch with our DNS servers. If you are not using our nameservers then we cannot make the DNS change for you automatically. We encourage you to use our nameservers or nameservers we have designated for your account for this reason.

If you are using bookmarked links to access your cPanel or Webmail, those links may no longer work after this migration. To access your cPanel and Webmail, it is always best to use the links:

cPanel – http://yourdomain.com/cpanel
Webmail – http://yourdomain.com/webmail

Replacing yourdomain.com with the domain name of the account you want to log into.

To find out if your account is affected by this migration, enter your domain name at:

https://www.amscomputer.com/maintenance091317.php

If you have any questions about this migration you can reply to this message or submit a support ticket at:

http://www.amshelp.com/support

Changes are coming to our servers later this summer. Some of these changes may require you to update the scripts you have on your website.

We will be upgrading the database service on all of our servers starting at the beginning of August 2017. This upgrade is due in part because the current versions have reached or are going to soon reach their end of life. The upgrade should also give a performance increase to scripts and services that utilize the database service.

Quick Summary: If you don’t read this full post, the main take away from this is that you need to insure that all of the scripts on your website are up to date. If you are using old, outdated, and especially end of life’d scripts, then you may encounter problems with this upgrade.

How will this affect you?
The main issue concerning your account in regards to this upgrade is going to be how up to date your scripts are. If the scripts on your website are up to date then you should not notice any change, perhaps a performance boost. If however your scripts are not being kept up to date, then you may experience your website being offline. Keeping your scripts up to date is really just a great idea in and of itself. But if you are using ancient versions of the script, then those versions may not be compatible with the new database server protocols. Extremely old versions of Joomla! are known to have issues with this. Other scripts may also have problems. If you are using plugins, components, addons, or themes tied into the script, you will want to be sure that they are up to date as well.

Newer software, such as this upgraded database service, is meant to provide better performance by optimizing the way it handles data. This means that it can’t continue to support the way older scripts handle data AND bring a performance boost. Continuing to support old and outdated software would result in a performance degradation in the database service. Likewise, new versions of scripts are developed to boost performance and by continuing to use older versions of the script you are being plagued by a performance degradation.

Keeping your scripts up to date, not only helps with the security of your account, but it also helps with the performance of your account.

I don’t want to or can’t update my script
If you can’t update the script on your account, then you need to find out why. If the task of updating the script is too technical, then you may need to hire a qualified professional to update the script for you. If you are unable to update the script because the developer or vendor is not releasing updates, then you probably should consider a different script. There are a lot of website scripts out there. Some are well written and properly maintained by the developer or a team of developers. Many others are poorly written and are never maintained. Avoid using the poorly written and unmaintained scripts.

Not wanting to update the script unfortunately is not a valid excuse. The majority of our client base keeps their scripts up to date. It is not fair to them that they cannot reap the benefits of the performance increase a database service upgrade provides just so the handful of other clients that refuse to keep their scripts up to date can keep their scripts running.

Failing to keep your scripts up to date is a dangerous proposition anyway. Security holes are published for out of date software, this is how abuse and malicious actions can happen on your account and server.

Will there be any downtime associated with this upgrade?
Our intention is to keep downtime to a minimum. There will be some downtime involved in this upgrade, but just how much is unknown. It could be 5 minutes to 2 hours, although our hope and plan is to keep this closer to 5 minutes. We really can’t do this upgrade without incurring at least a small amount of downtime.

When will my account be upgraded?
We can’t provide an exact timeline for that. Our plan is to upgrade a few servers at a time all beginning on August 1, 2017. How many servers can be done per day and how long it is all going to take is really up the air.

What are the technical aspects of this upgrade?
We will be upgrading the database server to MariaDB. MariaDB is a fork of MySQL. Much of the web hosting industry is switching to MariaDB and MariaDB is known to give real performance gains. MariaDB still uses MySQL bindings for scripts and connections, so it’s really a drop in replacement for MySQL. Nothing changes with your database structure. Just the software that maintains that database, currently MySQL, will be switched to MariaDB.

A new version of Joomla! was released last week. This release fixes a huge security hole in Joomla!

Information about these security holes can be found directly from Joomla!’s website:

Joomla! 3.6.4 Released
Revised Assessment of 3.6.4 Security Release

Basically this vulnerability allows anyone to create an administrator user on your Joomla! website. When they have administrator privilege to your site, they can log in and do anything.

You must upgrade your Joomla! script to 3.6.4 as soon as possible!

This point cannot be stressed enough.

If your account is hacked, if someone gains administrative privileges to your web hosting account, they can do anything to your account. YOU MUST UPGRADE TO JOOMLA! 3.6.4 AS SOON AS POSSIBLE!

To update your Joomla! script, log into your administrator dashboard. Click on Components -> Joomla! Update and follow the instructions.

You also need to check for users that may have been added if your Joomla! script has been hacked. To do that click on Users -> User Manager (just click on User Manager)

You will then see a list of Users. We don’t know who all is suppose to be a user and who isn’t. This is something that you need to know. If you find users that shouldn’t be there, then you have been hacked. If you’re hacked, all bets are off. You will need to clean up your user list, removing users that aren’t suppose to be there.

If you find users on here that aren’t suppose to be there, then you have been hacked. If you’ve been hacked, then your account may contain backdoors and other malicious files. If you are hacked, your best course of action is to reset your account because the integrity of your account is now in question. You don’t know what malicious or abusive files may exist on your account.

If you are going to use Joomla! on your website, you need to stay up to date with Joomla! releases. When Joomla! releases a new version you need to update to it, immediately. It doesn’t do you any good if Joomla! releases a new version and you do not update. You have to update the script on your web hosting account to be protected from the security holes that update provides.

Steven
AMS Support

When I hear the terms PHP-Selector or MultiPHP in the context of shared web hosting, this usually causes me to cringe a little bit. To be fair, there’s really nothing wrong with being able to select different PHP releases, my main gripe is with the ability to select old and outdated releases of PHP using these methods.

To better understand this, consider the lifetimes of a particular version of the PHP language. PHP, as some of you may be aware, is a web programming language. PHP is developed by the folks over at php.net and they release new versions from time to time. Typically a PHP release version (i.e. PHP version X.Y) will have a lifetime of about 3 years. During that lifetime various security releases may be released (i.e. PHP version X.Y.aa). These security releases rarely change any functionality but serve to fix security holes that have been discovered in those releases.

Why is end-of-life important? We covered that in a blog post back in October 2013. Basically, programmers and developers eventually have to end support for something so they can move on to bigger and better things. When a PHP release reaches end-of-life, that means it’s no longer being actively developed or maintained by the PHP developers – who are the ones that created it.

So this begs the question, from a pure security perspective, why should any end-of-life release of PHP be used? And that’s a very good question. The answer is that it shouldn’t be used. At the time of this blog post (September 2016), two PHP relases remain in life, PHP 5.6 and PHP 7.0 (see http://php.net/supported-versions.php). What this effectively means, is that as far as the PHP developers are concerned, PHP 5.6 and PHP 7.0 are the only releases that should be used. Yet, the web hosting industry is littered with PHP Selectors and MultiPHP systems that allow:

• PHP 5.5 (end-of-life: July 2016 – 2 months ago)
• PHP 5.4 (end-of-life: September 2016 – 1 year ago)
• PHP 5.3 (end-of-life: August 2014 – 2 years ago)
• PHP 5.2 (end-of-life: January 2011 – 5.5 years ago)
• PHP 5.1 (end-of-life: August 2006 – 10 years ago)
• PHP 5.0 (end-of-life: September 2005 – 11 years ago)

and more being made available. Why?

A common refrain I see for reasoning this is – “My script does not work on the latest release of PHP”. This is probably true, but instead of caving in and looking for a one-click easy solution of providing an outdated release of PHP, why not ask: “Is the script up-to-date and being kept up-to-date?”

We have already detailed in a previous blog post how the so-called Panama Papers were compromised due to the fact that the law firm holding the papers was using outdated versions of WordPress and Drupal on their website. So if you want to keep your website and the information behind your website safe, keeping your scripts up-to-date is one of the best thing you can do. Also worth mentioning is that a hacked or compromised script can have adverse affects for other users on a shared hosting server. If a website is hacked and compromised on a server and used to send out spam, that can have an adverse affect on other websites hosted on that shared hosting server..

So if you are using a script or CMS that does not work on current and supported releases of PHP, then that should tell you that the script or CMS you are using is out-of-date. If your script or CMS is out-of-date, it really doesn’t matter how patched up or hardened the underlying PHP release is, if your script or CMS is out-of-date, chances are great that it is vulnerable to some type of security exploit, and no amount of hardening of the underlying PHP release is going to protect you.

Being able to select old releases of PHP to allow you to continue to run your outdated script or CMS may look nice. It may allow you to keep your website up longer without any intervention on your part. But please understand, it’s just masking the problem that your script or CMS may be vulnerable to a much larger and much heavier attack. Hosting companies and administrators that suggest using these out-of-date PHP releases as a solution to your problem, either don’t understand enough, or don’t care about the security of your website or the well-being of other customers on the server and instead are just looking for an easy fix.

Steven
AMS Support

We have recently run into a few issues where users were attempting to parse PHP code in .html files. We don’t recommend this, and this post is meant to explain why.

First of all, an understanding of file extensions need to be made. Technically speaking, a file extension doesn’t really mean anything. In Windows, a file extension tends to have more meaning than in other operating systems, like Linux (which is what our servers run on). File extensions are largely hidden in new versions of Windows, but people who are familiar with older versions of Windows (and DOS) may remember that files with a .exe extension were able to be “run”. These were “executable” files that would start a program or application. Likewise a .doc file would open up the file in Microsoft Word. A .txt file would open the file up in notepad.

But technically speaking, you could just as easily open up Notepad, type up some notes, and save that file as “notes.exe”. All this would really do is confuse other users because they would expect “notes.exe” to run something and in order to open and read the file, users would have to know to open the file directly from Notepad.

In this sense, we can see that a file extension’s main purpose is used to categorize files. We have been brought up in a culture where .exe file extensions are meant to be “executable”, .txt files are meant to be simple text files that can be read by Notepad, .jpg files are image files meant to be opened by an image viewer. The extension of the file is meant to serve as a way to quickly and easily categorize what type of file this is.

You can think of this also as a filing cabinet. You may have an insurance statement that you would most likely file in the Insurance folder. A bank statement would be filed in the folder label Bank Statements. Can you put the insurance statement in the Bank Statement folder? Sure, nothing will stop you. But when you go to look for that Insurance statement 2 years later, where are you going to looK? In the Insurance folder or the Bank Statement folder? A statement that is misfiled can lead to a lot of headaches later down the road.

The same is true for the web experience. When working in website development there is some expectations when categorizing files. Files with a .jpg extension are expected to be image files. Files with a .css extension are meant to contain Cascading Style Sheets code. Files with .js extensions are expected to contain Javascript code. Files with .html or .htm extensions are meant to contain raw HTML code. Files with .php extensions are mean to contain PHP code. That is the expected behavior of these extensions. Can you put HTML code in a file and use a .jpg extension? Sure, but this is going to severely confuse your browser and probably won’t render correctly for your website visitors.

The same is also true about putting PHP code in .html or .htm files. This just isn’t the expected behavior. PHP code has to interface with the back-end webserver. How this is done gets technical very quickly, but just know that the web server has to talk to a system on the server that understands PHP code and interprets this back to something the web server can understand. By default the web server only sends code from .php files to this system to be interpreted. While it is true that the server can be made to send .html or .htm files, it is just not the default behavior. So any change in the way PHP operates or any change to this webserver -> PHP interface system, non-standard setups (like PHP code in .html files) may get overlooked.

The TL;DR version of this is to always be sure to use file extension properly. This is going to save you a lot of headaches later on, if you follow the expected behavior for any file extension. If you want to use PHP code, you should always use a .php file extension for that file. If you choose to operate outside of this expected standard behavior, do not be surprised when you encounter rendering issues.

Matt
AMS Support