Site Management for NGINX Server with Webinoly

The “Site” command allows you to manage the websites hosted on the server. Create any type of site on your new server, add an SSL certificate, activate FastCgi Cache for your WordPress installation and more features that will allow you to have total control over your sites easily and reliably, always at a command away and with no complications.

Syntax:

sudo site <domain> <option> <option2>

Options:

-cache
-clone-from
-delete
-delete-all
-empty
-force-redirect
-forward
–html
-info
-list
-multisite-convert
–mysql
-on
-off
-parked
–php
-proxy
-redirection
–ssl
-wp

Examples:

# Create PHP site
sudo site example.com -php

# Create WP site with cache enabled
sudo site example.com -wp -cache=on

# Disable cache
sudo site example.com -cache=off

# SSL Cert
sudo site example.com -ssl=on

# List of your sites
sudo site -list

# Clone a WP site
sudo site example.com -clone-from=staging.example.com

# Page redirect
sudo site example.com -redirection

Create a new site

Create a new website of any type: HTML, PHP, WordPress, Reverse Proxy, etc.

To create a basic HTML site, use the following command:

sudo site example.com -html

To create a site with PHP support.

sudo site example.com -php

All sites using the primary/main domain (not a subdomain) are configured to respond to requests from example.com and www.example.com (See the force-redirect option).

Also, when creating a PHP site, you should take into consideration that Webinoly uses this configuration for Nginx: try_files $uri $uri/ /index.php$is_args$args;. That means that everything relies on your index file, and 404 codes will need to be processed in your PHP code.

To create a PHP site in conjunction with a database:

sudo site example.com -mysql

The data to connect to the database will be displayed after executing the command.

You can also use the “custom” option to introduce your own data before generating the database sudo site example.com -mysql=custom or in the same way you can pass the data directly.

# TIP Hack
# Use the -mysql option without domain to create a DB and User (MySQL)
sudo site -mysql

# Custom data
sudo site example.com -mysql=custom

# Custom data
sudo site -mysql=[host,dbname,dbuser,password]
sudo site example.com -mysql=[host,dbname,dbuser,password,external_dbuser,external_dbpass]

# TIP
Use "random" (without quotes) as password to automatically generate a random password.

Also, FastCGI Cache is supported for any PHP site, this way you can reduce the load and CPU usage associated with php-fpm processes.

WordPress

Installing WordPress has never been so easy, Webinoly automatically configures the entire installation.

sudo site example.com -wp

And that’s it! It’s that simple!

Custom WordPress installation

Of course, you can customize whatever you want during site creation according to your needs.

Use the “custom” option to modify some aspects of the database, in any way you can simply press <Enter> in each question to use the suggested data.

# Installation script of a WordPress site using the "custom" configuration
sudo site example.com -wp=custom -cache=on

In the same way, you can pass the data directly from command line.

# WordPress installation script with custom data.
sudo site example.com -wp=[<setup_db>,<setup_wp>,<host>,<dbname>,<dbuser>,<dbpass>,<wp_prefix>,<external_db_user>,<external_db_pass>]

# Example:
sudo site example.com -wp=[true,true,localhost,example_com,example_user,password,wp_]

# TIP
Use "random" (without quotes) as password to automatically generate a random password.

You can also modify the privileges assigned to the DB user of each site created: sudo site example.com -wp -db-role=extra. Read the “Default database privileges” section for more details.

A WordPress configuration file wp-config.php is always created automatically by Webinoly and saved one folder below for extra-security: /var/www/example.com/wp-config.php, out of the public access folder (htdocs). Except when WP is installed in a subfolder. If for some reason, you copy or move this file, or you create your own file in htdocs, please remove or rename the old one to prevent an undesired behavior because Webinoly will see it as duplicate files.

External Database

Webinoly supports the use of external databases, for example Amazon RDS or any other (in fact you can configure an external DB server with Webinoly).

# Example
sudo example.com -wp=custom

# You will be asked for some data
Database Host [localhost]: myinstance.123456789012.us-east-1.rds.amazonaws.com:3306

You can even save the data from your external database in the Webinoly Configuration File and this way Webinoly will use it always by default (as if it were localhost).

