http://www.techradar.com/pro/linux May 2019 LXF249 73
WordPress to static HTML TuTorials
Signing up for
DigitalOcean.configuration file for OpenSSH by using the command:
sudo vi /etc/ssh/sshd_config
Find the line that reads PermitRootLogin and
change that from Yes to No. With the file still open
there are other changes we can make. These include
changing the default SSH port. While this may not
sound like much, it removes a lot of low-level port
scanning on port 22. It won’t stop determined hackers
but it makes logs smaller and removes the low-level
detritus. Locate the line Port 22 and change that to
some other random port number. To make these
changes permanent it’s important to restart the
OpenSSH server. This is done with the command
sudo service sshd restart
To log in now using our new port number we need to
modify how we use the ssh command. To specify a
port, use the -p switch. For example, to log in to
192.168.0.10 using port 999 the command would be.
ssh [email protected] -p 999
Assuming everything works as expected, we can now
enable public/private key logins. This negates dictionary
attacks and makes the setup even more secure. On your
local Linux workstation, open a terminal window and
generate the public private keys using the following:
ssh-keygen
This will ask where you want to store the files; go
with the default by pressing Return. We strongly advise
using a passphrase, as that prevents anyone who has
access to the private key from just using it to log in.
Once it has been generated, it can be copied to the web-
facing host using the ssh-copy command:
ssh-copy-id adminuser@webserver-ip -p 999
To enable public/private keys for login, open the
sshd_config file again and change the Password
authentication line to no , making sure it is not
commented out. Before progressing, try logging in
using the ssh application again (don’t forget we
changed the port number too!). This time it should offer
up our private key and let us log in once we’ve given it
our passphrase.
Now we can deploy the Apache infrastructure. While
logged in, install Apache using the following command:
sudo apt-get install -y apache2
Test to ensure Apache is working by opening up a
local web browser and browse to the website. It should
show the famous Apache website landing page.
Assuming all works as expected, we can turn our
attention to making the infrastructure for our various
websites. As with the actions we performed in the first
installation we need to create a base folder for each
website, like so:
sudo mkdir -p /var/www/livinginstarbucks.com/html
The next step is to create the appropriate
configuration file for each website. We could copy the
original file but in this case, because our requirements
are so simple we’ll just start with an empty file and build
our own configuration. For each website, create the file:
sudo vi /etc/apache2/sites-available/livinginstarbucks.
com.conf
Each site needs a configuration file. Copy the one
below and edit to suit your server. Save it and quit.
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/livinginstarbucks.com/
html
ServerName livinginstarbucks.com
ServerAlias http://www.livinginstarbucks.com
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log
combined
</VirtualHost>
It’s a good idea to give each site its own set of log
files. Ideally, put each site’s log files into separate
folders – this makes it easier to perform analytics and
troubleshooting. Repeat until all the sites you want to
upload are done. To activate a site, use the following
command with the appropriate configuration file.
sudo a2ensite /etc/apache2/sites-available/
livinginstarbucks.com.conf
Before restarting the Apache service (and to help
mitigate any downtime), run apachectl configtest to
check for any errors. All being well, restart the service
with sudo service apache2 restart. If you ever need to
roll it back there is a similar command called a2dissite.
Essentially this is a quick way to add and remove sites
from the live environments.
At this point, we are almost there. Assuming that the
export from our WordPress site is on the local Linuxthedefault
Wordpress
designincludes
severalitems
thataren’t
usefulfor
anythingin
theworldof
htML-only.
thereforeuse
theWordpress
webdesigntool
toremovethese
linksfromthe
defaultwebsite,
suchasthe
metamenu.BAckupsAnd restoring
It’s not the most riveting topic, but there is an important need to
perform a good backup. Critically, make sure you have a backup of
the source VirtualBox machine. Losing this would be catastrophic
because there is no way to put the HTML output back into WordPress- or at least, not without a lot of manual effort. Luckily, backing up
the VirtualBox server is as simple as ensuring the virtual machine is
shut down and then copying the folder and its contents to a backup
location, ideally an external drive or such. Restoring the VM is as
simple as copying it back to your local system and then importing it
into VirtualBox, from the menu.
Backing up the HTML code is important, as mentioned, for version
control. Assuming you’re using a folder that is Git version-controlled,
again it becomes simple to copy the folder (make sure to include the
hidden files and folders that are part of the Git setup). Copying the
entire contents enables you to keep your version-controlled contents
of the HTML files within easy access to all previous versions that are
stored online.