New Domains!

Because everyone needs more domains, right?

During a conversation the other week I was lamenting about how much of a pain it is to have to explain my domain when giving it out —

Yeah, its hyphen web — the take-away sign then the word web. W for Whisky, E for Echo, B for Bravo.

A typical reply when asked for my email address

I was asked — why don’t you just buy it without the hyphen? Good advice I suppose. Except that it had already been purchased. I checked on it previously and had done so at random intervals since registering The last update the wayback machine was on the 10th January 2018 – where it simply proclaimed

Welcome to

Staging Server

and had done so since May 2013. Prior to this is looked like a personal server for a Nick B.

I love that about the Wayback Machine — pop in a domain and see how its changed over the years. I’m a bit annoyed at myself as a number of years ago I requested that I be excluded from it and I can’t figure out how to re-enable it, but I digress.

Checking the domain I seen that it was now available for purchase! So I jumped on it, meaning is now improved, with one character less! 14 to 13 characters – a whopping 7.1% decrease!

But Wait – Theres More!

Nominet have also introduced the .uk domain – dropping the .co section. Checking with OVH they had a deal and I ended up grabbing that domain for less than £2 for the first year. A bargain! So that means that the domain now has 10 characters, translating to a near 30% reduction in characters!

The domains will all redirect to the domain as I’ve had it since 2002. I can’t get rid of it that easily!

Why? Why not…

Hosting PHP

What to expect when your expecting… to be hacked

A bit of a disappointing one this. Theres nothing worse (well, I’m sure there is but in this context lets leave it as is) than receiving that dreaded e-mail from your host. It starts with a subject line similar to

Security Incident Concerning

and a body of text along the lines of

A security risk has been detected on your server.
We have been informed that your server contains or redirects to harmful or malicious content, such as malware or phishing sites.

Not at all ideal. In summary — the server in question began to host malicious content. It was from a domain that I don’t use and have a holding page only up, and a user at some point has reported the URL as a malware/phishing attempt. This then gets reported to my host, who then reports it to me.

After getting the email I was a bit perplexed as to how this site had been flagged as a security risk. I checked the URL given and sure enough, a redirect was in place taking it away from my server to some other (compromised) server. I thought it might have been a coding issue that allowed my domain to freely redirect pages (meaning any attacker could mask their own server with mine). I logged in and checked a few things. It wasn’t my code that was doing anything. I checked and seen a few other files that shouldn’t have been there, all with recent creation dates. A quick

find . -maxdepth 20 -mtime -20

netted me a few files that had been created 2 days prior. These were in a variety of directories, and as I spread my domains across a couple of servers these files also appeared in those directories. The suspect files all were all Base 64 encoded, and executed php scripts – given that they all started with

<?php eval(base64_decode('BASE64ENCODEDSTRINGHERE')) ?>

These files either redirected pages, contained a mass emailer (LeafPHPMailer) or opened up a (pretty feature rich but visually poor) file manager. I’m not going to go into too much detail but the reason for the infection came from one WordPress installation that I had completely forgot about after transferring to the new host. Its a site thats very seldom accessed, and to be honest, doesn’t require a WordPress Installation, but it was an easy CMS solution for someone.

Using an out-of-date plugin the attacker managed to place obfuscated PHP file on the server. This file was then accessed via a web browser which ran the PHP code, and allowed other files to be placed in different locations on the server.

When I deployed these servers I began hardening them against attacks like this. Unfortunately, I didn’t finish it. Some of my actions stopped the potential full-scale destruction of the server which I’m thankful for, but I’m a bit annoyed I didn’t finish my hardening steps.

Having separate users for different tasks on the server helped. This meant that any file modifications were only able to be done at the root web-directory level. Config files, where appropriate were hosted out-with the directory, and permissions meant that other files could not be modified. There were a few other steps that I’m not going to go into detail about however cashing up on a couple of guides on how to harden or secure your server should help.

After figuring out what happened, and how it happened, I stopped any public access – essentially shutting down the HTTP Daemon, removed any newly created files matching the time scales above, pretty deleted any WordPress installations and re-downloaded fresh copies of the MD5-checked files from, then manually checked all the database tables for Indicators of Compromise (IoC’s) line by line, entry by entry, and slowly reloaded everything.

I then finished my hardening that I should have done before.

I think it’s important to vent that “hacking” isn’t hacking any more. It’s what used to be known as “Script Kiddies” who are now essentially Serious and Organised Crime Groups that use these phishing and malware scams to extract money. Theres no hacking in the traditional sense – just the unauthorised access to computers that wreck havoc on people who are caught by it. It’s the same as a teenager using a Low Orbit Ion Cannon.

Am I embarrassed this happened to me? Of course. Annoyed? Yep. But I’m also relieved that it did — it means I was able to stop it before it became much, much worse.


And Done

Thats all my domains now moved over to the new host.

7 years ago I started hosting with Digital Ocean. At exactly 0218Hrs on Friday 23/08/2013 I made my first $5 droplet – and that $5 droplet worked exceptionally well. I had automated backups and with VAT it came to around $7.20 every month. Not a lot by any stretch of the imagination.

The existing VPS was destroyed at 1655Hrs, Monday 30/03/2020 – meaning that droplet ran for exactly 2411 days, 14 hours and 37 minutes. Or 6 years, 7 months, 7 days, 14 hours and 37 minutes – give or take a few seconds. Its a good thing I waited until today to destroy the droplet otherwise there would be an extra calculation due to the DST difference!

