Webinoly full example and tutorial

Cristhian Martínez Ochoa

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 the example.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 the example.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.
  • Daily at 3:00pm
    • Local backup of the database in $HOME/webinoly-backups/example.com of the example.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 the example.org site.

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.