* It is important to consider that the url should not contain the schema (http/https) at the beginning, and it should be taken into account that a poor design or implementation in the architecture of this kind of solutions can have a negative impact on the speed of your site, high latency or even multiple connection errors and timeouts.

** It has been successfully tested with Amazon RDS using MySQL, MariaDB and Amazon Aurora as the database engine.

*** All the external DB credentials are stored in a MySQL CNF file following the official recommendations, this way Webinoly doesn’t need to ask for these credentials every time. Some Webinoly options have support for the -external-db=[user,pass] parameter, you should know that this parameter has more precedence, therefore it can be used to rewrite/update these credentials when supported.

WordPress Multisite

Converting your WordPress site to Multisite has never been so easy.

sudo site example.com -multisite-convert

It will ask and you should go to “Tools -> Network Setup” to select the type of installation (subdomain or subdirectory); Webinoly will do all the configuration automatically once you have selected the type of Multisite you want.

* If your site has been installed with the -subfolder option, only the “subdirectory” option will be available when converting to multisite, WordPress does not allow subdomain configuration in this type of installation.

Replace Content

The replace-content option can be used alone in any other WordPress site to search and replace any word or string in your content.

sudo site example.com -replace-content

Then you will be asked for the search/replace words, or you can use the example below to skip questions.

# To skip questions
# Note that some restrictions apply when using this option, like using spaces or quotes is not allowed.

sudo site example.com -replace-content=[search-this,replace-with]

In case your WP site – to clone or replace content – is connected to an external database, it will be necessary to enter the username and password. To skip these questions you can use the -external-db=[user,pass] option.

WordPress Environment Type

Set the WP_ENVIRONMENT_TYPE variable in WordPress:

production
staging
development
local

sudo site example.com -env=staging

In staging, development and local the FastCGI Cache will be disabled automatically. Also, the option “Discourage Search Engines from indexing this site” from WordPress “Settings > Reading” will be enabled automatically.

In development and local the WordPress “debug” mode will be enabled automatically. And will be disabled when changed to “staging” or “production”.

# Examples:

# Keep cache enabled
sudo site example.com -env=staging -cache=on

# Create a new WordPress site
sudo site example.com -env=development -wp

# The new cloned site will be set as "staging"
sudo site example.com -env=staging -clone-from=sub.example.com -overwrite=on

Configurable Subfolders

One of the most powerful tools for configuring your sites on your server is the ability to independently configure each subdirectory of a particular site.

sudo site example.com -html -subfolder=/one
sudo site example.com -php -subfolder=/two
sudo site example.com -wp -subfolder=/three
sudo site example.com -proxy -subfolder=/four

# Delete a subfolder site
sudo site example.com -delete -subfolder=/xxx

It is even optional to have a site at the root of the domain, that is, it is possible to have only support in the subdirectories configured in any combination of configurations that you need.

# Example with subfolders and empty root
+ example.com <empty>
  - /blog <wp>
  - /downloads <proxy>
  - /tickets <php>

# Another example with static site in root
+ example.com <html>
  - /news <wp>
  - /clients <php>

* NOTE: All sites installed in a subfolder using this method, including WP as described below, will have an independent configuration, and most of these files you can find them in the apps.d Nginx folder. That means that some changes in some settings will not affect these subfolders.

Install WordPress in a subdirectory

You can have more than one WordPress installations under the same domain.

sudo site example.com -wp -subfolder=/test

You should always specify the -subfolder argument to refer to this site and thus differentiate it from a common installation at the root of the domain.

sudo site example.com -delete -subfolder=/test
sudo site example.com -cache=on -subfolder=/test
sudo site example.com -multisite-convert -subfolder=/test
sudo site example.com -clone-from=dev.example.com -subfolder=/test
sudo site example.com -replace-content -subfolder=/test
sudo site example.com -env=staging -subfolder=/test
sudo site example.com -info -subfolder=/test
sudo webinoly -backup=local -export=example.com -subfolder=/test
sudo webinoly -backup=local -wp=example.com -subfolder=/test
sudo webinoly -backup=s3 -add-db-pre=example.com -subfolder=/test
sudo webinoly -clear-cache=example.com -subfolder=/test
sudo httpauth example.com -wp-admin=on -subfolder=/test
sudo httpauth example.com -path=/test/folder/ -subfolder=/test
sudo log example.com -wp=on -subfolder=/test