But anyway. Onwards and upwards. My new host is £1.20 per month for each server, with a £10 setup fee. I currently have 2 separate servers running – for both reliability and to ease strain as a new customer. So far I’ve spent £16.80 per server for 3 months. Thats £5.60 per month each, so £11.20 per month. Making it a tad more expensive.

Just for information. I just spent the last hour dealing with Digital Ocean’s Billing API to obtain all the following figures – then attempting to use jq to parse this data – and finally excel to do some quick calculations. I also used [1],[2] and [3] in my quest to save time.

Im going use the rounded up value of 6 years and 8 months for the following math – exactly 80 months.

I’ve had a total of $110 in Digital Ocean credit over those 18 months — this includes welcome credit and referrals. Over the 80 months I spent exactly $427.04. Minus that credit brings the total cost to $317.04, so per month that equates to $3.96. Not bad, and still under the $5 cost it should have been! Converting that into UK Pounds equates to roughly £3.15 per month.

As I said my new server is only £1.20 per month, but there’s two of them, so £2.40. A whopping 75p per month saving.

However – I still have to factor in that £10 (each) per server set upon cost – and if I take the average of 80 months £20 becomes £0.25 per month.

All totalled, It looks like i’ll be saving around 50p per month.

Damm. I wish I had done the math before the moves.



There comes a time when everyone makes a mistake with computers. Garbage In Garbage Out and all that jazz. I seem to just like shovelling a large amount of Garbage into my servers. Take this evening for example.

I have one domain left to transfer to my new servers. The third last one was this blog and that went almost without a hitch. There were some wordpress-related things I hadn’t accounted for but nothing I couldn’t handle. The penultimate one was another wordpress installation that went much smoother after I transferred this blog.

And then I started preparing the move for the last domain. I’m being careful with this one because I know things will go wrong given half a chance. I’ve been checking and re-checking everything and decided to start to the process this evening.

First up was to update the existing code on that domain so that I could transfer everything fresh. That has a small hiccup which ended with me erasing (thanks to an errant FTP command) almost every folder and leaving but a handful of files behind.

Panicking, I managed to copy a new instance of the software over however in my haste this overwrote the main configuration file. Thank goodness I managed to remember some very old username/password/database combinations.

That ended up being rescued and is now working fine on the old host.

Whilst running about I then tried to login to my new host and managed to type with my ham-fists the incorrect password a few times and put my own IP address in a fail2ban jail.

I managed to get a remote KVM Console running via my hosting provider, and took myself out of the fail2ban jail. Now, I’m not entirely sure why I thought this was a good idea but I seen this button and figured I should click it.


Now I’m no new entrant to linux and its ilk. I’m also not a stranger to Windows – and my organisation requires the use of Ctrl+Alt+Del to initiate a login. Completely forgetting that Ctrl+Alt+Del on Linux restarts the server I click the button. No confirmation. No warning. Just a graceful restart.

Remember how I didn’t want any downtime? 🤦🏼‍♂️

I am not a smart man.

On the plus side, I today confirmed that a reboot would bring all services back online in a sane manner!

But the last site move has been postponed.


Easy root MySQL Password reset

I’ve recently found myself in that awkward situation where I’ve chosen a (very) secure password for a root MySQL user and I’ve forgotten it. I suppose its the most secure password I’ve had then because even I cant use it to login to the MySQL database – not that you should be using a root account under any circumstances – this was debugging.

I’ve had this happen before and I’ve used the


trick that stops the MySQL server, starts it up with no password, allows you to change the password, then stop and restart the server with the new password in force.

Ideally I wanted no downtime (even for those few precious seconds). As usual, google ended up pointing (to me) to a unknown way to reset the root password using another account that has full root privileges in a standard Ubuntu install.

Full credit to, and the main parts are only reproduced here in case the original site goes offline.

The debian-sys-maint user account is an administrative user account automatically created when installing MySQL Server on Ubuntu and this user have full access to all databases.

Quote from

This means that viewing the debian.cnf file using cat

sudo cat /etc/mysql/debian.cnf

nets us directly the login details including password for this account. Looking under

user = debian-sys-maint

is a

password = LongAndRandomPassword

so, using these details, a a quick

mysql -udebian-sys-maint -p


 ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'NewVerySecurePassword';

nets you with an uninterrupted uptime MySQL password reset.

Now. To read about this account that has MySQL Root Privileges that I’ve never noticed before.


Time for an update.

Update 1 below, posted at 12/12/2019 @ 1910Hrs

It’s Annual Leave time. Seeing as I’m not going away anywhere that means I have to fill my time with other things. This time, I’ve decided to migrate hosts. Oh the joys.

I have approximately 10 domains to move, database to migrate, files to transfer and DNS changes to propagate. This is going to be fun.

Why? Cost. I currently pay around £9 a month for my current hosting, which is to a company based in the US. I recon I can (safely) get it down to around £2 per month, maximum. Thats roughly 77% less. The hosting for the sites I do isn’t mission critical. Its still just a hobby. The £2 a month hosting should be more than adequate for my needs.

Because I’m lazy I figure a script will help with some of the automation. I’m using Apache VirtualHosts, and because each domain requires a separate VirtualHosts configuration file, I created this script. It doesn’t have the full configuration in it, but its enough to help you get started. I also output the command required to enable each configuration into a separate file, which can be viewed here.

Update 1: Most of my sites have been transferred over with no issues. All DNS records have been updated and appear to be working fine, apart from Virgin Media dragging its heels and apparently (still) not adhering to TTL values.

This one, and my busiest have yet to be moved. Im contemplating moving these two to a separate server, and at £1 per month, I don’t see why not.