On desktop you can install KDE connect, or in my case as I use gnome I installed GSConnect which adds to the ubuntu gnome top bar nicely.

I had to add a couple firewall rules to allow kde connect protocol through with ufw:

sudo ufw status  # first checking it's running  
sudo ufw allow 1716:1764/tcp  
sudo ufw allow 1716:1764/udp  

On my pixel phone I downloaded KDE connect

From my desktop > top right dropdown > a new GSConnect option showed and I was able to connect to my pixel.
This then notified my phone and I accepted the connection.

Inside the app on my phone, under some of the default controls are text links to enable additional permissions for things like sms etc. where I enabled the ones I wanted to get SMS access and notifications as that's my primary use, as well as occasional clipboard sharing.

Desktop menu:

Phone app:

But, I'm paranoid and I want another backup just in case somehow I loose access to the account through a hack or some other issue.

An easy backup solution for this on linux/ubuntu is with rclone.

Install with:

sudo apt install rclone  

Once installed, we can configure it via:

rclone config  

This will ask you questions about the setup.
Choose "n" for a new remote.
Select Google Photos as the cloud service.
Follow the instructions to authenticate with your Google account.
It'll ask about setting a client_id, though possible to use the defaults and leave this blank, it's better to use your own for both a quota view but also potentially for privacy.

rclone has docs on creating a client to follow with
https://rclone.org/drive/#making-your-own-client-id
which you'll setup with https://console.cloud.google.com/apis/api/

I've created the following script backup-google-photos.sh which then automates backing up a few key folders and all photos split out by year & month for a little organisation, I've saved this in ~/Pictures/GooglePhotosBackup/:

#!/bin/bash

echo "Backing up Google Photos!"

echo "=> removing previous log file"  
rm ~/Pictures/google-photos-backup.log

# backup the smaller album, feature and shared-album folders first
echo "=> backup albums:"  
rclone copy googlephotos:album ~/Pictures/GooglePhotosBackup/album --progress --transfers 8 --bwlimit 50M --log-file ~/Pictures/google-photos-backup.log --log-level INFO  
echo  
echo "=> backup featured:"  
rclone copy googlephotos:feature ~/Pictures/GooglePhotosBackup/feature --progress --transfers 8 --bwlimit 50M --log-file ~/Pictures/google-photos-backup.log --log-level INFO  
echo  
echo "=> backup shared-albums:"  
rclone copy googlephotos:shared-album ~/Pictures/GooglePhotosBackup/shared-album --progress --transfers 8 --bwlimit 50M --log-file ~/Pictures/google-photos-backup.log --log-level INFO  
echo

# then in media, it contains sub folders for all, by-day, by-month and by-year
# photos repeat in these so rather than download 4 copies of each image/video
# i'm currently just backing up the by month ones so we have a little folder structure
echo "=> backup all photos by month:"  
rclone copy googlephotos:media/by-month ~/Pictures/GooglePhotosBackup/media/by-month --progress --transfers 8 --bwlimit 50M --log-file ~/Pictures/google-photos-backup.log --log-level INFO  
echo

echo "Complete! View ~/Pictures/google-photos-backup.log for full log detail."  

This downloads to a directory
Adjust the paths along with the 8 transfers at once limit and bwlimit. Also it logs to a file so you can review what happened later if needed.

With this, we can add run/execute permissions with:

chmod +x ./backup-google-photos.sh  

and then going forward we can either run this once a week or so manually with:

./backup-google-photos.sh

Or setup a cron to run it if you know your machine will generally be running around a specific time to do the backup.

crontab -e  

add a line to run this, e.g. Fridays at 2pm

0 14 * * 5 ~/Pictures/GooglePhotosBackup/backup-google-photos.sh  

You may from time to time need to refresh the access token.
To do this you can run:

rclone config reconnect googlephotos: --auto-confirm  

