well that’s very odd

I wanted to move my TLD and blog (resides in a trailing sub-dir) from Arizona to my state-of-the-art datacentre in my house in Rugby, so:

  1. I backed up (and exported to my local hard-disc), the MySQL databases for the TLD and for the blog.
  2. I FTPd the content plus WordPress files from Arizona to my local hard-disc.
  3. In phpMyAdmin I created two users and an associated database for each user
  4. I imported the exported MySQL databases in to each new instance (both completed with non errors)
  5. I created the webspace on my NAS, and copied the WordPress files plus content in to it – changing the wpconfig.php in both the TLD and the blog sub-dir for the user details I had created in step 3.
  6. I logged on to the domain admin panel and changed the root IP address from the Arizona datacentre to the Rugby one
  7. Waited

After about 10 minutes the TLD had completed the propagation; I had full navigation being served up by the Rugby environment.

However the blog sub-dir failed: when I tried to access it I just got a blank screen of whiteness.

I dropped all of the tables in the database and did another import (which completed successfully).

And got the same white space.

So I deleted the MySQL database and the user, and tried to access the blog – and got a Database Connection error message, which is what I’d expect.

Then I created a new database to match the same credentials I’d created in the wpconfig.php file, and imported the old MySQL database again.

It failed once more; same white screen.

Hmm.

This needs thinking about.

virtual or physical?

I have temporarily closed down Server 1 and Server 2, and transferred all data and functionality to the NAS.

Reason for this is twofold:

  1. I’m going to install VMWare on Server 1, and clone my laptop in to a virtual desktop on Server 1
  2. I’m going to install VMWare on Server 2, and configure it as a virtual hosting platform

The reason for 1. is because I have some audio production software on my primary laptop which is no longer available. If the laptop should suffer a critical failure (and I’ve had three of those in the last 12 years), I would lose that software and lose the unique goodness that it gives me. But if I virtualise the laptop on to a Raided VMWare server, then the laptop and its applications should be protected, yes?

The reason for 2. is just because I’d like to set up virtual servers, to see how easy the initial stand-up and config is, and look at the management overhead of running virtual hosts.

Although I’ve kicked off these tasks by migrating the content from Server 1 and Server 2 to the NAS, the actual installation/stand-up and config of both virtual environments is going to take a while to complete.

Not because they are long, complex tasks (they aren’t particularly complex), but because I have a hectic, complex calendar, with scant spare capacity for such leisure-time geekery.

speed (killing)

I haven’t been home much since I moved in. I know it’s been seven weeks since I got the keys to the new house, but I’ve probably spent eight nights here in that time.

Not that long, really.

But long enough to realise that there was a problem, of some kind, with the broadband speed.

I raised this with my ISP. They put me on hold and ran ‘a few tests’ and yep, they came back on the line and said “You should be getting better performance than that!”

They put me on hold again and went off to do something else.

A couple of minutes later they said “It looks like Openreach have put you on the wrong kind of broadband. I’ve raised this issue with our provisioning team and within 24 hours you should be getting speeds closer to what you expected.”

Twenty-four hours later I ran a speed test that yielded

Download: 70mbs
Upload: 20mbs

So well done to Plusnet for sorting things out.

And a big fuck off you useless fucktards Openreach, for giving me 8mbs down and 1.2mbs up, when I should have been getting 70/20 from day one.

moved

This website has been down for a couple of days, but only because I’ve moved house, and had to switch my phone service/ISP to a house that didn’t have a live phone line.

Last night I unboxed the tech, plugged it all in, switched it on and Robert’s your mother’s brother…

It all worked.

mariaDB, I’ve just met a girl called mariaDB

I’ve just upgraded the NAS operating system from DSM4.3 to DSM5.0

There are a number of changes, but the biggest obvious one is the UI, which now looks like this:

NAS_adminPanel

Jazzed up, huh?

When you crack open the bonnet and look inside, you notice that the changes go beyond the visual.

The new operating system drops MySQL out of the picture, and switches to MariaDB.

Why?

Since MySQL got bought up by Oracle, a growing number of people have become concerned that the brilliant free database that drives so many internet functions might stop being free (or might get taken off the market altogether by Oracle, and replaced with a paid-for product).

These people (the concerned ones) took foundation components from the MySQL product, added some updated thinking, and produced MariaDB.

I was understandably nervous about accepting the DSM upgrade. I use MySQL to run database functions, and use it to interface with .php front-ends. I also use MySQL to run security functions on the NAS, and content indexing features.

So this evening I backed everything up, took a deep breath and hit the upgrade button.

The NAS did its upgrade thing, rebooted itself and popped back up.

The WordPress intranet site (yeah, pretty geeky, huh?) popped straight back up and the first thing I noticed was how fast it was.

I poked around in the phpMyAdmin control panel to make sure that everything was still there, and doing what it should be.

All of the MySQL databases (I’m currently running five) had been converted to MariaDB.

I could access the databases through the GUI and could execute SELECT and UPDATE and DELETE statements in the SQL panel.

I could also import and export databases, and build new tables and drop tables at will.

And yes, it all seemed to be much quicker than it had been, when the back-end environment was MySQL.

