OpenCart is an opensource online store that uses Stripe for its transactions. Today we will be building a L.E.M.P. stack and setting up a SMTP in order to install an OpenCart instance on that same cloud server.
If you haven’t already, create a Linux cloud instance and SSH into it. Once we’re inside, change your working directory to /var/www. Here we can make a new directory for OpenCart:
sudo mkdir ./opencart
change your working directory to /var/www/opencart now so we can grab the latest release of OpenCart:
This is a tutorial explaining to go about installing what is known as a L.E.M.P. stack. L.E.M.P. stands for Linux, Nginx, Maria DB, and PHP. WordPress is written in PHP so this stack fulfills that requirement. The flavor of Linux this tutorial will use is Debian, sorry Arch users. That being said, many if not all steps described will still pertain to other Linux systems. As long as you install all corollary Arch repo packages listed in the beginning of this tutorial, you should be totally fine.
To start, lets bring up some documentation to help with the process. WordPress has its own documentation and tutorials found here on installing it so we can start there. Canonical also put out a tutorial on launching WordPress instance on an Apache web server running on an Ubuntu server. It sounds different than our stack but its not actually that different. If you have questions some of them might be answered in that tutorial which you can find here.
Let’s Begin:
If you haven’t already, you need to create a cloud server and SSH into it. Once you are in, we can start by installing all our projects required dependencies, so feel free to run the following command if you are running a debian system:
Now that we’re prepared, there are a few things that we need to do to set up our WordPress instance:
1) Files & Permissions
2) Set up Nginx
3) Set up MariaDB
4) Setup Certbot
5) Install WordPress via the browser
1) Files & Permissions
Now we need to grab the files that make up a WordPress instance. Change your working directory to /var/www and we can grab those files by running the following script:
wget -qO- https://wordpress.org/latest.tar.gz | tar -xz
The -q modifier sets wget to quite while the -O modifier pipes what wget is processing through stdout. Otherwise wget doesn’t pipe anything through standard output at all. This allows tar to take this file as stdin and process that file. This is a useful script when trying to grab and decompress any file.
Once you’ve extracted the contents it’s time to change ownership and permissions of this downloaded file so that Nginx can serve it. First we need to change it’s ownership to a pre-existing user called www-data. This is an account used by web servers such as Apache and Nginx, specifically for serving web data. Change your file’s permissions by running the following command:
sudo chown www-data:www-data -R ./wordpress
Assuming your working directory hasn’t changed and is /var/www/, issue the following commands. The first script finds all directories and allows the file owner full access, and while it’s group and user get the restricted access of five which means they can only execute and read. The second script finds files and disallows the www-data user from read access of them, while only granting group and user execute privileges.
sudo find ./wordpress -type d -exec chmod 755 {} \;
sudo find ./wordpress -type f -exec chmod 644 {} \;
2) Setting up Nginx
Once the files that make up WordPress have been downloaded and permissions have been set, we can direct Nginx to them. Change your working directory to /etc/nginx where we will be doing a little work.
Nginx’s configuration files, all together, have the following structure:
events {
}
http {
server {
location / {
}
}
}
The main file that houses Nginx configurations is the nginx.conf located in the /etc/nginx/ directory. This is where, by default, the event and http blocks reside. If you nano or vim into nginx.conf and scroll down, you will see a line:
include /etc/nginx/sites-enabled/*;
This is where the two halves of our configuration are put together.
To explain the configuration file structure as clearly and simply as possible: Nginx.conf houses the events and http blocks, while any files we place in ./sites-available then symbolically link into ./sites-enabled house server and location blocks.
Open ./sites-available with an IDE of your choice and copy and paste the following over what is in that file:
upstream wp-php-handler {
server unix:/var/run/php/php-fpm.sock;
}
server {
server_name url.com www.url.com;
root /var/www/wordpress;
index index.php;
try_files $uri $uri/ @blog;
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $request_filename;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTP_PROXY "";
fastcgi_index /index.php;
fastcgi_pass wp-php-handler;
}
}
Save and exit this file. Now you can run the following command to restart Nginx so it begins using the new settings we’ve programming into it. To do that, issue the following command:
sudo systemctl restart nginx
If something is wrong with the configuration file’s syntax, it will throw an error now. Otherwise it won’t say anything and we can move on.
3) Set up MariaDB
WordPress allows for the creation and use of multiple user accounts. To be able to do this, WordPress needs a database to safely store usernames and passwords. Setting up MariaDB is easy because there are setup and hardening scripts preinstalled one we install the MariaDB-server package through our operating system’s package manager. This part can get confusing because MariaDB was meant to improve upon MySQL security vulnerabilities. As a result the naming switches around quite a bit. When script invoke “mysql” remember it is manipulating the same backend. So, first run the following script and carefully read/follow it’s prompts:
sudo mysql_install_db
Second, run, carefully read, and follow the prompts for the following script to harden your MariaDB databases by removing the test database and user from your MariaDB instance:
sudo mysql_secure_installation
Login into MariaDB:
sudo mariadb
Create a new WordPress database:
CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
Create a user account associated with that database, *but switch out USER and PASSWORD ones of your choice* while also remembering these unique identifiers for later:
GRANT ALL ON wordpress.* TO 'USER'@'localhost' IDENTIFIED BY 'PASSWORD';
Now your database and user accounts are setup so you can issue the following commands to update MariaDB and exit:
FLUSH PRIVILEGES;
EXIT;
4) Setup Certbot
We’ve made it to the final and easiest part of this tutorial; setting up Certbot. You can complete this task by issuing, reading, and following the certbot toolchain to wrap up:
sudo certbot
5) Install WordPress via the browser
After setting up Certbot certifications with the E.F.F., you should be able to go to your website’s I.P. (or if you’ve set up DNS, visit via it’s URL directly). The site will redirect you to an installation page. After selecting your native language you will land on this page:
This page is asking about all the information we used to create a MariaDB database. So type in the database name (most likely wordpress), the USER username, and identifier/password from earlier. Leave the database host set as localhost, and the table prefix set to wp_.
6) Congratulations
Hurray, you’ve just set up your first WordPress instance. I recommend downloading a cache plugin as soon as possible. Now you can install and customize the site, as well as publish all your work. You can even write an article on how you set up your WordPress on a L.E.M.P. stack. Thanks for reading!