# email on ssh login
if [ -n "$SSH_CLIENT" ]; then  
    TEXT="$(date): ssh login to ${USER}@$(hostname -f)"
    TEXT="$TEXT from $(echo $SSH_CLIENT | awk '{print $1}')"
    echo $TEXT | mail -s "ssh login" your@email.here
fi  

Now on yours, and any other user ssh, you'll get an email (assuming you have email setup already with mailutils etc)

The email will look like this, showing the user, which server and their IP (where I've changed the IP to 1.2.3.4 and hostname of the server to my-server-name for the purposes of this screenshot):

Extract in your downloads folder and open up the terminal and cd over to the newly extracted folder.

cd ~/Downloads/postman-linux-x64  

Move it to be available system-wide:

sudo mv Postman /opt/postman  

Make the postman command available:

sudo ln -s /opt/postman/Postman /usr/bin/postman  

Add to applications menu:

sudo vim /usr/share/applications/postman.desktop  

Add the following:

[Desktop Entry]
Name=Postman  
Exec=/usr/bin/postman  
Icon=/opt/postman/app/resources/app/assets/icon.png  
Type=Application  
Categories=Development;  
Terminal=false  

Test & you're done.

Step 1. Create the user

CREATE USER 'USERNAMEHERE'@'localhost' IDENTIFIED BY 'PASSWORDHERE';  

Step 2. Privileges, e.g. this would give you everything:

GRANT ALL PRIVILEGES ON *.* TO 'USERNAMEHERE'@'localhost' WITH GRANT OPTION;  
FLUSH PRIVILEGES  

Step 3. Use the config editor to generate your file.

mysql_config_editor set --user=USERNAMEHERE --password  
# it'll then ask for your password once

Step 4. Profit.

mysql  

^-- you should now be able to access your local mysql with a single command and no password entry needed.

You can also run mysql_config_editor with a --login-path=NAME flag to create multiple of these, then when starting mysql you can add that flag again to login to them.

More info about this command here:
https://www.prisma.io/dataguide/mysql/tools/mysql-config-editor

The main apache error.log file only reported there was a config issue, each site/vhost have their own files in our set up so grep to the rescue to track which was reporting new errors in their error logs.
I spotted one specific site having issues each time I restarted apache to bring it back up after the change:
"AH02565: Certificate and private key site.com:443:0 from /path/to/ssl.bundle and /path/to/ssl.key do not match" That'd do it.

It seems that the old config had hidden this as it would work but was slightly misconfigured to duplicate the crt in the chain. The site was also behind Cloudflare so it's hard to know if that further hid the issue.

Like many sites we use automatic renewals, but it transpired this certificate's dates were several years old from a prior server migration and the cert hadn't been set up for the new server to auto renew.
As they had cloudflare in front, the site was serving fine over HTTPS and apache didn't seem to mind with no errors in the log either.

Backups are always key and I was able to bring sites back initially in minutes by rolling back the config files, giving me time to debug what had happened.

It's a tricky issue to prevent, the config change had been tested on several sites before it was rolled out to all. The backups worked well and the per site/vhost error logging was also useful for debugging here.
We have automated checks that the ssl certs for sites are valid but I plan to rework this to also check the raw files on the server itself and ensure the 2 files do match up.

Ultimately I'm writing this up to help my future self and anyone else that may run into a similar issue.
If apache's configtest (-t) reports that the files are ok but then apache fails to restart due to a config issue, a likely answer or at least something to check is the certs. Of course, always have backups before ready to roll the config changes back, check error logs and check the certs using openssl to verify they are correct or force renewing ones that are reporting as erroring in the error log.
Hope this helps someone else as well.

You'll need to install the different PHP versions and make sure modules and config matches up.
If you already have php7.4 installed and you're looking to install 8.3 you could add 8.3 in while leaving 7.4 by installing it by version number with your OS package manager, e.g. with apt on Ubuntu:

sudo apt install php8.3-{cli,fpm}  

However, before installing the new version, you'll need to make sure your PHP pools don't reference a central/single sock file as installing the new fpm may auto switch it to the new version. E.g.

sudo vim /etc/php/7.4/fpm/pool.d/www.conf  

Check if it references /var/run/php/php-fpm.sock and update it to the version it's on like /var/run/php/php7.4-fpm.sock.
You'll then also need to make this update in your nginx or apache file and reload php-fpm first, then nginx or apache.

Once you've installed your new PHP versions, check both php fpm versions are running with:

systemctl status php7.4-fpm  
systemctl status php8.3-fpm  

To help compare config files you could use a tool like meld, vimdiff or diff, e.g.:

sudo meld /etc/php/7.4/cli/php.ini /etc/php/8.3/cli/php.ini  

Make sure to compare both the cli and fpm config files.

Also to help compare PHP modules you can use meld, vimdiff or diff again like so:

meld <(php7.4 -m) <(php8.3 -m)  

Then install missing ones, for example if you spot gd, gmp, intl, xml, curl and bcmath missing you could install them with:

sudo apt install php8.3-{gd,gmp,intl,xml,curl,bcmath}  

Then compare the modules again.

Using PHP FPM you can switch PHP version easily by switching which /var/run/php/php7.4-fpm.sock (this may also be /run/php/php7.4-fpm.sock) you reference in either the Apache or Nginx config (or whichever system you use to host.

E.g. in Nginx it's this line:

fastcgi_pass unix:/var/run/php7.4-fpm.sock  

Or Apache:

SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost"  

Your line here may be a little different, the above assumes it's the default version number based sock files but there are alternatives.
Here's 3 additional examples you may find:

• A single /var/run/php-fpm.sock instead of specific version. If that's the case, it will likely be that your php fpm pool for that version points to that single sock file. Your pool will be configured by a file in /etc/php/VERSION/fpm/pool.d/ e.g. /etc/php/7.4/fpm/pool.d/www.conf
  You can either, leave the current one pointing here and make sure your new PHP version has the specific version number in the sock file name and update the reference to it in the nginx/apache config. Or, you could swap which php version uses that sock file by editing the current one to have the version in the file name and the new one to this main sock file. Then restart both versions of PHP FPM.

• Multiple pools, one per site. If you have multiple sites on the server you may have created a php pool for each of them to isolate them. If so, you'll need to copy over these configs to the new version (or at least the ones you want on the new version, maybe test with one first) so if it was /etc/php/7.4/fpm/pool.d/site.com.conf and you're switching to php8.3 then copy to /etc/php/8.3/fpm/pool.d/site.com.conf
SetHandler "proxy:unix:/run/php/php7.4-fpm-site.com.sock|fcgi://localhost" and update the version number in the sock file if it had one, or add one in so it doesn't clash with the other.

• Listing to a port instead of a sock file. listen = 127.0.0.1:7401 In this example you have ports instead of files but they can be updated mostly the same as the sock files. You'll just need to remember or note down which ports relate to which versions & update your nginx/apache configs as needed.

Remember to reload nginx/apache after editing the configs and if you updated your php-fpm configs or pools, reload php-fpm for the versions you updated.

Then for the CLI you can switch with:

sudo update-alternatives --set php /usr/bin/php8.3  

You may also want to switch the php version phar files use as well, you can do this with by running both the following commands:

sudo update-alternatives --set phar /usr/bin/phar8.3  
sudo update-alternatives --set phar.phar /usr/bin/phar.phar8.3  

To make this easier, I added a bash function so I can call php-version 7.4 or php-version 8.3 to switch between them, and call php-version to have it list the php-versions I have available:

# switch php version for CLI
function php-version {  
    if [[ "$1" == "" ]]; then
        echo "Available versions:"
        currentVersion=$(php -v | grep -oP '(?<=PHP )\d+.\d+')
        availableVersions=$(ls /usr/bin/php* | grep -oP '(?<=/php)(\d+\.\d+)')
        echo $availableVersions | sed "s/$currentVersion/$currentVersion *current/"
        echo "Set default for cli with: php-version $currentVersion"
    else
        echo "Setting default php cli version to $1"
        sudo update-alternatives --set php /usr/bin/php$1
        sudo update-alternatives --set phar /usr/bin/phar$1
        sudo update-alternatives --set phar.phar /usr/bin/phar.phar$1
        echo "php -v:"
        php -v
    fi
}

Side note, you can also use sudo update-alternatives --config php to have it interactively show you php versions available and switch that way.

PHP heredocs aren't something I think most PHP devs (including myself) use day to day.
But did you know they have a secret power in editors like VSCode? Sub syntax highlighting.

Say you write some SQL for a report, rather than wrapping it in single or double quotes, try with heredocs with the identifier named SQL and you'll get SQL syntax highlighting inside:

The same is true for HTML:

Variable interpolation works here too:

The above example isn't secure though, it'd be open to an XSS attack. But as we can have variables reference anonymous functions, we can do things like:

Falling further down the rabbit hole.

We can't put foreach loops in for example, nor functions directly like arraymap but like the above example referencing the example escape attr method, we can have a variable which calls both arraymap and implode like so:

If you have Collections or similar you can do this without the helper:

Heck, if you want you can throw another Heredoc inside it!
Though at least at the point of writing, this breaks the syntax highlighting in VSCode.

The descent into madness begins...

At this point, you might ask, what else can we hack together here?

If statements? One way could be to have a function again which takes in a condition, true case and false case. But a simpler option is the ternary operator:

Switch (or rather, match statements), just like above:

And if you want something especially weird, there's a parser hack that will let you run essentially any PHP on the right side of this assignment like so:

Though this will trigger a deprecated warning in php-8.2+

Try any of these examples locally or over on https://onlinephp.io/

They could be better

I'm not suggesting you use these in your next project. Simple heredoc usage is great but these examples can be solved in much better ways such as the use of abstracted template files for rendering.

However, it'd be interesting for simple use cases if you could call functions or php directly without these hacks in heredocs.

There's a couple RFC's that attempted to bring this to PHP:
PHP RFC: Arbitrary Expression Interpolation
PHP RFC: Arbitrary string interpolation
Both appear to be withdrawn and had their drawbacks but maybe there's still chance we could get something similar in the future.

As PHP has deprecated ${} string interpolation maybe this syntax could be brought back but to allow calling PHP directly. Maybe to limit it's impact it only affects heredocs?
I don't think the presence of this feature would cause developers to no longer use better solutions when needed, but it would be handy for quick things where abstracting to a template is unnecessary.

Here's an example class which tracks logs and needs a simple way to render them as a list. I've added multiple renderLogs() methods showing a few possible solutions and well as the #{...} style for the possible proposed solution.

This isn't a perfect example, other examples could be where you want to render a total of 2 values and you don't want to break up the string just to add 2 numbers together. It doesn't have to be HTML of course either, maybe it's outputting to the terminal or sending an SMS, where adding template files perhaps wouldn't make as much sense.

Template Literals for example allow for this in Javascript. String interpolation in Ruby also allows for it, and they too use the #{...} style solution and similar solutions exist in other languages.

You can definitely have a view on your preferred method here, for many cases my go to would be either the foreach method or a view() style template function for now.
At the least I hope this helps demonstrate how we could interact with such a solution if it were to be added in the future.

Thank you for reading.

sudo apt install mkcert libnss3-tools  
mkcert -install  

Then set up your SSL cert for the needed domains, e.g. here I'm setting up localhost & mytestsite.localhost and i'm saving them to /home/andrew/bin/mkcert/ but change this to wherever you'd like the certs to save to:

mkcert -cert-file /home/andrew/bin/mkcert/localhost-cert.pem -key-file /home/andrew/bin/mkcert/localhost-cert-key.pem localhost mytestsite.localhost 127.0.0.1 ::1  

Simple and done.

For configuring your local apache, nginx or caddy etc. use the Mozilla SSL Configuration Generator.

While upgrading, half of them had no issues at all, while the other half ran into networking issues, bad times but this article will help you resolve those.

Talking to Digital Ocean support about this, its not an uncommon issue with larger upgrades like these. They mentioned their recommendation is that for anyone that can, is to install a new server and transfer over the files instead. If that's an option for you, it's a good one, but in my case that wasn't as simple an option.

In this post I'll run through my tips for doing each server upgrade from 16.04 to 18.04, and then to 20.04, along with a few common issues noticed along the way to help if you run into them too.

First, start with backup / snapshot.

Digital Ocean provide a great way to take live snapshots of the servers, but the preferable way if you're able to is to turn off the server and snapshot it before continuing. For several of the servers this process took less than half an hour, all down to the size of the server, and as I ran into Network issues later, the snapshot proved especially useful as I restored back to it while I debugged the issue further.

Updates & upgrades

You'll want to make sure your packages on the server are working and up to date before you continue.
Pretty standard but run and check the output of both to make sure everything's ok:

sudo apt update && sudo apt upgrade  

If you notice there's any issues like apt repos now 404'ing etc, make a note of them as you can either see if they can be fixed now, but as you're upgrading from EOL you may find some repos are no longer available on your current version and you'll need to come back to these after the upgrade.

Run the release upgrade

Before starting the next upgrade process, you'll want to open port 1022 ready. This is a port the release upgrade process opens for ssh in case there's an issue.
If you're using ufw you can run:

sudo ufw allow 1022/tcp  

(Check if you're running ufw with sudo ufw status)

Now you're ready to begin the upgrade, simply start it with the following command and follow the on screen instructions:

sudo do-release-upgrade  

My advice during this is answer Y (yes) to the questions about starting and automated restarts, but answer D (diff) or N (no) to the config changes.
Especially if you know you've made custom changes around files like your /etc/sysctl.conf or your /etc/nginx/nginx.conf file etc. then you'll not want to have to re-do them, but on some files it's worth checking the differences to see what's changed.

The nice thing to remember here though is that if you don't upgrade the config files, it'll save the new default one to the same location but with a .dpkg-dist extension.
e.g. /etc/nginx/nginx.conf.dpkg-dist so you can use this to compare your custom version to the new default they'd have provided later.

The same goes if you went the other way and said yes to changing the files, you'll have .dpkg-old file versions available.

Lastly, if needed you have your backup / snapshot to go back to as well if ever needed.

After finishing up the last stage of this command will be when it requests to restart your machine. Select yes and restart.

In all my upgrades, the 16.04 to 18.04 upgrades came back up fine, the only issues I ran into were during the 18.04 to 20.04 upgrade which was mainly network issues.
However, if you do find the server doesn't come back online after a couple minutes, skip down to the Resolving Network Issues section below.

Checks & repeat

After the 16.04 to 18.04 upgrade, you'll want to check everything is up and running well on your server before continuing to upgrade.

Check key services are up and running, view your sites on the frontend etc., check api monitoring etc. you might have.

IT's worth checking your apt repos here too, over in your /etc/apt/sources.list file and the files in your /etc/apt/sources.list.d folder, check for commented out repos from the upgrade and check if you want to bring them back and if so do so one at a time. Uncomment, sudo apt update to check it's working and sudo apt upgrade where needed, then repeat.

If everything's good, you can repeat the previous step again and continue on to upgrade from 18.04 to 20.04.

Resolving Network Issues

On a bunch of the servers I upgraded, I ran into networking issues where I couldn't connect over ssh to it, and once inside couldn't ping out.
This happened mostly on the 16.04 servers but during their upgrade from 18.04 to 20.04.

Luckily Digital Ocean provide a cloud console you can use to directly access the server even when it's networking is down. (Top right of the droplet info screen)

The cloud console may take a little time to start up and what I ran into was that the networking service was causing startup to take around 2 minutes.
Once in, I quickly found I needed a password as I've always just used ssh keys instead here so if you're like me you'll need to reset the root password which you can do via the servers info page under Access.
That'll email you the new password, it's a long one and the issue I've run into is that you can't paste (at least I couldn't at the time of writing this) into the console so you'll have to type the password manually.
Once you're in, if you did reset the password it'll ask for it again and to change it there, again that means typing out the long password but this'll be the last time.

The main source of the issue is due to Ubuntu switching to use netplan vs the previous networking service used in pre ubuntu 18.04.

View your current config with sudo vim /etc/netplan/50-cloud-init.yaml it should look something like this:

network:  
    ethernets:
        eth0:
            dhcp4: true
            match:
                macaddress: XX:XX:XX:XX:XX:XX
            set-name: eth0
    version: 2

Inside eth0 you need to add 2 new properties, an array of ip addresses and the gateway to use.
Edit the file and add in your servers IP and it's floating IP if you're using one like so:

network:  
    version: 2
    ethernets:
        eth0:
            addresses:
              - xxx.xx.xxx.xxx/16
              - xxx.xx.xxx.xxx/16
            gateway4: XXX.XX.XXX.X
            match:
                macaddress: XX:XX:XX:XX:XX:XX
            nameservers:
                addresses:
                - 67.207.67.2
                - 67.207.67.3
                search: []
            set-name: eth0
        eth1:
            addresses:
              - xxx.xx.xxx.xxx/16
            match:
                macaddress: XX:XX:XX:XX:XX:XX
            nameservers:
                addresses:
                - 67.207.67.3
                - 67.207.67.2
                search: []
            set-name: eth1

Your IP (and floating ip if in use) are available in your droplet info screen and your ip is also shown at the bottom of the cloud console screen too. (Add /16 to the end of these).

Get the macaddress's for eth0 and eth1 by running ifconfig (next to ether in the output blocks for each).

eth1 is the private network while eth0 is public.

Your gateway / gateway4 ip is also shown both in the droplet info screen and the bottom of the cloud console screen as well. (No /16 needed here though!)

Now you'll need to apply the changes with netplan, run:

sudo netplan apply --debug  

With this, your main server can now reach and be reached by the outside world again through your droplets default ip but not the floating ip yet.

At this point, I opened an ssh connection to continue as then I can paste commands faster.

In order to fully hook up your floating ip, you need to add your servers "Anchor IP", to look this up run:

curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address  

With this, go back and edit your /etc/netplan/50-cloud-init.yaml file again and add another address ip line in for this anchor ip (with /16 after it again).

Run netplan apply again and you should now be able to access your server via it's floating ip again.

sudo netplan apply  

Last part, after doing the above I found that after rebooting my changes to this file would be lost. So before rebooting, you'll want to copy this file to a couple locations to make sure it's always applied (once for netplan as a backup and another for cloud-init).

sudo cp /etc/netplan/50-cloud-init.yaml /etc/netplan/01-netcfg.yaml  
sudo cp /etc/netplan/50-cloud-init.yaml /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg  

Next disable the network conf changes in cloud-init by adding "{config: disabled}" into the following file:

sudo vim /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg  

Finally you can re-init cloud-init and netplan once more to be safe.

sudo cloud-init clean -r  
sudo netplan apply  

You should now be safe to reboot your machine, it can take a couple minutes still to come up due to cloud init waiting for old networking (working on a solution for this too but if you have a simple one please let me know) but it'll come back up fine and all connected to your droplets default ip and floating ip.

PHP version issues

You may find after the upgrade that php's upgraded, e.g. if you've been running 7.2 with fpm, you might find that service is not running and instead 7.4 or 8.0 is running instead.
Here what you can do is simply stop the version you don't want yet (if you're not ready to upgrade that yet) and then start the service you want.

E.g.

sudo systemctl stop php8.0-fpm  
sudo systemctl start php7.2-fpm  

You can then check it's status and logs with the following commands:

sudo systemctl status php7.2-fpm  
sudo journalctl -u php7.2-fpm  
less /var/log/php7.2-fpm.log  

If it's all working, you can disable the previous service all together, or even mask it to prevent it starting up in the future.

sudo systemctl disable php8.0-fpm  
sudo systemctl mask php8.0-fpm  

If you do mask the service you can unmask it at a later date if you want to enable it in the future.

you might also want to change your local CLI version of php, e.g. roll it back to use 7.2 as default.

sudo update-alternatives --set php /usr/bin/php7.2  

Resolving MySQL issues

You might also run into some issues if your mysql version upgrades.
On one of the servers I was upgrading that ran mysql it upgraded to v8 from 5.6.
Surprisingly easy upgrade in the end but I did run into some issues start/restarting.

To debug I used 2 terminals, 1 to restart mysql and the other to watch the mysql error log where I'd watch to see error lines.

tail -f /var/log/mysql/error.log  

If mysql isn't coming back online you should see the error in the log output.
It'll look something like this:

2021-04-07T17:52:31.945816Z 0 [ERROR] [MY-000067] [Server] unknown variable 'query-cache-size=0'.  
2021-04-07T17:52:31.946389Z 0 [ERROR] [MY-010119] [Server] Aborting  

The above was a real example from that server, in this case it turns out mysql v8 [removed a bunch of config params] (https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html), query-cache-size included so the fix was to edit the mysql config file and comment out that line.

sudo vim /etc/mysql/my.cnf  

In this case the query cache has been retired from mysql so there's not a straight foward replacement for this config var. But in other cases it's worth exploring what the alternative is if a config variable has maybe been dropped in favour of another etc. Google is your friend here.

Another common connection issue can be from the sql_mode needing to be set to blank or tweaked.
As well as another issue where you need to change the default-authentication-plugin = mysql_native_password to mimic how it used to run before.

Node version issues

Some of our apps on these app servers ran using older node versions and though we plan to upgrade those, while upgrading the server OS you might not want to handle that separate upgrade at the same time.

That's where nvm comes in, the node version manager.

To install nvm, run the following command:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash  

Then edit where your node service starts up, e.g. for me I use systemd service files for these.

E.g. inside your apps service file "/etc/systemd/system/app-name-here.service"

If previously you had a line like:

ExecStart=node /srv/app-name/index.js  

Update it to use the nvm init script and to run with your desired node version: (in this example I'm using an the latest node v6 release)

ExecStart=bash -c ". /home/andrew/.nvm/nvm.sh && nvm run 6 /srv/app-name/index.js"  

I hope this guide has helped you with your server upgrades, at the least it serves as a reminder to me of what I've done on mine but if you have any comments or questions let me know in the comments below.

Thanks for reading!

If you use email hosting with Heart Internet and prefer to manage your emails through Gmail, it’s easy to link the two. This guide will walk you through the steps to set up Gmail so you can send and receive emails using your custom domain address.

These steps are specific to Heart Internet, but the process will be similar for many other email providers.

Step 1: Set Up Incoming Mail (Receiving Emails)

1. Open Gmail and click the gear icon in the top-right corner.
2. Select See all settings.
3. Go to the Accounts and Import tab.
4. Under Check mail from other accounts, click Add a mail account (or edit info next to an existing account).
5. Enter your email address (e.g., yourname@yourdomain.co.uk) and click Next.
6. Select Import emails from my other account (POP3) and click Next.
7. Fill in the following details:
   
   • Username: Your full email address (e.g., yourname@yourdomain.co.uk)
   • Password: Your email account password
   • POP Server: mail.yourdomain.co.uk
   • Port: 110
8. Optional: Choose any of the additional settings (e.g., label incoming messages).
9. Click Add Account. Gmail will test the connection and start importing your emails.

Step 2: Set Up Outgoing Mail (Sending Emails)

1. In the Accounts and Import tab, find Send mail as and click Add another email address.
2. Enter your name and your email address (e.g., yourname@yourdomain.co.uk).
3. Untick Treat as an alias unless you specifically need it.
4. Fill in the following SMTP server settings:
   
   • SMTP Server: mailXX.extendcp.co.uk (Check your Heart Internet control panel for the exact server address)
   • Port: 587
   • Username: Your full email address
   • Password: Your email account password
5. Choose Secured connection using TLS.
6. Click Add Account. Gmail will send a confirmation email to your mailbox.
7. Follow the instructions in the confirmation email to verify your setup.

That’s It!

Once these steps are complete, you can send and receive emails from your custom domain directly through your Gmail account. This setup gives you the convenience of Gmail with the professional touch of your own domain email address.

Your ini file changes wont be upgraded with you, it's worth checking the ini file changes from the old version to the new one.

You can use diff or vimdiff but my personal favourite is meld which will open a visual gui diff between the files letting you go through and quickly copy in changes from the old file to the new one.

sudo meld /etc/php/7.2/cli/php.ini /etc/php/7.3/cli/php.ini  

Also remember to go through the different php ini files you have, e.g. for cli vs fpm vs apache if you use them.

As many sites / companies have had to temporarily shut down, or had to change delivery schedules or want to reasure customers of how they have handled this internally, OurSiteUpdates is a super simple and entirely free solution.

Find out more here: https://oursiteupdates.com/

p.s. this video recorded around 3am to get the app out as fast as possible lol

mitmproxy is a free and open source interactive HTTPS proxy.

To quickly get this up and running on Ubuntu 19.04 (Updated and tested in 20.04 & 21.04).

Install mitmproxy

sudo apt install mitmproxy  

This should install the latest version, if not you can get the binary direct from the website: https://mitmproxy.org

Start the proxy

For this demo we'll use port 8881 for the proxy but this can be anything not already in use.

For the command line version:

sudo mitmproxy -p 8881  

Or the web UI version

sudo mitmweb -p 8881 --web-port 8882  

Using 8882 as the web port, this will let you open http://127.0.0.1:8882/ to watch the traffic through but again this can be any port you like.

Or a socks5 proxy

sudo mitmproxy -p 8881 -m socks5  
or  
sudo mitmweb -p 8881 -m socks5 --web-port 8882  

Setup proxy

Open your Network settings and click to edit your Network Proxy.

Can also be found by going through chrome://settings/?search=proxy and clicking Open proxy settings

Set to Manual & set both your HTTP & HTTP proxies to localhost port 8881.

Setup SSL/TLS certificate for HTTPS support

This step is only needed the first time it's run.

Go to http://mitm.it/pem/cert which will download the certificate.

Then to import this into Chrome, head to chrome://settings/certificates and click Authorities & then click Import to select the downloaded certificate.

You may find this doesn't kick in with your existing Chrome session so try it our in Incognito/Private/Guest.

Enjoy

If using the command line version the requests will be listed as they come in. Use the up and down arrows to navigate around, press enter to view inside a request and then left & right between the tabs. You can also use your mouse to click the requests and tabs if easier. Then press q to go back to the requests list. Ctrl+c as often to exit.

Or if you're using the web UI, simply head over to http://127.0.0.1:8882/ and it'll start listing requests as you navigate the web.

Remember when you're done to disable your Network proxy setting when you're done with the proxy.

You'll need your phone, your desktop / laptop & a cable to connect them.

Prep

1. Enable developer options on your phone

   Settings > search for About phone > Tap Build number 7 times.
   If after the first time it says no need, you already have it enabled. After the 7th time it should say it's enabled.

2. Enable USB debugging

   Settings > search for USB Debugging > Enable.

Recipe

1. Plug in your phone

2. You should have a notification for "Charging this device with USB", tap this to get to the options.

3. Under "Use USB For" select File Transfer

4. On your desktop Chrome, go to chrome://inspect/#devices

5. On your phone Chrome, load any website, it should now be listed on the inspect page on your desktop.

6. Optionally enable port forwarding to debug a local site from your desktop on your phone.

Troubleshooting: https://developers.google.com/web/tools/chrome-devtools/remote-debugging/#troubleshooting