well that’s very odd (solved in a bizarre way)

I had half an hour of personal downtime last night, so I thought I’d have another bite at the ‘migrate the TLD website and trailing sub-domain blog from Arizona to my state of the art data centre (haaaahahaha) in my lounge.

I’d researched the WSoD problem that WordPress had presented on the previous attempt to migrate the blog (the common fault seemed to be either theme-related or plugin-related), and decided on a cunning course of action:

  • Leave the MariaDB database and associated user that I’d created for the previous migration intact on the NAS
  • Move *all* of the WordPress files/directories that I’d brought over from Arizona to a new temporary directory 
  • Download a vanilla WordPress package
  • Install the vanilla WordPress package in to the blog trailing sub-dir, and see what I got

What I got was the usual WordPress install screen; it prompted me to enter enter the config details for the database and user.

I entered the details as I had configured during the previous attempt, and what I got was a WordPress error message: theme style sheet missing.

I went in to the admin screen, selected and loaded a native WordPress theme, and a native version of WordPress loaded in the blog’s location.

I then downloaded and installed the latest version of the Mantra theme (my preferred theme), and checked that the site loaded.

It did.

I copied back in to the wp-content directory all of the old blog content (but not the themes or plugin sub-dirs) from where I’d moved them in the temporary directory.

And everything worked – the blog loaded in its customised theme/design, and with almost the entire range of content.

Bizarrely, a couple of photos have gone AWOL somehow, but they are in the minority; just about everything else was in place.

The logical explanation is that something went wrong in the migration of content from Arizona to my NAS.

Except it can’t be that simple, because when I hit the problem the other day, I took, and deployed, a second data migration – and hit the same problem.

It was at that point that I backed out of the previous attempt to migrate (a backout plan is always a good thing to have!).

So I’m puzzled as to what may or may not have occurred during the first migration, but I’m not going to lose any sleep over it.

It was a bizarre fix to an unknown problem, but the fix worked.

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.