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:

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
Create a Group to connect the policy to
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.