Parked domain or alias

A parked domain is an additional or alternate domain that points to a main site. It is a simple way to access your site from different domain names.

sudo site example.com -parked

When executing the command you will be asked to enter the name of the main domain where the new parked domain will point to. In the same way you can use the command as follows to facilitate its use:

sudo site example.com -parked=mainsite.com

Make sure the main site is hosted on the same server.

Automatic WordPress Domain Mapping

If you are creating a parked site and your main site is a WordPress Multisite, then we can do the Domain Mapping process automatically if you want, you just need the subsite “WP Blog ID”.

sudo site example.com -parked=mainsite.com -domain-mapping-wp-id=3

Or you can do it manually following the steps for Domain Mapping described on the official WordPress documentation.

Domain forwarding

All requests to this domain will be redirected or forwarded to another domain.

sudo site example.com -forward=example.org

All the request parameters are passed to the new domain. If you want to remove these parameters and force a redirection to a single site you can use the -root=on option.

# example.com/news  -->  example.org/news
sudo site example.com -forward=https://example.org

# example.com/news  -->  example.org
sudo site example.com -forward=https://example.org -root=on

Reverse Proxy site

A reverse proxy server is a type of proxy server that directs client requests to the appropriate backend server.

To create a site with Reverse Proxy configuration in Nginx:

sudo site example.com -proxy=[localhost:8080]

