WordPress is an incredibly popular website management system, powering an estimated 25% of websites. This guide is aimed at the novice Linux user and should talk you through setting up WordPress on Bytemark Symbiosis while explaining what is going on.
By the end of this guide, you should be left with an install of Symbiosis which allows it to automatically update itself and support things like plugins and themes with minimal security concerns, and this can be repeated multiple times to run many individual sites on the same server.
While this guide may look fairly daunting to the novice user, it outlines what is happening as you set it, so is intended to be informative while still being instructive!
What you’ll need
This guide assumes a base level of knowledge of Linux, and you will need:
- A server running Bytemark Symbiosis 8 or above
- A 1 GiB server with 25 GiB of disk space should be more than enough for a number of low traffic sites (this is our base spec).
- This guide uses Symbiosis — our free, open source server management software — to do all the heavy lifting and configuration, as well as set up things like SSL certificates.
- The server doesn’t have to be hosted with Bytemark, but it only takes a few minutes to sign up and set up a new Cloud Server with us.
- Familiarity connecting to a server via an SSH client
- You could do all of this via the console to a Cloud Server, but you will want to be able to copy and paste as there would otherwise be a lot of typing involved.
- PuTTY is a popular SSH client on Windows, and macOS and Linux both have SSH clients built in.
- Access to the domain that you want to set the server up on
- You’ll need to have decided what domain that people will use to access the site before you start setting it all up.
- If you already have a domain you want to use, you’ll need access to its DNS records so that your WordPress site is visible to users.
- If you don’t own a domain already, you can register one with Bytemark through the Bytemark Panel or via another provider.
Create your Symbiosis virtual machine
For the purposes of this guide, we’re going to assume you don’t already have a server running Symbiosis, and that you’re going to use a Bytemark Cloud Server. Feel free to skip this section if you have a server already set up.
- If you haven’t done so yet, sign up for a Bytemark account. You’ll typically receive enough credit to cover a month’s basic Cloud Server hosting when you do. This should be enough for hosting a few moderately popular sites.
- Log into the Bytemark Panel and select the “Cloud Servers” tab.
- Click the “Add a Cloud Server” button, and type a name for it. “Group” can be left as default, and you should choose which data centre you want the server to be in.
- Resources can be left at the default for most servers, but you can adjust this up and down as needed if your site gets busy.
- Select “Symbiosis 8” as the operating system.
- Disc space can also be left as default as this should be enough for most servers.
- Click the “Add this server” button and wait a couple of minutes for the server to start up.
- Make a note of the password you’re provided when starting the server – you will need this to log in!
Connect to your server and set up some variables
Using your SSH client, connect to the server as the
admin user. You should be presented with a Bytemark Symbiosis splash screen with some system information.
As you know what the site is going to be called, we can set it as a variable to save typing it over and over, and ensure that you can easily copy and paste the code below. Apart from the first two commands, setting the
wp_name, the text in blocks can all be copied and pasted into your SSH client.
For this guide, the site will simply be “https://www.example.com“, but we’re going to set a short ‘name’ up as not everything is happy with the dots (.) in full domain names. While we do this, we’ll add them to a simple script so you can pick this up later.
First, we’re going to set the full domain. Note that this must not include the
www. as this will be added automatically.
wp_domain='example.com' # Remember to change example.com below for whatever your domain name is, and no www.!
Next, we need to set a short name for the site. This will be used for the database connection and a few other places, but won’t be publicly visible. You can simply drop the
.co.uk or similar, as long as it is a simple string of lower-case characters and numbers.
wp_name='example' # Remember to change this also! Lower case number and letters only, please.
Once that has been done, you can check they have been set correctly with:
echo "Setting up site 'https://www.$wp_domain' with short-name '$wp_name'."
Assuming those look okay, we can save them in a simple script which will save you having to set them again, act as a simple scratchpad, as well as allow you to pick up where you left off.
Now we have setup these variables, you can copy and paste the following code blocks without having to change anything.
echo '#!/bin/bash' >> /srv/variables-$wp_name.sh echo "echo 'Setting WordPress installation variables, use the command \"set | grep ^wp_\" to list the current settings.'" >> /srv/variables-$wp_name.sh echo "wp_domain='$wp_domain'" >> "/srv/variables-$wp_name.sh" echo "wp_name='$wp_name'" >> "/srv/variables-$wp_name.sh" chmod 700 /srv/variables-$wp_name.sh
If you find that you are disconnected and need to return, you’ll need to run
/srv/variables-wp_name.sh (replacing wp_name with your short name) to get back to where you were.
Create the database and set permissions
Now that we have that set up, we’ll want to create the database WordPress will use, and create the user for it. This could be set up manually via the phpMyAdmin web interface, but the quickest way is to use the command line.
To do this simply, we’ll use the Debian built-in credentials to create the database and user:
echo "create database $wp_name;" | sudo mysql --defaults-file=/etc/mysql/debian.cnf
You’ll be prompted for a “sudo” password (and you may see a blurb about ‘great power coming with great responsibility’ if it’s your first time using it). The password is the user password for the user you’re logged on to the server with.
Next, we’ll have to choose a password for the database. As you won’t be typing this in, it can be fairly long and hard to type.
So, we’ll generate a secure random password, add it to the variables scratchpad, and then print it out.
wp_dbpassword="`dd if=/dev/urandom bs=200 count=1 | base64 | tr -dc '[[:alnum:]]' | cut -c 1-20`" echo "wp_dbpassword='$wp_dbpassword'" >> "/srv/variables-$wp_name.sh" echo "Database Password of \"$wp_dbpassword\" randomly selected and saved."
Now that we have a password, we can create the WordPress user and give it full permissions to the database.
echo "grant all privileges on $wp_name.* to '$wp_name'@'localhost' identified by \"$wp_dbpassword\";" | sudo mysql --defaults-file=/etc/mysql/debian.cnf
Again, you may be prompted for your password.
You can now test this worked okay with the command
mysql -u $wp_name -p$wp_dbpassword $wp_name -e "SHOW DATABASES;", and you should have a result which includes your site name you set earlier.
Next, we can download WordPress. First, we’ll need to create the directory Symbiosis expects, and move there.
mkdir -pv /srv/$wp_domain/public/ cd /srv/$wp_domain/public/
Then, we’ll download the latest version of WordPress, then rename the directory that you get out.
wget -O - https://wordpress.org/latest.tar.gz | tar -zxv mv -Tv wordpress htdocs
If you get an error with the last command that mentions the directory isn’t empty, it’s likely because you already have a
htdocs directory with content in it. If you’re entirely replacing an existing site, then you can use
mv htdocs htdocs_old to move it out of the way then try again.
Adjust the security
Symbiosis has a few security features which can prevent any malicious code on websites from connecting out – we’ll need to turn this off in order for WordPress to be able to connect out to perform automatic updates, and get things like new themes and plugins. (You may be prompted for your password again.)
rm -v /etc/symbiosis/firewall/outgoing.d/50-reject-www-data sudo symbiosis-firewall
However, we aren’t going to leave it unprotected — we can stop PHP files from being executed after being uploaded. This is a common vector for WordPress exploits and attacks, and fairly simple to set with a
mkdir -pv /srv/$wp_domain/public/htdocs/wp-content/uploads/ echo 'php_flag engine off' > /srv/$wp_domain/public/htdocs/wp-content/uploads/.htaccess echo -e '<Files *.php>\ndeny from all\n</Files>' >> /srv/$wp_domain/public/htdocs/wp-content/uploads/.htaccess
Enable larger uploads
By default, Symbiosis is only set to allow files of 2 MB to be uploaded. To allow larger files (which you will likely want to do), we need to add a few lines to the
.htaccess file, increasing the limit to 64 MB.
echo -e '\n# begin php override\nphp_value upload_max_filesize 64M\nphp_value post_max_size 64M\nphp_value max_execution_time 300\nphp_value max_input_time 300\n# end php override\n\n' >> /srv/$wp_domain/public/htdocs/.htaccess
Set filesystem permissions
To ensure that WordPress can keep itself up-to-date while still allowing Symbiosis to do its thing, we need to adjust the ownership on some files. You should do these commands one-at-a-time, so that you will be able to see if one of them has a problem (problems with any command may break things).
First, we set the directory the site is in to be owned by the
admin user and the
sudo chown admin:www-data /srv/$wp_domain/public/htdocs
Then we set all the files in the directory to be owned entirely by
sudo chown -R www-data:www-data /srv/$wp_domain/public/htdocs/*
Please note: On servers running Symbiosis, double check that the /srv/$wp_domain/public/htdocs/.well-known directory is still owned by admin:admin. Run the following command if you’re unsure:
sudo chown -R admin:admin /srv/$wp_domain/public/htdocs/.well-known
Next, we set the files and directories to be writable by both the user and group:
sudo chmod -R 664 /srv/$wp_domain/public/htdocs
Then (and most importantly) we set the directories to be enterable as the previous command will have revoked this.
sudo chmod -R +X /srv/$wp_domain/public/htdocs
Finally, we should add the
admin user to the
www-data group. This isn’t strictly needed but it will allow you to get around as the
admin user the next time you log in.
sudo usermod -a -G www-data admin
We can now paste a quick script to output the WordPress configuration instructions in an easy-to-read format. (We could simply insert the values into a config file, but this is less destructive and less prone to problems later on):
cat | bash << EOF clear echo echo "1. Browse to: http://$wp_domain.testing.$HOSTNAME" echo "2. Select your Language. Click 'Continue', then 'Let's Go!' on the next page." echo "3. When prompted, enter the information:" echo " Database Name: $wp_name" echo " Username: $wp_name" echo " Password: $wp_dbpassword" echo " Database Host: localhost" echo " Table Prefix: wp_" echo "4. Click Submit, then if everything looked okay, 'Run the Install'" echo echo -n "Press enter to continue..." EOF
Once you have pasted that into your SSH session, the screen should be cleared and the instruction printed. Follow these, and you should be dropped at the WordPress installation screen.
Then, when prompted, enter:
- The name of the site
- An admin username
- Email Address
Then click ‘Install Now’, set the site up as you like, and you’re almost done!
Now the site is visible (although on the wrong name) it’s time to look at making it visible on the correct name. DNS is the important part which ties the domain name to the IP address of the server, and there are a few options here which vary based on how you’re setting things up, so read this part carefully!
First, run these commands to install the
dig utility and determine where the DNS records are currently expected to be:
sudo apt -y install dnsutils
dig +short NS $wp_domain
If your result is blank…
…then your domain may not exist. Check that you did register it, it’s not expired, and you definitely typed it right when you started. It’s worth noting that very new domains may take a few hours to a day to become fully visible across the internet.
If your result includes
… then your domain is hosted on the Bytemark Content DNS platform.
- If the domain is a new one which you have only recently registered with Bytemark, then DNS should be configured automatically.
- You won’t need to do anything in this case, and it should all “just work”.
- If you’re setting this up on a Bytemark server and the domain has been used on another Bytemark server, then you may need us to change the authority if you haven’t done so already.
- Domains are ‘locked’ to the first server that uploaded DNS records, please contact Bytemark support to confirm and change this if needed.
If your result doesn’t include
… then it’s probably running on third-party servers, and you will need to contact that third party, probably the company you bought the domain from.
You have a few options here — the fastest would be to log into the third party’s control panel and then add the DNS records for the new server. Symbiosis will have created a DNS file for you at this point with all the records you’d typically need. To find out what the bare minimum of records needed are, copy and paste this block into your SSH client:
cat | bash << EOF clear echo "Minimal DNS configuration for $wp_domain:" echo echo " $wp_domain with an A record of `symbiosis-ip`" echo " www.$wp_domain with an A record of `symbiosis-ip`" echo echo "Optional IPv6 records:" echo echo " $wp_domain with an AAAA record of `hostname -i | grep -o "^[0-9a-f:]*"`" echo " www.$wp_domain with an AAAA record of `hostname -i | grep -o "^[0-9a-f:]*"`" echo echo -n "Press enter to continue..." EOF
Unfortunately, if your domain is hosted elsewhere then we can’t help with this part, but you should be able to use that information to set the basic DNS records up so the WordPress site is visible.
A longer method which may take a day or so two to update would be to change the “authoritative name servers” to use the Bytemark Content DNS servers. You’ll need to contact your registrar for this (the people you bought/renew the domain from) and have them change the authoritative name servers to
An even longer method, which can take a few days to a week or more, would be to transfer the domain to Bytemark. Note that if you are doing this, you can probably update the DNS and/or change the authoritative name servers before you begin this process.
Finalising the WordPress install
There is one last thing that will need to be changed to enable the site to work properly without its redirect.
Once the DNS records have been set up and browsing to the address you entered way back up at the top of the page drops you on the shiny new WordPress site, you’ll want to change the address of the site to the correct address and get rid of the redirect.
To do this, you will need to change two options on the WordPress Dashboard.
- Browse to the URL of your new site, and you should end up at a different address, probably ending in
bigv.ioor something similar.
- Add the text
/wp-adminto the end of the URL, and log into the Dashboard if you haven’t already.
- On the left-hand side of the page, click the “Settings” menu to go to the “General Settings” page.
- Change the “WordPress Address (URL)” and “Site Address (URL)” to the URL of your new site. In both cases, you should remove the
.testing.text and whatever follows it from the end of what’s already there.
- Make sure you get these right as if you don’t then it can be fairly complex to fix.
- Scroll down to the bottom of the page, and click “Save Changes“
Assuming all went okay, congratulations! Your site is now live and working on the final address.
From here you should be okay to use WordPress normally, restoring backups if you have them, uploading content to the site and installing plugins and themes.
Setting up HTTPS
Once your site has been visible to the public for a few hours, Symbiosis will automatically retrieve a free Let’s Encrypt SSL certificate for your site and enable HTTPS. However, before that happens, Symbiosis will use a ‘self-signed’ SSL certificate, which will generate warnings in the browser.
Once it’s swapped to the new certificate, and you can browse to your site via
https:// without warnings, go back to the “General Settings” page in WordPress and swap
https:// in the “WordPress Address (URL)” and “Site Address (URL)” fields and save the configuration.
WordPress will update itself with security fixes to its current version but won’t automatically install minor versions as this may break plugins and themes, so you should remember to check the Dashboard occasionally to ensure things are up to date.
In the event you run into any problems, please don’t hesitate to contact Bytemark support and let us know!
Note that if your server isn’t hosted with us then we may not be able to help much, but we’d like to know if there are any problems with the guide so we can improve it.