Moving the second (part III)

Well.

In the best traditions of technical geekery, the next part in the exercise to self-host on a Synology Diskstation NAS was not as straightforward as it could have been.

But I got there.

There are a few very minor gremlins to sort out, but tonight was all about establishing a proof of concept, and implementing a prototype self-hosted, php-based/MySQL-backed website.

I began by taking a copy of WordPress from my downloads folder. I knew it was not the current version, but that was part of my plan – I wanted to see how the self-upgrade function would work on a self-hosting NAS.

I exploded the zipped WordPress files locally, and copied the exploded WP structure and files over to the appropriate web-folder on the NAS.

Then I fired up the phpMyAdmin console and attempted to create a new MySQL database.

Snag.

phpMyAdmin could navigate around the default structure of MySQL databases, but it wouldn’t create anything.

I checked the permissions which, naturally, were good – I had logged in as root – so I tried again. And again.

The console just hung on a create command.

I navigated to users and tried to create a new user, but that achieved the same square-root-of-absolutely-nothing result.

I then spent a good 20 minutes googling various combinations of the words ‘phpMyAdmin fails to create new database and user’.

The only thing I learned is that a significantly large number of people don’t know the difference between hosted and self-hosted, and root and full access permissions.

Obv.

So then I looked at shelling out to the MySQL command prompt and using command-line syntax to create the database.

Fortunately MySQL syntax is a variation on the PL/SQL that I speak, so, refreshed in the patois of MySQL, I rolled up my sleeves and…

… thought about it.

Why is phpMyAdmin allowing me to do everything except execute any type of write command?

I scouted around the internet for a phpMyAdmin upgrade, because the more I thought about the problem, the more it began to feel like a command/interface issue.

I went on to Synology’s website and, while looking for a phpMyAdmin upgrade I discovered that the operating system of my NAS was two versions out of date.

It was a bit of a swervy long-shot, but I gave it a go and upgraded the OS.

Twice.

Then I ran phpMyAdmin again, navigated to the root of MySQL and, exactly as I had done several times before, I attempted to create a new database.

It only bloody worked.

I have no explanation for why, I can’t believe that having a version deficiency in the OS would stop phpMyAdmin from writing to MySQL, however…

Each of the two version upgrades required the NAS to be restarted, so maybe restarting the NAS was the catalyst that fixed the problem?

The old “switch it off and switch it back on again” technique?

If so, I’m slightly disappointed, because I thought Linux and MySQL were above such fripperies.

But, meanwhile, back at the geek factory…

I created a user for that newly created database, and allocated permissions and a password to it.

I fished out the config.php file from the WordPress root, and edited in to it the details of the database and the user I had just created, filled in the password and the hostname, saved it back to the WordPress root and then, in a browser, entered the URI.

I was expecting to see either a vanilla WordPress installation on the website or the WordPress config screen.

Instead I got a database error.

I fished back in to the root of WordPress, renamed the config.php to something the system wouldn’t be able to identify.

Flipped back to the browser, entered the URI again and got the WordPress setup/config creation page.

I entered the details of the database/user/host etc and accepted the changes, and ran straight in to a vanilla WordPress installation.

Brilliant, it worked!

Except.

Because I had used an old version of WordPress, the system prompted me to go and grab an upgrade.

When I tried to run through the usual WordPress upgrade procedure I got this screen:

The problem is, as geeks might have guessed, I haven’t used FTP anywhere in this process.

I hadn’t even configured FTP.

So I did the manual upgrade (downloaded the WordPress zipped package, exploded it, copied the exploded files in to the root webfolder) and then hit the refresh button.

And got a database error.

So I fished back in to the WordPress root, deleted the config.php, refreshed the website and, as expected, got the WordPress installation page again.

I filled in the database, host, username etc (again) and the website loaded.

Since then I’ve been playing with load functions, and attempting to analyse performance against user function and database activity.

The most that I can move the needle is to get the NAS resource monitor to flick up to 4kb/s of upload (to the web) activity, concurrently with 3kb/s of download (from the internet) traffic.

I don’t know how these numbers stack up in the Grand Scheme Of Things, but in my world right now, an activity ratio of 4kb/s over 3kb/s, on a combination of back-end and front-end utilisation is pretty encouraging.

But it is only one website.

Though it is loading lightningly fast!

Anyway.

The bottom line is that I need to investigate the FTP functionality, to allow WordPress to self-upgrade and, importantly, allow the WordPress plugins to self-upgrade too.

But that is the only thing left to do.

I’ve proved, with this prototype, that I can deliver what was in my head.

I will do no more (he said, trying to sound resolute) work on this concept until after I have moved.

But I know of a very nice pair of PowerEdge servers and a compatible rack for sale, for not much money…