# Examples:
sudo site example.com -proxy=[127.0.0.1:8080]
sudo site example.com -proxy=[https://example.com]
sudo site example.com -proxy=[http://example.com:8080]

# You are running a Node.js app in port 3000
sudo site example.com -proxy=[localhost:3000]

# You are running a Java app in port 8082
sudo site example.com -proxy=[localhost:8082]

# You are running a Vue app in port 8080
sudo site example.com -proxy=[localhost:8080]

# You are running a Python app with Django and Gunicorn
sudo site example.com -proxy=[localhost:8000]
# In case you are using sockets with Gunicorn
sudo site example.com -proxy=[http://unix:/home/<user>/<project_name>/<project_name>.sock]

# Ghost
sudo site example.com -proxy=[localhost:2368]

* As you can see in the examples above, URI is not allowed due to Nginx restrictions http://localhost:8000/uri/ or http://unix:/tmp/backend.socket:/uri/ , URI is not allowed in upstreams and also our Reverse Proxy configuration includes some location blocks that are specified using regular expressions. We have created a special case for when there is no other option than supporting the URI part, read the “simple” Dedicated-Reverse-Proxy section below.

** Nginx configuration for Reverse Proxy sites can be safely modified with your custom rules, please read the Nginx section.

Same as any other site, Reverse Proxy sites are protected by some basic rules and headers, dotted files and some names and extensions are blocked by default, which is great when you have a website behind the Reverse Proxy, but it can be not what you want in some other cases. That’s why we have created the “Dedicated Reverse Proxy” sites that you can read the details below.

Dedicated Reverse Proxy

Unlike the previous ones, this configuration is completely transparent, which may be ideal in some cases, such as file repositories.

sudo site example.com -proxy=[https://repo.example.org] -dedicated-reverse-proxy

When you create a “dedicated reverse proxy” site, then only “dedicated reverse proxy” sites will be allowed in subfolders under this domain, in the same way these dedicated sites are not allowed in subfolders of any other type of existing sites.

Never use a “Dedicated” reverse-proxy for websites: a lot of unsafe files will be publicly exposed to internet, also some HTTP headers will be removed. Dedicated reverse-proxy should only be used for file repositories, like S3 or similars, unless you know what you’re doing.

# Example: S3 file repo behind a Reverse Proxy
sudo site example.com -proxy=[https://s3.bucket1.aws.com] -dedicated-reverse-proxy

# Add an SSL Cert
sudo site example.com -ssl=on -manual=http

# Add a second bucket in a subfolder
sudo site example.com -proxy=[https://s3.bucket2.aws.com] -dedicated-reverse-proxy -subfolder=/images

Another example using a website app:

# Example: Website APP in localhost
sudo site example.com -proxy=[localhost:8082]

# Add an SSL Cert
sudo site example.com -ssl=on -root-path=/opt/app/web

# In this case, you can have any other type of site in a subfolder
sudo site example.com -wp -subfolder=/blog

Also, FastCGI Cache is supported for any Reverse-Proxy site, this way you can reduce the load and requests to the origin (upstream) servers.

The simple dedicated reverse proxy is a special case that we have created with some limitations to support the URI part in the backend path, https://s3.bucket1.aws.com/uri-path/ for instance. Just use the -dedicated-reverse-proxy=simple option. This configuration is not using the Nginx Upstream block and is passing the backend directly into the proxy_pass directive instead.

Fully Custom Sites

This is the perfect option if want to build your site Nginx configuration from scratch.

sudo site example.com -empty

Now, you’re ready to include all your own Nginx code using a Custom Configuration File.

# Example
sudo site example.com -empty

# Your own Nginx Configuration
sudo nano /var/www/example.com/custom-nginx.conf

# Basic configuration in /var/www/example.com/custom-nginx.conf
location / {
    try_files $uri $uri/ =404;
}

The new site created has their own server block as any other site, depending on your needs you will need at least one location / block in your custom configuration as you can see in the example above.

As in any other site, some basic locations locations.conf are included by default. Use the -empty=blank option to not include all these default settings, also some HTTP headers will be removed.

Management Tools

Some very useful commands to manage your sites.

Cloning a site

Now, you can clone any type of site, not just WP.

This feature is also known as “staging sites” due to its usefulness during the development stage.

sudo site example.com -clone-from=dev.example.com

Any of these features – if present -, it will not be inherited to the cloned site: SSL cert, force-redirect, default-site or tools-site settings, any custom Nginx file.

For WordPress sites you should consider the following:

Every link in your content will be updated automatically, you can disable this option using the -replace-content=off parameter.
Note that WordPress Multisite cannot be cloned, since each site in the network is like an independent site, there is no practical way to clone all the network. If you want to clone just one site inside a multisite network, just use a free WP plugin.
Also, you can set or change the WP Environment Type of the cloned site using the -env=staging parameter.

To clone and overwrite an existing site you can use the -overwrite=on parameter.

Example: Development Cycle

# Create a new development site
# WP debug mode enabled, cache disabled and noindex for search engines
sudo site dev.example.com -wp -env=development

# Staging site waiting for client approval
# Debug disabled, cache disabled and noindex
sudo site staging.example.com -env=staging -clone-from=dev.example.com

# Overwrite your old site in production
# Cache enabled, debug disabled and index enabled
sudo site example.com -clone-from=staging.example.com -cache=on -env=production -overwrite=on

# Updates in local environment
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

How can I temporarily disable a site?

At any time you can activate or deactivate a site hosted on your server without deleting it.

sudo site example.com -on

sudo site example.com -off

Delete a website

You should use this option with caution, as once a site is deleted it will not be possible to recover the files.

sudo site example.com -delete

You can also use the “force” option to omit the questions (unattended) sudo site example.com -delete=force.

# Do not erase Database
sudo site example.com -delete=keep-db

# Unattended delete with external DB (Unattended Script)
sudo site example.com -delete=force -external-db=[user,pass]

# Revoke SSL Cert
sudo site example.com -delete=force -revoke=on

To remove all sites hosted on your server:

sudo site -delete-all

The databases of your WordPress sites that are currently in use will also be deleted. Some other DB’s may not be deleted, so there may be remanent stored data from your deleted sites.

# Extended example
sudo site -delete-all=force -external-db=[user,pass] -revoke=force

# Keep databases
sudo site -delete-all=keep-db

When a site is deleted, if an external database is found, an attempt will be made to use the data from -external-db , if they are not found, the user will be asked to enter the necessary data. The -revoke=on parameter will remove and revoke the SSL Cert of a site if found, use the “off” option to keep the SSL cert.

When a site is set as default-site or tools-site cannot be deleted. When force or -delete-all is used then these sites are forced to be deleted and each option is set as default to prevent errors.

Also, please note, that if you delete a subfolder sudo site example.com -subfolder=/test -delete all the subfolders inside will be deleted too, always.

Site Info

Display a list of information about your site.

sudo site example.com -info

* WordPress sites with external database will need your access credentials in order to display a complete info. You can use the -external-db=[user,pass] parameter, or save your data in the Webinoly Configuration file.

List of your sites

To see a list of all your sites hosted on the server, use the following command:

sudo site -list

You will also see some information of each site:

Site Type: WordPress, HTML, PHP, Parked, Proxy, Forward, Subfolders.
Assignation: If site is set as “Default” or to access Webinoly “Tools”.
Alerts: NoSSL, SSL-Staging, AccessLog, NoCache, NoAdminAuth, Debug.

# Filtered list
sudo site -list=nossl

Filter options: disabled, main, html, php, wordpress, parked, proxy, forward, tools, default, ssl, nossl, sslstaging, accesslog, noaccesslog, cache, nocache, adminauth, noadminauth, debug, nodebug, wpenv.

When WP Environment Type is not “production”, the site type will be: (WordPress:staging), for instance. To filter these sites you can use “wpenv”.

Settings and Customizations

Configure your sites according to your needs.

Force WWW or non-WWW in a site

By default, Webinoly configures your site to accept both requests in your domain, that is, example.com and www.example.com will be both valid when a main/root domain like: example.com is used (NOT for subdomains: sub.example.com).

You can force the use and redirect the requests to any of your preferences.

sudo site example.com -force-redirect=<options>

Options:

www
root
off

In some special cases where an SSL certificate has been imported from another provider and this does not include the “www” domain or vice versa, we can use the -ignore-ssl option as follows: sudo site example.com -force-redirect=root -ignore-ssl.

Nginx FastCGI Cache

The easiest and more powerful tool to optimize almost any site:

FastCGI Cache for WordPress
Custom Nginx Cache (any site)

FastCGI Cache for WordPress

Pre-configured Nginx FastCGI Cache for WordPress.

Together with Nginx this is the best optimization you can do to speed up your WordPress site. Forget about using obsolete plugins like W3 Total Cache, Super Cache or WP Rocket. FastCGI has demonstrated a performance far superior to the time to serve content cached from your server.

To enable/disable (on/off) FastCGI:

sudo site example.com -cache=on

You can also activate it from the creation of your new site as follows:

sudo site example.com -wp -cache=on

You can use the -wp-cache-plugins (on/off) parameter to skip the question for suggested plugins installation: sudo site example.com -cache=on -wp-cache-plugins=on.

Nginx Helper Plugin
It is highly recommended to use the Nginx Helper plugin to dynamically renew and purge cached content automatically; in this way we ensure to always display the most updated content when necessary.

It is important to configure the Purge Method of the plugin as “Delete local server cache file”, the support for the purge/url method has been disabled because it is considered a security risk. Similarly, the “Caching Method” should be set to “Nginx FastCgi Cache”.

To modify the global configuration of WordPress FastCGI Cache:.

Custom Nginx Cache

The same powerful Nginx Cache with support for any kind of site, not just WP.

Supported sites: PHP, WordPress and Reverse Proxy.
Independent cache configuration for each site.

sudo site example.com -cache=custom

When the Custom Cache is enabled for the first time on a site it will take the current global configuration, after that, you can start configuring your site cache using the same parameters described in the global FastCGI Cache section and they will be applied only to this specific site configuration.

# Example

# Enable Custom Cache
sudo site example.com -cache=custom

# Custom settings
# All the same options are available: -delete, -list, -regex, etc.
sudo site example.com -cache=custom -cache-valid
sudo site example.com -cache=custom -query-string-cache=one
sudo site example.com -cache=custom -query-string-never-cache=two
sudo site example.com -cache=custom -query-string-cache-default=never
sudo site example.com -cache=custom -skip-cache=/page
sudo site example.com -cache=custom -skip-cookie-cache=app_logged_in

* The order in which these rules are entered can affect the desired result. Please, read the Cache Rules Precedence section.
** Also, your own custom Nginx rules for Custom Cache can be manually entered, read the Nginx Configuration section to know how to modify these files.

Additionally, as you see above, we have support for -query-string-cache-default (all/never), and it defines the default cache behavior for query-strings. Individual rules have precedence over this default rule.

The Custom Cache can be disabled and all your custom settings will be saved and available for the next time is re-enabled.

# Disable Custom Cache
sudo site example.com -cache=off

# Just in case you need to completely remove and reset your saved settings
sudo site example.com -cache=off -reset
sudo site example.com -cache=custom -reset

When Custom Cache is used in a subfolder site (sites that were created using the -subfolder=/test option), it’s important to note that only this subfolder will be cached, not all the domain. For example: sudo webinoly -clear-cache=example.com -subfolder=/test will only have effect on this subfolder. Each site is independent and isolated, even if it’s a subfolder site configured inside of another domain.

It’s important to note that when Custom Cache is used in a WP site, it will be NOT pre-configured for WP use, and you need to start this configuration from scratch.

By default when Custom-Cache is used, absolutely all the requested pages are cached, so it is important to have a suitable configuration for each case. For example, if we wanted to recreate the configuration we use for the WP cache, it would be as follows:

# Cache Settings for WordPress
# This is the same configuration we use in the WP pre-configured option.

sudo site example.com -cache=custom -query-string-cache-default=never

sudo site example.com -cache=custom -skip-cache='"(/wp-admin/|/xmlrpc.php|wp-.*.php|index.php|/feed/|.*sitemap.*\.xml|/feed/|/account/|/add_to_cart/|/cart/|/my-account/|/checkout/|/logout/)"' -regex=insensitive

sudo site example.com -cache=custom -skip-cookie-cache='"comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in|[a-z0-9]+_items_in_cart|[a-z0-9]+_cart_hash"' -regex=insensitive

* We don’t do it by default, but in some cases, depending on how you are using the WP Rest API, you may want to include /wp-json/ to skip cache.

Basically, setting a custom cache is about preventing that some specific pages from being cached, logged-in users, sitemaps, shopping carts and checkout pages, etc. It’s that simple!

In the same way you can create your own custom rules according to your project.

Do you imagine how easy would be your custom configuration for your own app or site developed in Laravel, Java, Node, Angular, React, Vue or any other language or framework, or maybe just a different CMS like Drupal or Joomla?

SSL Certificates with Let’s Encrypt

We take advantage of the facilities provided by Let’s Encrypt to generate free certificates for your site and make it even easier to configure your site easily and quickly.

There is no pretext for not migrating your site to HTTPS, just by executing the following command your new website will be fully configured to navigate securely over HTTPS.

sudo site example.com -ssl=on

Once activated the SSL certificate, Webinoly will automatically configure Nginx to redirect all the traffic from your site from HTTP to HTTPS.

During the creation of the certificate, Webinoly will ask for your email account, this email will be used to register the new certificate, in addition to helping you to follow up the periodic renewal process.

If you prefer, you can save your email address: sudo webinoly -email=user@example.com to skip questions during the cert request.

* On existing servers this command will update the registered email in Let’s Encrypt, also the MAILTO in root cronjob will be updated.
** Ubuntu internal root email will be forwarded to this email address.

The certificates issued by Let’s Encrypt are valid for 90 days, but don’t worry, the renewal process is automatic. A timer is created in Ubuntu to check every day for certs that need to be renewed (<30 days), and also for redundancy, Webinoly automatically checks once a week the status of the certificates of all your sites.

During each weekly renewal check, you will receive an email in the account that you have registered with the current status of each certificate.

* The Must-Staple option is now disabled by default, this option can be enabled using the -must-staple=on parameter.

Disable SSL on a site

If for some reason you need to deactivate the use of the SSL certificate in your site, just execute the following command.

sudo site example.com -ssl=off

# Use the "revoke=(on/off/force)" option to skip questions. (Unattended)
sudo site example.com -ssl=off -revoke=on

When a cert fails to be revoked (for example, if you try to revoke an expired cert), in that case you will be asked if you want to delete it. Then you can use the -revoke=force option to proceed automatically.

The -ssl=off option can be used even if your site doesn’t even exist anymore as a way to remove and revoke an orphan SSL cert.

Certificates in parked sites

The “-root” option allows you to create certificates for sites where the root of your files is in a different place than usual; this is the case of parked sites, since the parked domain does not even have a root directory or own files, however, it points to another site hosted on the same server.

sudo site example.com -ssl=on -root=mainsite.com

A common and practical example of the above case is in WordPress Multisite installations with Domain Mapping, where you have one or more parked (mapped) domains on your server pointing to a main site. First do the domain mapping process before requesting a cert.

Certificates on Reverse Proxy sites

The “-root-path” option allows us to specify a different route, as is the case of sites in Reverse Proxy configuration where the files are stored in a location different than /var/www.

sudo site example.com -ssl=on -root-path=/opt/myapp/web

Only for apps hosted on the same server (localhost), for external servers you should use the manual validation described below.

Manual validation

If you want to obtain a certificate on a server or for a site that for some reason is not directly accessible from the outside, you can use the manual validation method.

sudo site example.com -ssl=on -manual=http

The manual method supports “http” and “dns” validation.

The “http” validation will ask you to place a file with a specific name and content on your site. And the “dns” validation will ask you to place a TXT record in your DNS with a specific name and content.

Please, note that certificates with manual validation will not be automatically renewed, they have to be “manually” renewed before expired (90 days). Read the “Renewing certificates” section below for more info.

Wildcard Certificates

When we need a single certificate to cover all subdomains (* .example.com). This is the kind of certificate we need in WordPress Multisite installations in sub-domain configuration.

sudo site example.com -ssl=on -wildcard

During the creation of the Wildcard certificate, it will be necessary to create a DNS record to verify the ownership of the domain.

To add a site to an existent Wildcard cert:

sudo site sub.example.com -ssl=on -add-to-wildcard=example.com

Only have support for first-level subdomains.

Renewing certificates

Although Webinoly has a redundant system for the automatic renewal process, we have an option to force it.

sudo site -ssl=renew

This command attempts to renew any previously-obtained certificates that expire in less than 30 days.

We can also force the renewal of all of the certs:

sudo site -ssl=force-renewal-all

Force renewal of a specific certificate:

sudo site example.com -ssl=force-renewal

Only for this last “force-renewal” option:

In the case of parked domains, “reverse proxy” sites or certs with manual validation, the parameter -root, -root-path, -wildcard or -manual respectively must be included to force the renewal.
This is the only way to renew a “manual” cert, including “wildcard”.

Staging environment for certs

We highly recommend testing your projects using the Let’s Encrypt staging environment before using real certs in production environment. This will allow you to get things right before issuing trusted certificates and reduce the chance of your running up against rate limits.

# Examples
sudo webinoly example.com -ssl=on -test-cert
sudo webinoly example.com -ssl=on -test-cert -wildcard
sudo webinoly example.com -ssl=on -test-cert -root-path=/opt/app/web

Always use the -test-cert parameter to activate the Let’s Encrypt test environment.

These are not real certs, they are just intended to be used for testing purposes, you will get errors if you try to access your site using this cert. You should never use these certificates in a production environment.

Custom SSL Certificate

Bring your own Cert!

You can add your own cert of any third-party vendor or your preference.

sudo site example.com -ssl=on -ssl-key=/path/cert.key -ssl-crt=/path/cert.crt -ssl-ocsp=/path/cert.pem

The -ssl-ocsp parameter is optional for OCSP support.

It’s highly recommended that you use the /etc/nginx/certs folder to store your custom certs files, this folder is included in server backups or when server is exported using Webinoly.

Redirection Manager

Creating a redirection is easy, just run this command and follow the instructions:

sudo site example.com -redirection

Remove a redirection:

sudo site example.com -redirection -delete

# Skip questions (unattended)
sudo site example.com -redirection -from=/path -to=/test -http-code=308

sudo site example.com -redirection -from=/path -to=http://example.com

sudo site example.com -redirection -from=/path -http-code=410

sudo site example.com -redirection -delete -from=/path

The -http-code parameter is optional, the default value is 302. Supported codes: 301, 302, 303, 307, 308. Also, even though they can not be considered as redirections: 403, 410, 444 and 451 are supported (destination “to” value is omitted or ignored).

You can also use the -exact option to define an exact match of URI and location.

What the "EXACT" option does?

Take this path: /news

https://example.com/news (match)
https://example.com/news/local/our-city (match)

If you use the "EXACT" option:
https://example.com/news (match)
https://example.com/news/local/our-city (no-match)

The -exact parameter is not needed when -delete, it will just remove every path that match.

Regex Supported

The “regex” option allows us to use regular expressions and on the command line must be written using single quotes, as in the example above. And it supports the following options:

sensitive – Case sensitive.
insentive – Case insensitive.
longest – Specifies the best option and does not continue evaluating regular expressions.

Check the official documentation and some examples about using regular expressions in Nginx.

# Example
sudo site example.com -redirection -from='^\.(gif|jpg|jpeg)$' -to=/test -regex=insensitive

List current redirections:

sudo site example.com -redirection -list

NGINX Configuration

If need to add additional NGINX rules, you can have your own custom configuration file located at /var/www/example.com and it should be named following the pattern *-nginx.conf.

These custom files are supported by all sites of any type.

How to add your own custom NGINX rules:

WARNING: Please, don’t just copy and paste! Before adding any custom Nginx rules, be sure about what you are doing and be sure you really need it, a lot of things are already handled by Webinoly.

For example: /var/www/example.com/custom-nginx.conf would be a valid file to include your custom rules.
More than one configuration file can be added: another-nginx.conf.
Sites created in subfolder configuration will be ruled by the main site configuration files.
Parked sites will be ruled by the main site configuration files.
- You can add specific rules for the parked site: /var/www/{maindomain.com}/*-{parkeddomain_com}_parked.conf for example: /var/www/example.com/custom-parkedsite_com_parked.conf. The same way can be applied to the main site only when it has parked sites assigned, in this case, the configuration will only apply to the main site, with no effect on the parked sites.
Included NGINX files should not be modified, all changes will be lost during some updates. There are a couple of exceptions you can take into consideration:
- Reverse Proxy configuration files can be safely modified: /etc/nginx/apps.d/example.com-proxy.conf
- Custom Cache configuration files can be safely modified: /etc/nginx/apps.d/example.com-wpcache.conf or/etc/nginx/apps.d/example.com-phpcache.conf
- In fact, all of the files in the Nginx apps.d folder are not overwritten during the update process and can be modified under your own risk, in some cases Webinoly uses some lines of code and text like comments as references, any changes can cause an unexpected behavior.
- In case you need it, you can do a server reset anytime sudo webinoly -server-reset to be sure. If you have followed all these recommendations, nothing should be broken, that’s what we do during some updates.
All these conf files are included in the “server” block in Nginx context. In case that you need it, you can include your own custom conf files in “http” context, using the “conf.d” standard Nginx folder: /etc/nginx/conf.d/*.conf.
- We have created a special case/extension of the “conf.d” folder. You can use /etc/nginx/conf.d/*.conf.srv and it will appy to ALL sites (in server context of each site, obviously).
Remember that a lot of (Nginx, PHP, etc) options can be customized in the Webinoly Configuration File: /opt/webinoly/webinoly.conf.

Webinoly automatically detects if your site is a domain example.com (example.com and www.example.com are configured) or subdomain sub.example.com (only sub.example.com), this is to determine the most appropriate Nginx configuration for each site. Domains with no-valid TLD are configured as subdomain. If for some reason you need to force a certain configuration, you can do it using the -subdomain option when creating your site or an SSL cert is requested.

Example: sudo site example.com -html -subdomain=true, or likewise sudo site sub.example.com -ssl=on -subdomain=false. As you can see, you can use the “subdomain” parameter with any other option, not just when creating a site.

The command sudo webinoly -external-sources-update is for internal use only to update some external lists, like public-suffix and timezones.

If you have any suggestions, ideas, or comments, or if you (gasp!) found a bug, join us in the Community Forum.

Sites Manager