Data Sheet: Installing WordPress

I‘m describing here the installation of WordPress on a local Terramaster Intel-based NAS running the latest version (at the time of writing) of the firmware, TOS 5.0. WordPress is supplied by Terramaster as a standard application, along with MySQL, the open source SQL database solution. What I cover here should be broadly applicable to installing WordPress on any locally accessed NAS.


INSTALLATION OF WORDPRESS ON TOS 5.0 is easy but you need to know what you’re doing. The WordPress app depends heavily on the presence of an SQL database, provided by a separate app. SQL (pronounced “sequel” if you want to sound like an IT old timer—and why wouldn’t you?) stands for Structured Query Language, named after the set of protocols used to access the database.

Underpinning SQL is the deeply sophisticated philosophy of Edgar F. Codd (pictured right). Until Codd developed his relational model of data you didn’t start building a database until you knew exactly the sort of answers you would be asking of it in the future.

Of course, real life data doesn’t work like that. Codd showed that it was possible to collect data in a shape that would be able to answer any kind of relevant questions in the future. That’s what a SQL database is.

If that’s puts you off SQL (yes, it’s hairy) and WordPress, you need to know that WordPress handles its SQL database silently and invisibly in the background, generally requiring no attention from the WordPress creator. All that matters is that it’s installed and working.

To fulfil this function, Terramaster provides MariaDB, an open source SQL database, the brainchild of a Finn called Monty Widenius (pictured left) that is widely used and respected across enterprise You install it before WordPress and open it to a login page that needs to be set up with an admin and password name.

By default, MariaDB announces itself as MySQL, the name of Widenius’ original open source SQL database creation. You can leave it like that (and there’s a story behind this.)

Once you’ve done that, hit the button marked Create Database to—yes—create a database. Call it wordpress (or whatever) and close the app. You’re done with MariaDB.

Now Open Terramaster’s WordPress app. You’re not running WordPress yet, just the initial setup. The WordPress Welcome screen is where you’ll create a title, username and password for your WordPress publication (which isn’t the same thing as your MariaDB). Fill in your email address and hit Install WordPress.

You’ll now see a login screen for WordPress. It might need to be refreshed. Log in to WordPress and apply any updates that may be necessary. You’re now ready to experiment with your own WordPress Website. As it’s on a private server it won’t be visible to the world even if you hit the Publish button on any Page or Post you create.

It’s possible you may get an error message when you try to apply updates. We didn’t after the initial installation on TOS 5.0 beta. Switching to the production version of TOS 5.0 left all our data intact but we decided to start afresh with WordPress so that we could document the installation process here.

The installation went smoothly but when we tried to apply the WordPress update a warning message asked for special access to the TOS 5.0 Web server. It wanted information about how the WordPress update could get to it using the file transfer protocol (FTP).

We sought advice on the Web and found this on the Silva designers Web site. Thanks to Machine Networks careful curation we’d never had to venture before into the entrails of WordPress. But the discovery that we could, and quite easily, was heartening.

PHP (originally “Personal Home Page” but subsequently cunningly recursively backronymed to the more general “PHP: Hypertext Preprocessor”) was a home brew project developed by the Danish-Canadian programmer Rasmus Lerdorf to create simple Web-based applications.

Never intended to be a formal programming language, PHP’s appeal (and shortcomings) stem from the fact that it “just growed” to fit the needs of its author. PHP has since been formalised and tidied up by an offical consortium, The PHP Group, and is invisibly at work underneath more than 75% of the pages on the Web.

Like the rest of the Web, WordPress runs on the engine* of HTML, the (let’s hope) graceful presentation on the surface of the page. But underneath, peddling away and moving it all along like the unseen webbed feet of the swan, is an active, get-stuff-done language called PHP. These engines are each driven by text files that you can edit and modify (at your peril).

*Programmers tell me off for describing HTML and PHP as “engines”. The actual engines are the respective language interpreters in much the same way as the production team is an “engine” that turns a script into a movie. So when I mention HTML here I mean “the language and whatever it takes to make it work.” You can read more about this here.
We’d developed some limited HTML skills from previous exercises with WordPress. But PHP was new to us. And it was PHP that needed editing here.

In particular, the instruction about how WordPress internal files are accessed from outside was what had to be changed. The suspicion was that a Terramaster update had tightened the WordPress security (probably the right thing to do but a nuisance for us).

The advantage of a local WordPress installation is that you can easily get to the entrails from your computer or laptop using either telnet or ssh. Either of these will create a pipeline into your NAS as if you’re working on its command line directly.

telnet, the simpler but less secure of these protocols, is generally deprecated these days. TOS 5.0 switches both these off by default, so you need to go into the Control Panel/Terminal and SNMP to switch either or both of them on. A very useful option also allows you to restrict entry from outside your local area network.

If you’re just doing the kind of operation we’re engaged in here, the smart thing is to tick the box marked “Allow telnet/ssh access only within the local network.” Under these circumstances, telnet, the simpler of the two protocols, is probably safe enough. But it’s best practice to shut down telnet and ssh access as soon as you’re done with it.

Windows users will need to install and run putty; Mac and Linux users have what we need built in. On our Ubuntu command line we typed something like:

sudo ssh -l topdog 192.168.0.88 -p 9222

(the topdog parameter is the name chosen for the NAS administrator.  The quartet of numbers following this is, of course, the IP address of Tellie on the LAN.

ssh defaults to using port 22 and without this parameter, the command line will seek entry through that port and report a failure. Terramaster sets a different port. 9222 used here is Terramaster’s own default but you can change this to whatever you like, and probably should.

If you’ve been following our Landing on Linux series you’ll know that the sudo at the start of the line means that the ssh command is being sent from the administrator, notionally the most privileged user of the system. It’s important to understand (as I didn’t at first) that having administration rights on your local machine (which you need to be able to connect ssh to the NAS) doesn’t automatically give you the same exulted rights on the NAS itself. That’s why we need the -l parameter here to announce that we intend to arrive on the NAS as the NAS supervisor.

For security reasons, topdog isn’t the real name I’ve given the Tellie administrator. It’s worth keeping this out of the public eye. In earlier versions of TOS this defaulted to admin, a far too common name, making it much simpler for bad actors to attack your system.

In TOS 4.0, if you shared a file across the Internet as the administrator, whether this name was topdog or whatever, the name would appear in plain text in the URL you sent out to your recipient. One of the subtler (but greatly appreciated) improvements in TOS 5.0 is that this information disappears into an encrypted string.


Chris Bidmead 24-Jul-22

Comments are closed.