Surely you have already read and experienced our Quick Guide – The Famous Webinoly 5-minute installation – where in a matter of minutes your Nginx server and your first site are ready and completely configured.
In the following tutorial we will show some common examples and case studies with a slightly greater degree of complexity using Webinoly in order to show you some of the potential of this tool so that you can use it as a guide to learn in a practical way the use of some commands.
Webinoly Custom installation
Update and upgrade your operating system should be always the first step: sudo apt update && sudo apt -y upgrade
We will start installing Webinoly with the option “-clean”, this means that only Webinoly will be installed, but no extra package will be installed on the server.
wget -qO weby qrok.es/wy && sudo bash weby -clean
Next we will modify some values prior to the installation of the packages.
# Webinoly Configuration File
sudo nano /opt/webinoly/webinoly.conf
# Modify these variables
max-mb-uploads:200
nginx-ppa:mainline
timezone:America/Mexico_City
We define a maximum size in PHP to upload files of 200Mb, also we will install the “mainline” branch of Nginx and set the time zone of your preference.
Now we are ready to install and configure all the necessary packages on the server. We use the “lemp” option for an installation, configuration and full optimization of Nginx, PHP and MariaDB (MySQL).
sudo stack -lemp
As a reference you should read the official Webinoly documentation, in addition to the installation instructions.
Signup for our Newsletter to be the first to know when an update is released!
Development tools
We will start by creating a development site in a subdomain:
sudo site dev.example.com -wp -env=development
The “development” WP environment will automatically enable debug mode, cache will be disabled and “noindex” for search engines.
To access the administrators area of the new WordPress site it is necessary to create a user for HTTP authentication, since it is a protected area.
sudo httpauth -add
After development is done, now we can set a staging site and wait for client approval.
sudo site staging.example.com -env=staging -clone-from=dev.example.com
Staging environment will automatically disable WP debug mode, cache will be also disabled and still “noindex” for search engines.
Site can be enabled and disabled to avoid unexpeted visitors:
sudo site dev.example.com -off sudo site dev.example.com -on
Webinoly has the “log” command to visualize the events in real-time, it also facilitates the activation and control of WordPress logs, very useful when developing themes and plugins, or the application logs such as PHP and MySQL, among others, always necessary during the development process of almost any project.
Once the project is finished you can overwrite your existing old site with the new one in production.
sudo site example.com -clone-from=staging.example.com -cache=on -env=production -overwrite=on
Debug mode is automatically disabled when production environment is set and index is enabled for search engines. Of course, FastCGI cache is also enabled.
And finally we deliver the project by adding an SSL certificate to the site.
sudo site example.com -ssl=on
Finally, we will set a local copy to make small frecuent updates.
sudo site local.example.com -env=local -clone-from=example.com
Push updates to production:
sudo site example.com -clone-from=local.example.com -cache=on -env=production -overwrite=on
Creating sites with Webinoly
The company has grown and our client has created a non-profit project, so it has acquired a “.ORG” domain to promote it.
We propose a single HTML page with general project information and contact information, including a contact form for visitors to send us their questions and then we can contact them.
A really simple project, so we started by creating the site with PHP support to execute the contact form.
sudo site example.org -php
We enable SFTP access to upload the files of the new site.
sudo webinoly -login-www-data=on
After a some revisions the project is finalized and we deliver the site, but not before adding an SSL certificate.
sudo site example.org -ssl=on
WordPress installed in a subfolder
Finally the client decides to add a blog to publish articles, so quickly and easily we add a WordPress site installed in a subdirectory of the current PHP site.
sudo site example.org -wp=custom -subfolder=/articles
Because there will be thousands of posts on this site, it was decided to use an external database in RDS service of Amazon Web Services, so we use the “custom” option to install WordPress and in this way Webinoly will request the data to connect with the database and set up the site automatically.
In addition, they have requested to remove HTTP authentication to access the WordPress administrators area of this specific site. Although not recommended, it is necessary due to the number of authors and users that this site will have.
sudo httpauth example.com -wp-admin=off -subfolder=/articles
Very important, don’t forget to enable cache for WP:
sudo site example.org -cache=on -subfolder=/articles
WordPress Multisite
Our client’s company has grown and after several updates and improvements to the main site example.com
, we are now asked to add to this site a private area for internal company publications. In addition to a new site for the newly created school to sell company certifications.
The first decision is to convert the main site to “Multisite” so that we can add sites and manage them from the same place.
sudo site example.com -multisite-convert
We configure the site with the “subdirectory” option and we will see that Webinoly automatically detects our selection and makes all the necessary configurations.
We create a new site within WordPress Multisite: example.com/members
which will be managed independently. And we also add HTTP authentication to restrict access to employees only.
sudo httpauth example.com -path=/members
Previously they used an exclusive domain example.net
for a private site where they hosted an old blog with some internal posts. It has been decided to migrate the content of the old blog to the new site and member area, so the best strategy is to redirect the old domain.
sudo site example.net -forward=https://example.com/members
Now for example: example.net/news
will be automatically redirected to example.com/members/news
.
WordPress Multisite with domain mapping
One of the current features of WordPress that I personally like the most is that it is no longer necessary to use a plugin for “Domain Mapping” and this is now a native WP function.
What do I mean by this?
It’s now possible to use a separate domain for each subsite of your multisite installation, that is, instead of using a subdirectory or a subdomain, you can use a new domain and in this way you can manage several completely different and independent websites from the same WordPress installation.
I recommend you read the official documentation “WordPress Multisite Domain Mapping“. Webinoly natively integrates this feature as described in the following example.
To create the new site for the school we have decided to use this option. We created a new site in the Multisite installation: example.com/school
, which we will access using the new domain www.example.edu
, as is shown in the example below:
sudo site example.edu -parked=example.com -domain-mapping-wp-id=2
We have already created two independent sites using two different domains and managed from the same WordPress installation.
Now, we will add an SSL certificate and force the use of “www”.
sudo site example.edu -ssl=on -root=example.com sudo site example.edu -force-redirect=www
This specific site will be managed by a department in the client’s company different than the other sites, so they have requested to create independent users for HTTP authentication.
sudo httpauth example.edu -add
In this way we add all the necessary users and they will only have access to this site, in addition to users with general access that were created in the previous sites, they will not have access to this site.
Finally, FastCGI should be enabled and due to this site use query-strings to show content in different languages, we need to add an exception to FastCGI to cache these pages.
sudo site example.edu -cache=on sudo webinoly -query-string-cache=lang
Some additional sites
On the example.org
project site, they have a file repository for download on the AWS S3 service, which they need to access from their own domain.
We will create a “Reverse Proxy” site to access the repository in S3 with our own domain.
sudo site download.example.org -proxy=[https://s3.amazonaws.com/download.example.org/] -dedicated-reverse-proxy
And now we will add an SSL Cert:
sudo site download.example.org -ssl=on -manual=http
Now we can access the repository using: download.example.org/file.jpg
.
For the management of the company’s car fleet, they have implemented a GPS tracking software (Java App) called Traccar, which is configured to use port 8082 and we need to integrate it with our sites.
sudo site gps.example.com -proxy=[localhost:8082]
Any app/site of your preference can be configured this way: Laravel, Java, Node, Angular, React, Vue, etc.
And we add an SSL certificate indicating the path where the tracking software is installed.
sudo site gps.example.com -ssl=on -root-path=/opt/traccar/web
And finally, the company’s development team is developing a new internal ticket system using a PHP framework and for its access and hosting on the server we will be creating a new site:
sudo site internal.example.com -mysql
After executing the command, the data of the newly created database that we will use to configure the new ticket application on the server is displayed. Basically it is a PHP site with a database.
In summary…
We have created a number of sites with very different requirements.
- example.com (WP Multisite)
- example.com/members (Subsite protected)
- www.example.edu (Subsite with domain mapping and auth disabled)
- gps.example.com (Java App with Nginx Reverse proxy)
- internal.example.com (PHP with MySQL)
- example.org (PHP)
- example.org/articles (WP in subfolder with independent auth and external DB)
- download.example.org (Dedicated Reverse Proxy to S3)
- example.net (Domain forwarded to example.com/members)
Webinoly Backups
With Webinoly, Duply and Duplicity come pre-installed, a couple of tools to perform backups in practically any known medium. In this tutorial we will use AWS S3 and local backups.
Webinoly has native support for any S3 Compatible service, like: Backblaze B2, Digital Ocean Spaces, Wasabi, Vultr Object Storage, Linode Object Storage, DreamObjects, etc.
We will start by making a complete backup of the entire data directory of our sites /var/www
, the backups are done incrementally, so only the first time the total data is sent, then only the changes are sent.
To connect with our S3 bucket we must have the necessary IAM credentials, in this case our server is an AWS EC2 instance to which we have attached an IAM Role, so it is not necessary to save the credentials in our server.
sudo webinoly -aws-s3-credentials=awsiamrole
With this we indicate to Webinoly that we have attached an IAM role on our server, so it is not necessary to enter the credentials.
We are now ready to configure the first backup:
sudo webinoly -backup=s3 -profile=DataBackup -bucket=america/data -source=/var/www -max-age=3M
One of the features that I personally find most useful is the possibility of including a backup of a database that will be performed automatically immediately before executing the backup that we configured in the previous step.
sudo webinoly -backup=s3 -profile=DataBackup -add-db-pre=example.com -destination=/var/www/example.com/db-backup -max=10 -bucket=america/db_com
sudo webinoly -backup=s3 -profile=DataBackup -add-db-pre=example.org -subfolder=/articles -max=3
That is, each time we run the “DataBackup” profile, the backup of both databases of the WordPress sites configured in the previous step will be performed first.
In addition, in AWS it is possible to configure the automatic replication of an S3 bucket, in this case we can replicate the “america” bucket to a different region, for example in Asia.
Now we need to add a CronJob to run this backup automatically every day at 3am. We run sudo crontab -e
and add the following lines:
0 3 * * * sudo webinoly -backup=s3 -profile=DataBackup -run
# Extra backup for the database of both sites
0 15 * * * sudo webinoly -backup=local -wp=example.com -max=10 -bucket=america/db_com
30 15 * * * sudo webinoly -backup=local -wp=example.org -max=5
# Backup of the log fiel of the ticket system.
30 3 * * * sudo webinoly -backup=s3 -send-to-s3=/var/log/internal.log -bucket=america/internal
In case you are using a user different than root, for example in AWS, you need to add the user path before ‘RUN’ any backup in your Cron (root):
0 20 * * * env HOME=/home/user sudo webinoly -backup=s3 -profile=name -run
In summary, we have configured the following backups:
- Daily at 3:00am
- Local backup of the database in
/var/www/example.com/db-backup
of theexample.com
site and is automatically sent to S3 in the/db_com
folder. - Local backup of the database in
$HOME/webinoly-backups/example.com
of theexample.org
site. - S3 backup of the entire data directory, including backup of the
example.com
database for being inside this directory. - S3 backup of the tickets system log file.
- Local backup of the database in
- Daily at 3:00pm
- Local backup of the database in
$HOME/webinoly-backups/example.com
of theexample.com
site and is automatically sent to S3 in the/db_com
folder. - Local backup of the database in
$HOME/webinoly-backups/example.org
of theexample.org
site.
- Local backup of the database in
As you can see the database is backed up twice a day and in the case of example.com
we have 3 copies of the backups (local, america bucket, asia bucket) in addition to the original. And if it is not enough, in each bucket there are two copies of the DB, one in the /data
folder and one in /db_com
. Enough?
Performance, security and Nginx additional adjustments
Normally the NGINX FastCGI cache is configured by Webinoly to expire every 30 days, this is a recommended value for websites with very low traffic.
I explain briefly, the first time you visit a certain page of your site it is saved in the FastCGI cache and it will be there until the expiration period.
If our site has just a few visitors in a day and we have configured a value, for example “1 hour”, most visitors will receive a non-cached version of the page, so there’s no benefit of having the cache enabled.
To modify the configuration and values of FastCGI in Webinoly we use the following command:
sudo webinoly -cache-valid
We will configure times of 1 hour in cache, 20 minutes of inactivity and 10 minutes for redirects [1h, 20m, 10m]. This would be a configuration that could work very well in very high traffic sites.
We will also modify access to server tools.
sudo webinoly -tools-port=18915 sudo webinoly -tools-site=example.com
Now we will access with the assigned domain and port: example.com:18915
.
After the development of the Project is finished, we will modify the default response of Nginx again as a security measure.
sudo webinoly -default-site=blackhole
Even though we already have Postfix installed for sending emails, I prefer to use an external SMTP service such as Amazon SES, Mailgun, SendGrid, etc.
sudo webinoly -smtp
We will also modify some HTTP headers.
We will set the “preload” option for HSTS, and some custom values for “Referrer” and “Content-Security-Policy”.
# Webinoly Configuration File
sudo nano /opt/webinoly/webinoly.conf
# Modify these variables
header-hsts:preload
header-referrer:origin-when-cross-origin
header-csp:default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
header-permissions:floc
Wildcard Certificates
Optionally we could use a single certificate for these sites:
- example.com
- example.com/members
- gps.example.com
- internal.example.com
First, we need to remove the current certificates from the sites -ssl=off
and create a wildcard certificate for the main site.
sudo site example.com -ssl=on -wildcard
And finally we add the rest of the sites to this certificate.
sudo site gps.example.com -ssl=on -add-to-wildcard=example.com
sudo site internal.example.com -ssl=on -add-to-wildcard=example.com
Webinoly Internal-API
The client finally had a special requirement, due to a complex process of internal audits they have a strict control of their servers, so you need that each site that is created on your server be reported to an API of your system and at the end it shows a message.
Using the Webinoly API-Internal we can add any action at almost any point of Webinoly execution. Following the instructions, we rename and use the file /opt/webinoly/lib/api-events
and we addi the following code:
api-events_catch_status() {
if [[ $1 == "si1" ]]; then
wget --timeout=10 -t 1 -qO- https://api.example.net/?createsite=true
elif [[ $1 == "sie" ]]; then
echo "All sites are reported to the example.net API in compliance with the computer systems audit."
fi
}
Conclusion
With Webinoly as we could see in the previous example the idea is always to facilitate the routine tasks to fully manage an Nginx web server, everything is a command away.
In this way, Webinoly has become the favorite tool for professionals both in web development and in the business areas of DevOps and Software Engineering as an ally to automate and streamline the deployment of servers.
If you have any suggestions, ideas, or comments, or if you (gasp!) found a bug, join us in the Community Forum.