In fact it looked so quick that I have opened port 80 on my router again, and brought this blog back from Arizona, and am currently hosting it on my NAS (not on HP Server A or HP Server B).

Just, you know, for a laugh.

opening and closing port 80 – a test

Well, as you might remember, having migrated all of the self-hosted websites to the Arizona host from the Rugby infrastructure (so there are no domains pointing to the static IP address here), I closed port 80 on the router.

That was a week ago.

This evening, just for a laugh, I opened port 80 on the router. You have to remember that there are no domains hosted in Rugby, so there can be nothing pointing to a domain inside the router.

As soon as I saved the new #open port 80# config on the router, the port 80 calls started appearing:

[LAN access from remote] from 123.125.71.13:20876 to 192.168.1.9:80 Thursday, Feb 27,2014 17:47:41
[LAN access from remote] from 220.181.108.99:33261 to 192.168.1.9:80 Thursday, Feb 27,2014 17:43:59
[LAN access from remote] from 116.83.69.235:48491 to 192.168.1.9:80 Thursday, Feb 27,2014 17:42:49
[LAN access from remote] from 186.93.250.149:60705 to 192.168.1.9:80 Thursday, Feb 27,2014 17:18:47
[LAN access from remote] from 186.93.250.149:60300 to 192.168.1.9:80 Thursday, Feb 27,2014 17:18:46
[LAN access from remote] from 186.93.250.149:60125 to 192.168.1.9:80 Thursday, Feb 27,2014 17:18:45
[LAN access from remote] from 186.93.250.149:59920 to 192.168.1.9:80 Thursday, Feb 27,2014 17:18:44
[LAN access from remote] from 186.93.250.149:59862 to 192.168.1.9:80 Thursday, Feb 27,2014 17:18:44
[LAN access from remote] from 179.60.148.11:34017 to 192.168.1.9:80 Thursday, Feb 27,2014 17:18:38
[LAN access from remote] from 220.181.108.78:15213 to 192.168.1.9:80 Thursday, Feb 27,2014 16:53:14
[LAN access from remote] from 123.125.71.17:54235 to 192.168.1.9:80 Thursday, Feb 27,2014 16:52:23
[LAN access from remote] from 179.60.148.11:55732 to 192.168.1.9:80 Thursday, Feb 27,2014 16:30:56
[LAN access from remote] from 220.181.108.100:50027 to 192.168.1.9:80 Thursday, Feb 27,2014 15:43:21
[LAN access from remote] from 123.125.71.17:16481 to 192.168.1.9:80 Thursday, Feb 27,2014 15:42:36
[LAN access from remote] from 123.125.71.45:53286 to 192.168.1.9:80 Thursday, Feb 27,2014 14:46:49
[LAN access from remote] from 220.181.108.117:14815 to 192.168.1.9:80 Thursday, Feb 27,2014 14:43:55
[LAN access from remote] from 123.125.71.45:30651 to 192.168.1.9:80 Thursday, Feb 27,2014 13:55:58
[LAN access from remote] from 220.181.108.90:51256 to 192.168.1.9:80 Thursday, Feb 27,2014 13:48:08

So, it’s safe to assume that all of these (and probably most of the historic)  port 80 calls are routing to the static IP address configured inside the router, not to any domain name.

Interesting.

examining a log

The router log does, it seems, record some activity, but not all, even though all ports are now closed in the primary firewall.

The router log continues to show the MAC addresses of the devices that attach to it (chiefly my phone and laptops), it also records non-specific port activity, like this:

[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:33:54
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:31:10
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:29:46
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:27:13
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:25:42
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:24:15
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:22:21
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:21:59
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:20:23
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:17:53
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:16:09
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Thursday, Feb 20,2014 05:14:54
[DoS attack: FIN Scan] attack packets in last 20 sec from ip [77.247.179.176], Wednesday, Feb 19,2014 17:57:00

Someone in the Netherlands seems to be trying to bring my system down, but with no ports open, all that’s happening is my router is recording the external activity (and promptly ignoring it).

Interesting.

so I woke up early this morning

And, for reasons that I’ll go in to another time, I thought ‘Well, I’ve got half an hour, why not migrate those websites off the HP Server array, over to Arizona, and shut Port 80 on my router?’

So I did.

I took local copies of the five MySQL databases, created five new MySQL databases in Arizona, imported the appropriate copies of the local MySQL databases in to each of the appropriate new MySQL databases, FTPd the five .php environments to the five new webspaces, made myself a cup of tea, and then pointed the IP and NameServers for each of the five domain names from the HP Server address, over to the Arizona address.

Then I shut my local router to all internet traffic.

I’ll review the router log tonight; it’ll be interesting reading because I don’t know if it will record all failed attempts in the same way that it recorded all successful attempts.

I’ll also check the NAS access log (as it acts as DHCP server).

My internal LAN (NAS/DHCP server, plus HP Server A, and HP Server B) are all still accessible to me from within my network.

The downside of this is that I can’t perform remote admin on the NAS, HP Server A, or HP Server B, while I have all ports shut down on the router.

Well, I’ll keep an eye on the server log, and maybe I’ll open up just the one port I need for remote access.

We’ll see.