Amazon Web Services (AWS)

There are 10 posts filed in Amazon Web Services (AWS) (this is page 2 of 2).

Updating PHP on an AWS Lightsail WordPress Stack

In October 2024 I rewrote this guide. The updated version contains less information, but it simplified to 7 steps with limited downtime (unless your install is huge) and limited chance of failure.

Feel free to read the rest of this article if you like a broad knowledge of things before you start.

Updated 27th September 2020 to consider restart of all services where restarting just apache isn’t enough, and also to share choice when it comes to import first vs SSL first as you may lose permalinks. Thanks to Peter and Simon in the comments.

Updated 25th January 2021 to add an initial paragraph clarifying that you can’t ‘choose’ a PHP version on Lightsail and to further clarify that you must first check which version of PHP a new AWS Lightsail instance will be built with to confirm it will resolve the message being displayed in WordPress.

Updated 11th May 2021 to confirm that snapshots cannot be used to update the PHP version of a Lightsail Bitnami instance.

Updated 22nd September 2022 to add a link to a guide to check which PHP version you’ll get if you spin up a new Lightsail WordPress instance. Also added a note about WordPress supported PHP versions.

Updated 7th September 2023 to add a mention of the option to use Bitnami’s bncert tool to create an SSL certificate

NB: If you’re hoping for a way to click ‘update php’ or ‘use X version of PHP’ in Lightsail, it doesn’t (at time of writing) exist. This guidance will walk you though creating a new Lightsail instance with a newer version of PHP installed and moving everything over to it.

The AWS Lightsail service is great. Click a few buttons and you have a powerful VPS with WordPress up and running for only a few dollars a month. The Bitnami integration allows you to choose from a whole set of Stacks to include upon setup. The LAMP option allows a competent PHP developer to run almost anything on Lightsail.

But after a while running the Lightsail VPS the setup is going to get stale, and because Bitnami bundles everything up, it’s not recommended to go poking around with only a few parts of it.

That’s the challenge I was faced with. Logging into the WordPress admin console a message is displayed which is telling me WordPress would prefer a newer version of PHP please. My version was old and not receiving security updates.

I read a fair bit about my options, but after looking at the choices I decided the best thing was to do an export and import onto a new Lightsail instance.

Continue reading →

Quick and dirty export of AWS Elastic Beanstalk Environmental Variables

A very quick and dirty way to export key and value pairs from web console of elastic beanstalk environments config page.

While viewing the elastic beanstalk config page containing the variable inputs paste the following into your browser console.

var strs = [], inputs = $('.properties-table input');
$.each(inputs, function(key, input){
  if(!((key+1)%2)){
    strs.push(inputs[(key-1)].value + ' = ' + inputs[key].value);
  }
})
console.log(strs.join("\n"));

Moving the default Bitnami AWS Lightsail document root

When you set up an Apache or LAMP Lightsail instance on Amazon Web Services, the default document root is /home/bitnami/htdocs/

If you are migrating to Lightsail already use something other than htdocs as your root folder, for example public_html, then you might want to update this.

Although you could creating a new app on the server to hand it, here is a simpler option which leaves the default folders and setup in place:

In /opt/bitnami/apache2/conf/bitnami/bitnami.conf add your own document root to the end of every location that htdocs is mentioned.

Then

sudo chown -R bitnami:daemon /home/bitnami/htdocs/*
sudo chmod -R g+w /home/bitnami/htdocs
sudo /opt/bitnami/ctlscript.sh restart apache

And you should be good to go.

Remote connection to AWS bitnami lightsail LAMP Mysql

I’m using Sequal Pro here, but this should work for almost any connection. I’m also going to lock to a single IP for security. You could us ‘%’ for any IP, but I wouldn’t recommend it if you are on a static ip at home of at work.

Log into ssh for the relevant LAMP instance using the browser tool on the Lightsail dashboard.

cat bitnami_application_password to get your application password. Copy it somewhere as you’ll need it shortly.

Run nano /opt/bitnami/mysql/my.cnf
Comment out the line that starts with bind-address. So #bind-address...
Exit and save the file.

For MySQL < 8 – update mysql permissions for root remote access with

/opt/bitnami/mysql/bin/mysql -u root -p -e "grant all privileges on *.* to 'root'@'1.2.3.4' identified by 'PASSWORD' with grant option"

Replace 1.2.3.4 with internet connection IP address. Replace PASSWORD with the password you copied above.

For MySQL 8 we have to create the user first

/opt/bitnami/mysql/bin/mysql -u root -p -e "CREATE USER 'root'@'1.2.3.4' IDENTIFIED BY 'PASSWORD';"

/opt/bitnami/mysql/bin/mysql -u root -p -e "grant all privileges on *.* to 'root'@'1.2.3.4' with grant option";

Restart mysql with sudo /opt/bitnami/ctlscript.sh restart mysql

Copy the IP address of your Lightsail instance. You may want to add a free static IP address, else the IP will change on restart and all this work will need doing again.

In Sequal Pro choose to add a new connection. Select the SSH tab. In both hosts, put the IP of your Lightsail server.

In mysql username put root and in password, put your password from above.

In ssh username put bitnami and in password, put your password from above.

Click to test your connection. All should connect as expected.

You’ll now need to add a database etc. Enjoy.

Security of WHM backups to an AWS S3 bucket

When you give your Web Hosting Manager (WHM) the ability to send a copy of your backup to Amazon’s AWS S3 service, you have to hand it a Key and Secret that give it that permission.

The worst option is to hand over a Secret and Key related to your own log in.

The best is to:

  1. Create a policy which
    • Only gives access to a single bucket
    • Only allows the least access required for the task
    • Only allows connections from trusted IP addresses
  2. Create a Group to connect the policy to
  3. Create a user (for the WHM) to connect to the group

For validation of connection to S3 WHM currently requires the ability to write objects, list all objects in a bucket, delete objects. Now for some this is frustratingly more than you want to hand over. In theory WHM could make do with just the ability to write to the bucket, but at the moment we have to make all those abilities available.

Luckily, the fact we’re also limiting by IP and then Secret and Key—which WHM encrypts when you submit them—should make it highly unlikely anybody else will be able to abuse the ability to delete objects.

Here is the example policy that I have in place. Feel free to copy, personalise and use:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "WHMBackupAccess",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::YOUR_BUCKET_NAME",
                "arn:aws:s3:::YOUR_BUCKET_NAME/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "YOUR_SERVER_IP/32"
                }
            }
        }    
    ]
}

If you’re in need of help putting this all together, let me know and I might expand this post to include how to do the setup inside WHM and the AWS console.