Where do people host their WordPress sites? If Google Trends is anything to go by, more and more webmasters now prefer cloud platforms such as Amazon Web Services (AWS). It’s fueled by the popular notion that everything in cloud is super easy – one-touch scalability, quick deployments, and convenient backups. However, things are not so rosy in reality.

A majority of WordPress sites in AWS is self-hosted. This means, the AWS customer is responsible for taking care of server updates, security, service optimization and WordPress updates. For an most WordPress webmasters, it’s a tall order. Without an experienced server administrator at hand, even simple things like WordPress update can end up in an extensive website downtime.

Today, we’ll take a look at the most common update related issues faced by AWS-WordPress site owners, and how to fix them:

1. Update failures due to FTP connection errors

A lot of webmasters follow the default server setup guide provided by AWS to create a WordPress website. But that guide misses out an important point – setting up an FTP server. So, many webmasters follow the basic procedure, and get a site running, only to see that their website updates fail with the error:

"Failed to connect to FTP Server websitename:21"

That’d be the first time a WordPress site owner realizes that an FTP account is actually needed.

Note that there are other ways to avoid this error (as mentioned below), but setting up an FTP account is safe because it allows access to only one user per website. Here’s a quick run-through of how it’s done.

a. Install and setup an FTP server

Assuming that the server is RedHat compatible (CentOS, Fedora, etc.), FTP can be installed by:

# yum install vsftpd

Then make the following changes to the FTP configuration file /etc/vsftpd/vsftpd.conf

# Disable anonymous access:anonymous_enable=NO# Allow passive connections (more reliable):pasv_enable=YESpasv_min_port=35000pasv_max_port=35500port_enable=YESpasv_address=1.2.3.4 (Replace with Elastic IP)pasv_addr_resolve=NOStart the FTP service, and set to start automatically:# service vsftpd start# chkconfig vsftpd on

Now, setup an FTP user to access the website.

# useradd wpuser -d /path/to/wordpress/files/ -s /sbin/nologin# passwd wpuser# chown -R wpuser /path/to/wordpress/files/

b. Open FTP ports in AWS security groups

At this point, the FTP service would be ready to accept connections, but Amazon’s firewalls would be blocking incoming connections. To fix this,

1. Go to Amazon EC2 console and choose “Security Groups”.
2. Choose the relevant security group, and select the “Inbound” tab.
3. Use the “Custom TCP Rule” options to allow incoming connections to port range “20-21” and “35000 – 35500”.

c. Setup WordPress auto-update

Now, WordPress updates will work fine, but a FTP password prompt will come up each time an update is done. To make updates easier, update the FTP login details in the WordPress configuration file:

 define("FTP_HOST", "1.2.3.4"); define("FTP_USER", "wpuser"); define("FTP_PASS", "FTP_PASSWORD");

[ Timely WordPress updates are important to maintain website security. Click here for a full list of steps you can take to secure your WordPress website. ]

2. Failed updates due to insufficient web server permissions

It is one thing for an update to not take off at all. It is entirely another story (and vastly more scary) if an update fails. In such a situation, the site stays in maintenance mode, and site visitors see a “Hang on” message. That’s bad juju for a website.

  Website downtimes can be very costly. From permission errors to database issues, anything can cause a WordPress update failure. In our server management services, we help AWS instance owners avoid downtime by taking care of the common failure points, such as filesystem issues, firewall settings, web server configuration, database settings, and more.   

Blessen Cherian
Member of Executive Group, Bobcares

 

 

 

The most common reason for failed updates in AWS instances is insufficient web server permissions. It means, the web server was unable to update site files because it lacked sufficient permissions to update a file. There are two ways to fix it:

a. Give write access to Apache/Nginx

The popular solution (which AWS recommends) is to assign the ownership of website files to the web server (Apache or Nginx), and give it write permission.

So, assuming that the web server user name is “apache”, and group is “www”, the ownership of the files can be changed with:

# chown -R apache:www /path/to/wordpress/files/

Directories should be given “775” permissions and files should be given “644” permissions, for that, use the commands:

# find /path/to/wordpress/files/ -type d -exec chmod 775 {} \; # find /path/to/wordpress/files/ -type f -exec chmod 664 {} \;

While this solution works, it has a serious security issue. An attacker who gains access to a web server process can access all the sites in the server. So, if there are multiple website running off the same AWS instance, a hack in one site can put all sites out of business.

b. A better solution – Run PHP as site user

Giving the web server full access to all websites is bad for security. An attacker who gains access to one site can easily then get access to all other sites.

This is where user-mode PHP engines such as PHP-FPM or SuPHP can come in handy. These PHP engines execute WordPress scripts as a normal user, and can control (or navigate to) only the directories in just one website.

To make this work, first the default PHP engine needs to be un-installed and a compatible user-mode PHP engine should be installed. Then the settings need to be adjusted for optimal WordPress performance. These things can get a bit tricky and is beyond the scope of this article.

[ Click here for an in-depth article on how to install special web modules ]

3. Issues related to Firewall, Apache/Nginx and MySQL updates

To maintain server security, it is important to keep the Web server, Database server and Web Application Firewall rules updated at all times. However, there are instances where such updates fail due to incompatible libraries, incorrect permissions or network errors.

  In AWS instances, web server upgrades can fail due to conflicting packages. It may not be immediately apparent how to fix those errors, and can lead to extensive website downtime. In our server management services, we take care to check all dependencies, and any possible conflicts before an upgrade is attempted. We even have contingency roll back systems on stand-by in case an upgrade fails for some unexpected reason.   

Reeshma Mathews
Sr. Systems Engineer, Bobcares

 

 

 

Even with the best preparation, upgrades can fail. So, it is important to have several layers of mitigation before an upgrade is attempted. Some of the steps we implement include setting up a roll-back procedure, testing the new packages in a staging server, setting up a fail-over instance, and more.

Based on the complexity of the WordPress infrastructure and cost of downtime, the downtime mitigation strategy can vary from one site to another.

In short..

WordPress websites are now increasingly being hosted in cloud servers such as AWS. However, despite its many advantages, cloud hosting can be quite hard for an average webmaster. One common issue faced by many AWS-WordPress webmasters is broken updates. Today we’ve covered the different kind of update errors, and how to tackle them.

Bobcares helps website infrastructure owners minimize downtime, and improve performance by using tried and tested server architectures. If you’d like to know how to make your server infrastructure more efficient, we’d be happy to talk to you.