Manage and configure your NGINX Web Server with Webinoly

The command “Webinoly” allows you to make some changes and manage the global configuration, as well as to consult some aspects of the web server. We will explain in detail the use of this command.

Syntax:

sudo webinoly <option>

Options:

-backup
–blockip
-cache-valid
-clear-cache
-custom-headers
-datadog
-db-import
–dbpass
-default-site
-dynvar
-email
-external-sources-update
-info
-login-www-data
–mysql-password
-mysql-public-access
-query-string-cache
-query-string-never-cache
-timezone
-tools-port
-tools-site
-server-reset
-skip-cache
-skip-cookie-cache
–smtp
-uninstall
-update
-verify
-version

DEPRECATED: -conf-value_ (in favor of -dynvar), -config-cache (in favor of -cache-valid), -db-role-default, -external-db-save, -header-cache-control, -header-csp, -header-hsts, -header-permissions-policy, -header-referrer, -header-robots, -header-xcto, -header-xfo, -header-xssp, -raw

Examples:

# Check for Webinoly updates
sudo webinoly -update

# SFTP Access
sudo webinoly -login-www-data=on

# Purge Cache
sudo webinoly -clear-cache

# Backups
sudo webinoly -backup=s3 -profile=mysite

# Server timezone
sudo webinoly -timezone

System Updates

Don’t forget to keep your system updated!

How do I upgrade to the latest version of Webinoly?

It is very simple, you just have to execute the following command and it will download and install the most recent version of this application.

sudo webinoly -update

It is important to note that this command only updates the Webinoly app, not the other packages installed in the server.

You should run a server update and upgrade sudo apt update && sudo apt -y upgrade at least once a month.
If you are on a VPS, you should do at least one “stop/start” cycle (not a reboot) every four months or so. Depending on your provider, it will move the instance to a new host computer.

It’s really highly recommended always keep Webinoly updated to the latest version, especially when the stack version is raised, during the stack update a lot of things are changed and if more than one of these updates are done at a time, most of the times is safe, but you are increasing the risk of breaking something due to the complexity of these updates.

High-traffic servers should have a maintenance plan to prevent doing these updates during critical hours, and maybe with no live traffic, especially when the stack is updated.

* NEVER upgrade a cloud instance do-release-upgrade or dist-upgrade if you are not an experienced user. It can easily break stuff badly!

NGINX & FastCGI Cache

NGINX and FastCGI Cache global configuration and management.

Please, note that most of the Nginx and FastCGI settings can be also modified directly from the Webinoly Configuration file.

FastCgi Cache settings

Webinoly configures three time values for Cache retention.

HTTP Code 200: Successful requests.
HTTP Code 301, 302, 303, 307, 308, 404, 410, 451: Redirects and pages not found.
Inactivity time: Remove cached data that has not been accessed in the specified time.

To modify the configuration you only have to execute the following command:

sudo webinoly -cache-valid

The time parameters must be entered in the following format:

s – seconds
m – minutes
h – hours
d – days
w – weeks
M – Months
y – years

The command also allows to automate its execution of the following way:

sudo webinoly -cache-valid=[10d,1w,5m]

The first argument is the response for 200 codes, the second the downtime and the third for redirects.

Clear/Purge Cache

Options:

fastcgi
redis
memcached
opcache
all
<domain>

# Example:
sudo webinoly -clear-cache=fastcgi
sudo webinoly -clear-cache=all

# Sites with Custom Cache
sudo webinoly -clear-cache=example.com
sudo webinoly -clear-cache=example.com -subfolder=/test

Exclude URL from Cache

Exclude an URL from being cached by FastCGI.

sudo webinoly -skip-cache=/page

* Pre-Configured Cache for WordPress option have already included by default some pages to being excluded. Read here!

Examples:

# Exclude one page
sudo webinoly -skip-cache=/test

# Regex supported (sensitive|insensitive)
sudo webinoly -skip-cache='^(one|two)$' -regex=insensitive

# List of pages excluded
sudo webinoly -skip-cache -list

# Remove page from being excluded
sudo webinoly -skip-cache=/test -delete

* The order in which these rules are entered can affect the desired result. Please, read the Cache Rules Precedence section.

The -regex parameter for regular expressions support is described here.

Cache is disabled when this cookie is present.

sudo webinoly -skip-cookie-cache=<cookie>

* Pre-Configured Cache for WordPress option have already included by default some cookies to being excluded. Read here!

Examples:

# Add a cookie to exclude
sudo webinoly -skip-cookie-cache=wordpress_logged_in

# Regex supported (sensitive|insensitive)
sudo webinoly -skip-cookie-cache='^(one|two)$' -regex=insensitive

# List of cookies excluded
sudo webinoly -skip-cookie-cache -list

# Remove cookie from being excluded
sudo webinoly -skip-cookie-cache=wordpress_logged_in -delete

* The order in which these rules are entered can affect the desired result. Please, read the Cache Rules Precedence section

The -regex parameter for regular expressions support is described here.

Query-String Cache

URL’s that contains query-strings are never cached by default. You can specify some exceptions to be cached.

sudo webinoly -query-string-cache

Also, you can specify which query-strings (if present), should never be cached.

sudo webinoly -query-string-never-cache

# Example:
sudo webinoly -query-string-cache=one
sudo webinoly -query-string-never-cache=two

# example.com/?one=true&three=true  (Cached)
# example.com/?one=true&two=true  (No-Cached)

-----

# Remove query-string
sudo webinoly -query-string-cache=one -delete
sudo webinoly -query-string-never-cache=two -delete

# Lists supported
sudo webinoly -query-string-cache -list
sudo webinoly -query-string-never-cache -list

* The order in which these rules are entered can affect the desired result. Please, read the Cache Rules Precedence section

Cache rules precedence

The last rule executed has more precedence:

The query-string-cache-default is always on top.
The query-string-cache and skip-cache are always added at the beggining (after query-string-cache-default). The final result depends on the order of how it was entered.
The query-string-never-cache and skip-cookie-cache are always added at the bottom. The final result depends on the order of how it was entered.

Block and deny IP address

To restrict access in Nginx to a specific IP or block of addresses.

sudo webinoly -blockip=123.231.12.31

In the same way we can use the -purge option to remove it from the list of blocked addresses.

Or to list all the IP’s that have been blocked:

sudo webinoly -blockip -list

# Remove IP from the list
sudo webinoly -blockip -purge
sudo webinoly -blockip=123.231.12.31 -purge

# Multiple IP's
sudo webinoly -blockip=1.1.1.1,2.2.2.2

Default Website

If you access your server from your browser using the IP of the server you will see the Welcome page of Nginx, which is the answer that is configured by default.

Webinoly allows you to customize the site or answer by default.

sudo webinoly -default-site=<option>

default – Nginx default behavior.
blackhole – Any request that does not correspond to an existing domain in the server will return a 444 code in response or in other words, the server will not respond to those requests.
domain – Define an existing domain or site as default response to any request.

More complex solutions can be created according to your needs, for example: create a site with a forwarding domain configuration in Webinoly and set it as default-site, then all these request will be redirected to a different server.

Don’t use an IP address to access the WordPress admin section (especially for new installations), configurations and posts modified or created can have an undesired behavior.

HTTP Headers Configuration

The HTTP Headers listed below are supported and can be modified or enabled in the Webinoly Configuration File.

Cache-Control
Content-Security-Policy (CSP)
HTTP Strict-Transport-Security (HSTS)
Permissions-Policy
Referrer-Policy
X-Content-Type-Options
X-Frame-Options
X-Robots-Tag
X-XSS-Protection (no longer recommended, use CSP instead)

Read our blog post: CSP Practical Example

# Default headers included:

Cache-Control: "no-cache"
Referrer-Policy: "no-referrer-when-downgrade"
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

How to add my own custom HTTP headers

There are 3 contexts in Webinoly to include your headers:

HTTP – Every request.
HTML – Only pages (static files requests like images, CSS, JS, etc. are not included)
HTTPS – Every request (only when HTTPS protocol is used).

# Create a file:
# /opt/webinoly/templates/source/custom_header_http_webinoly.data
# /opt/webinoly/templates/source/custom_header_https_webinoly.data
# /opt/webinoly/templates/source/custom_header_html_webinoly.data

Every line starting with add_header and ending with a semicolon will be included in the context described in the name of the file. Be careful of not ending the line with spaces or any other character.

# Example
add_header Save-Data "on";
add_header X-DNS-Prefetch-Control "off";

Now you are ready to load your own custom headers:

sudo webinoly -custom-headers=reload

You can modify your source files any time, just remember to do a “reload” every time for changes to take effect. If you want to disable your loaded custom headers use the “remove” option.

# Included headers by context:

HTML:
Cache-Control
Referrer-Policy
Permissions-Policy
Content-Security-Policy

HTTP:
X-Frame-Options
X-Content-Type-Options
X-XSS-Protection
X-Robots-Tag

HTTPS:
Strict-Transport-Security

MySQL Tools

MySQL management tools.

Recover MySQL username and password

Webinoly saves a copy of users and passwords generated automatically during the installation of MySQL since these data are necessary to execute some commands, like the creation of the database for WordPress sites, among others.

sudo webinoly -dbpass

After the installation, an obfuscated copy of these passwords (root/admin) are stored in the Webinoly Configuration file, you should know that you can remove these stored passwords with some considerations:

The password of the “root” user cannot be recovered.
The password of the “admin” user is also found in a MySQL CNF file following the official recommendations, so it could be manually retrieved by the user.
Normally when sudo webinoly -server-reset is executed, the password of the “admin” user is regenerated in the CNF using the value saved in the Webinoly Configuration File, so if they are removed, this functionality will be lost.
Even when the passwords have been removed, the method described in the next section should always be used to modify or change any of these passwords, in this way the CNF will be updated with the new password automatically.

Change MySQL password

It’s very important, you should NEVER modify manually or by your own the password of the “root” and “admin” users, they are the only ones that Webinoly saves and uses to work. In case that you do it, Webinoly will lose access to these users, and that’s why we have created this command; in case that you need to modify some of these passwords, you should always do it using this command, this way Webinoly will always have access to the updated credentials.

sudo webinoly -mysql-password

We can also use it in the following way: sudo webinoly -mysql-password=[user,pass].

With this command, you can update the password of any existing user, but it will only save the data, and it’s only mandatory for “root” and “admin”.

Access to phpMyAdmin and other tools

To access the admin area you can do it from your browser using your IP or your selected domain and port as follows: http://ser.ver.ip:22222.

You will also find here some additional tools like PHP (info, ping and status), NGINX Status, etc.

This area is protected with HTTP Authentication, read about the HTTPAUTH command to create your credentials.

At any time you can modify the access port (0-65535), by default we use port 22222.

sudo webinoly -tools-port

In the same way, you can automate the execution of the command as follows:

sudo webinoly -tools-port=19816

It is also possible to define an existing domain for “only access” to these tools.

sudo webinoly -tools-site=example.com

Any request from another domain will be blocked.

Now you can access your tools using example.com:19816 from your browser. If you want to reset and remove any domain previously set, use the default option: sudo webinoly -tools-site=default.

Import MySQL database

Import a MySQL database directly from the command line.

sudo webinoly -db-import

# Examples
sudo webinoly -db-import -file=/folder/name.sql

# Support for external database
sudo webinoly -db-import -file=/folder/name.sql -external-db=[user,pass,host:port]

In case you need to export a database you can use our own tool to make a local DB backup of your site.

Default database privileges

You can change the default DB user privileges assigned when a site with MySQL database is created, like a WordPress site, for instance.

By default we use “full”, and “limited” is the minimun necessary for WP sites. The “all” privileges option is not allowed in some external services like AWS RDS.

Modify this value in the Webinoly Configuration File.

basic – SELECT,INSERT,UPDATE,DELETE
limited – SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,INDEX,ALTER
extra – SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,INDEX,ALTER,LOCK TABLES
complete – SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,INDEX,ALTER,CREATE TEMPORARY TABLES,EXECUTE,CREATE VIEW,SHOW VIEW,CREATE ROUTINE,ALTER ROUTINE,EVENT,TRIGGER
full – SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,INDEX,ALTER,CREATE TEMPORARY TABLES,EXECUTE,CREATE VIEW,SHOW VIEW,CREATE ROUTINE,ALTER ROUTINE,EVENT,TRIGGER,REFERENCES,LOCK TABLES
grant – SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,INDEX,ALTER,CREATE TEMPORARY TABLES,EXECUTE,CREATE VIEW,SHOW VIEW,CREATE ROUTINE,ALTER ROUTINE,EVENT,TRIGGER,REFERENCES,LOCK TABLES,GRANT OPTION
all – ALL PRIVILEGES

Also, you can change it just for a especific site during site creation: sudo site example.com -wp -db-role=extra

MySQL Remote Access

By default MySQL (MariaDB) is configured to not allow connections to the MariaDB server from other hosts or from the same host over TCP/IP on a different interface than the loopback (127.0.0.1 or localhost).

To enable MariaDB to listen to remote connections (on/off):

sudo webinoly -mysql-public-access=on

If your system is running a software firewall (or behind a hardware firewall or NAT) you must allow connections destined to TCP port that MariaDB runs on (by default and almost always 3306).

In case that you need it, you can create a user with “all privileges” and remote access (%):

sudo webinoly -mysql-public-access=on -create-master-user=[username,password]

We use it internally, but we will share it with you. For just “replication slave” instead of “all privileges”:

sudo webinoly -mysql-public-access=on -create-master-user=[username,password] -replication-slave

* Use “random” (without quotes) as password to automatically generate a random password.

Example of a WordPress site with MySQL database remote server:

# Server A (IP: 1.1.1.1)
# This will be the remote MySQL server

# Install MySQL (MariaDB) only
wget -qO weby qrok.es/wy && sudo bash weby -mysql

# Remote access enabled
sudo webinoly -mysql-public-access=on -create-master-user=[masteruser,abcdefgh]


# Server B
# This will be the webserver

# Install Nginx and PHP
wget -qO weby qrok.es/wy && sudo bash weby -php

# Create a WordPress site
sudo site example.com -wp=custom

# Then you will be asked for custom data
Database Host: 1.1.1.1:3306
External DB Master Username: masteruser
External DB password: abcdefgh

# And that's it!

Server Management

Server management tools and configuration.

Allow SFTP access to www-data user

Very useful for uploading files through SFTP, this user has very limited access permissions and can only be used to log in through SFTP and with access only to the data folders of your websites.

sudo webinoly -login-www-data=on

You can block the access at any time.

sudo webinoly -login-www-data=off

* In case you are using SSH keys, www-data user will use the same SSH Keys as the main user.

Set Timezone

This command will set the timezone in PHP and in Ubuntu operating system.

sudo webinoly -timezone

You can also directly pass the data in the following way: sudo webinoly -timezone=America/Mexico_City. Check the supported timezones.

SMTP setting for sending emails

Postfix is always installed with Webinoly for sending emails, for instance, all your WordPress sites notifications, and now you can also configure it to send emails using an external SMTP provider such as Amazon SES, Mandrill, Mailgun, SendGrid or any other provider.

sudo webinoly -smtp

All the server outgoing emails from any of your websites will be sent through this service.

# Test the SMTP service from command line:
echo "Subject: test" | sendmail user@example.com

# Remove the SMTP configuration and use the Postfix default configuration
sudo webinoly -smtp -purge

# Tip for Unattended Scripts
sudo webinoly -smtp=[smtp_host,user,password,mainhost.com]

The “mainhost” refers to the domain that will be used by default to send emails when this data is not provided and it must be an existing domain on the server.

What are DMARC, DKIM, and SPF?
SPF, DKIM, and DMARC help authenticate email senders by verifying that the emails came from the domain that they claim to be from. These three authentication methods are important for preventing spam, phishing attacks, and other email security risks.

Backups

Webinoly has a complete set of tools for backups:

Export/Import server or site
Database backups
Incremental Backups with S3 (AWS or any other S3 Compatible service)

sudo webinoly -backup

* You can manually configure any backup supported by Duply and Duplicity: Amazon S3, Backblaze B2, DropBox, FTP, GIO, Google Docs, Google Drive, HSI, Hubic, IMAP, local filesystem, Mega.co, Microsoft Azure, Microsoft Onedrive, par2, Rackspace Cloudfiles, rsync, Skylabel, ssh/scp, SwiftStack, Tahoe-LAFS, WebDAV.

** Most common S3 Compatible services: Backblaze B2, Digital Ocean Spaces, Wasabi, Vultr Object Storage, Linode Object Storage, DreamObjects, etc.

Export/Import server or site

Moving a site or the whole server has never so easy!

Export server settings and sites:

sudo webinoly -backup=local -export

A file will be created containing all your server data.

Options to import on a new server:

full – Configuration and sites.
stack – Only configuration.
sites – Only sites.

sudo webinoly -backup=local -import=full

When configuration is imported, all the packages will be installed and configured based on the exported configuration. For example, you can install Webinoly using the option “-clean” on a new and fresh server and build (import) your stack based on an exported configuration.

# Export server
sudo webinoly -backup=local -export

# Import on a new server
sudo webinoly -backup=local -import=full -file=/folder/name

The “stack” option also support importing your configuration based on your Webinoly Configuration file, this is an easy way to ship them to all your dev team. Just bring this single file /opt/webinoly/webinoly.conf (you can even rename the file if you want) and all your team can have the same standardized dev environment, this is the easiest way to replicate your custom settings across all your team.

To export/import a specific site:

# Export a site
sudo webinoly -backup=local -export=example.com

# Import a site
sudo webinoly -backup=local -import -file=/folder/name

# Import and overwrite an existing site
sudo webinoly -backup=local -import -file=/folder/name -overwrite=on

Multiple sites and WP in subfolder are also supported:

# Export multiple sites
sudo webinoly -backup=local -export=[example.com,example.org,example.net]

# WordPress installed in a subfolder
sudo webinoly -backup=local -export=example.com -subfolder=/test

Due to Let’s Encrypt (certbot) limitations, it is not possible to export/import an SSL certificate from a particular site. However, when a complete server is exported/imported we can move all of them.

For WordPress sites a database backup is included automatically. When export/import you can use the -skip-db to not include the database. Also, a custom file name and path can be defined for the exported output file: -filename=test.bkp -destination=/folder.

External databases won’t be included when exporting your sites. You can export/import your sites and your site’s configuration should be preserved, so the connection with the external DB should be automatically established. In case you need a backup of your external database, you can easily create a database backup as is detailed in the next section below.

Database backups

At any moment you can make a database backup of any database or WordPress site and it will be saved locally in your server storage.

sudo webinoly -backup=local

# Examples for WP sites
sudo webinoly -backup=local -wp=example.com

# Multiple WP sites
sudo webinoly -backup=local -wp=[example.com,example.org,example.net]

# WordPress in subfolder
sudo webinoly -backup=local -wp=example.com -subfolder=/test

# Custom destination folder
sudo webinoly -backup=local -wp=example.com -destination=/folder

# Limit the number of local backups to keep (max) and send it to S3
sudo webinoly -backup=local -wp=example.com -destination=/folder -max=5 -bucket=bucketname/folder

* The “max” option deletes any file in the destination directory.

In case of your WP site is connected to an external database, you will be asked to enter the username and password. To skip these questions you can use the -external-db=[user,pass] option.

# Example using DB name
sudo webinoly -backup=local -dbname=db_name

# Multiple DB's
sudo webinoly -backup=local -dbname=[db_name1,db_name2,db_name3]

# All databases
sudo webinoly -backup=local -dbname=all

# External Database
sudo webinoly -backup=local -dbname=db_name -external-db=[user,pass,url:port]

To save the backup file with a specific name you can use the -filename=db.sql parameter.

Incremental Backups with AWS S3

Incremental backups of any folder and send it to S3.

Create as many profile backups as you need.

sudo webinoly -backup=s3

We use the newer Boto3 backend to connect with S3.
Bucket creation is not supported.
Support only for the newer domain style buckets.
- Read: Bucket Naming Rules
- Read: Virtual Hosting (Path Style requests will be deprecated by AWS)
Restores from the glacier storage class are not supported.

Before you can make a backup, you need to have your IAM Credential with full access to S3 service.

sudo webinoly -aws-s3-credentials

# To skip questions (unattended)
sudo webinoly -aws-s3-credentials=[aws_access_key_id,aws_secret_access_key]

# Create new S3 backup profile
sudo webinoly -backup=s3 -profile=name -bucket=bucketname/folder -source=/folder -max-age=2M

# For AWS EC2 instances linked to an IAM Role
# This way it is not necessary to save credentials on the server.
sudo webinoly -aws-s3-credentials=awsiamrole

In case of S3 Compatible services (no AWS):

# Support for S3 Compatible services, like Backblaze or any other.
sudo webinoly -aws-s3-credentials=[key_id,app_key]

# Create new backup profile
sudo webinoly -backup=s3 -profile=name -bucket=bucketname/folder -source=/folder -s3-compatible-endpoint=https://s3.compatible-endpointURL.example.com

The -max-age argument is optional and is the time frame for old backups to keep, the default value is 1M and format is (s, m, h, D, W, M, Y).

To run a new backup:

sudo webinoly -backup=s3 -run

Delete an existing profile:

sudo webinoly -backup=s3 -delete

List profiles:

sudo webinoly -backup=s3 -list

Display info about an existing profile:

sudo webinoly -backup=s3 -info

Restore or recover the most recent backup:

sudo webinoly -backup=s3 -restore

If you are restoring your data in a different server, just create the same profile with the same data pointing to the same S3 bucket.

Webinoly will never overwrite data while restoring, that is a design choice to protect your data. So your destination folder must not exist.

# Backup recover one file
sudo webinoly -backup=s3 -restore=/folder/file.exe -destination=/folder/file.exe

# Backup recover one specific folder
sudo webinoly -backup=s3 -restore=/folder -destination=/folder

# Backup recover from an specific date
sudo webinoly -backup=s3 -restore -destination=/folder -date=2020/4/27

# Date format supported:
2020-01-25T07:00:00+02:00 (full date time)
2020/3/5 (YYYY/MM/DD)
12D (12 days ago)
1h78m (1 hour 78 minutes ago)

You can always use -profile=name to skip questions.

Using the -add-db-pre option allows you to configure an automatic backup of an existing WP database immediately before executing the selected S3 profile.

sudo webinoly -backup=s3 -add-db-pre=example.com

# Example
# DB backup every time S3 profile backup runs.
# Limit to 5 files to keep in DB local backup folder.
# Also, send the DB backup to a different bucket.
# DB is now backed up in 3 different locations: local folder (default), S3 backup profile and S3 bucket for DB.

sudo webinoly -backup=s3 -add-db-pre=example.com -max=5 -bucket=bucketname/folder

* Remember, you can always use -filename=test.bkp -destination=/folder to your convience.

** Duply, the tool Webinoly use to automate all the backups, has support for pre/post scripts, check the documentation.

If your site is connected to an external database, the -add-db-pre option can only be used if your DB credentials are saved with -external-db-save.

# List PRE backups configured
sudo webinoly -backup=s3 -add-db-pre -list

# Remove all the PRE backups
sudo webinoly -backup=s3 -add-db-pre -purge

Send file to S3

Send a single file to AWS S3.

sudo webinoly -backup=s3 -send-to-s3=/file -bucket=bucketname/folder

S3 Compatible services are also supported:

sudo webinoly -backup=s3 -send-to-s3=/file -bucket=bucketname/folder -s3-compatible-endpoint=https://s3.compatible-endpointURL.example.com

Datadog integration

Datadog is an external service for monitoring servers and applications, through a SaaS-based data analytics platform.

sudo webinoly -datadog

You only need an API key and Webinoly will automatically install and configure the Datadog agent on your server, including integrations with Nginx, PHP-FPM, MySQL and Redis, in addition to the logs of each service and each site hosted on your server.

# Examples:
# Full installation
sudo webinoly -datadog

# Install only the agent, without integrations or logs.
sudo webinoly -datadog=123456789 -integrations=off -logs=off

# Set up an integration (nginx, fpm, mysql, redis)
sudo webinoly -datadog -integrations=nginx

# Remove an integration
sudo webinoly -datadog -integrations=nginx -purge

# Configure the logs of an integration (on/off)
sudo webinoly -datadog -integrations=nginx -logs=on

Remember that in order to see the integrations data from your server, you need to manually install each of them in your Datadog account (Integrations menu). Also, for “Logs” you need to have an active plan with “Log Management” included in your Datadog account.

To completely remove Datadog from your server:

sudo webinoly -datadog -purge

Update, modify or reset server settings

This is an advanced function and you only have to make this type of modifications if you know the impact and result that could cause in the behavior of your server, otherwise we recommend to keep the configuration set by default.

PORTABLE : All your complex and custom stack requirements in a single config file and ship them to all your devs. This way all your team can replicate and work with the same standarized environment. Read more about how to export/import your stack.

The Webinoly configuration file is located here: /opt/webinoly/webinoly.conf

Configuration File

Operating System
- Timezone _{(date.timezone)}
- Kernel Optimization
- Percentage of RAM assigned to /run folder
- Size of Swap file
- IAM Role (AWS Credentials)
Nginx
- Nginx Branch (stable/mainline)
- Maximum Upload file size _{(client_max_body_size, upload_max_filesize, post_max_size)}
- Email Address
- SFTP Access for www-data user
- Nginx Access Logs
- Nginx Log Format
- Nginx Error Log Level
- Nginx Default Response
- Admin Tools Access
- Admin Tools Access Port
- HTTP Authentication Whitelist IP
- Block IP Access
- Block/Deny files and extensions
- FastCGI Cache times
- WordPress FastCGI Cache Defaults
- WordPress Login Basic Authenticantion
- WordPress XMLRPC
- HTTP Headers
  - Cache Control
  - Content Security Policy
  - HTTP Strict Transport Security (HSTS)
  - Permissions Policy
  - Referrer Policy
  - X-Content-Type-Options
  - X-Frame-Options
  - X-Robots-Tag
  - X-XSS-Protection
PHP
- PHP Version
- Process Manager _(pm)
- Number of child processes to be created _{(pm.max_children)}
- Maximum amount of memory that a script is allowed to allocate _{(memory_limit, opcache.memory_consumption)}
- Maximum time in seconds a script is allowed to run before it is terminated _{(max_execution_time, request_terminate_timeout, fastcgi_read_timeout)}
- Maximum number of files allowed to be uploaded simultaneously _{(max_file_uploads)}
- PHP How many input variables may be accepted _{(max_input_vars)}
- PHP OpCache Validate Timestamps _{(opcache.validate_timestamps)}
- PHP OpCache Revalidate Frequency _{(opcache.revalidate_freq)}
- Path_Info
- Redis maximum amount of memory before eviction policies _(maxmemory)
MySQL
- Database Engine
- MySQL/MariaDB Version
- External DB Credentials to use instead of localhost
- Default Database User Privileges
- General Log _{(general_log)}
- Binary Log _{(log_bin, log_bin_index)}
- Slow Query Log _{(slow_query_log)}
- Long Query Time _{(long_query_time)}
- Public/External Access

After any modification to the Webinoly configuration file, you should do a -server-reset to changes take effect, this command can update the configuration of a specific package (os, nginx, php, mysql, all) in the following way: sudo webinoly -server-reset=php. If the packages (stack) have not been installed yet, the values will be loaded automatically when you do the installation, if they are already installed, the current configuration will be updated and any changes made manually by the user will be lost.

Also, the -server-reset option can be used in many different situations when you want to restore the default configuration or remove unwanted changes you probably made manually.

When you update your hardware specs, more RAM was added, you can update your server configuration with server-reset to take the new values.
Permission/owner of some folders and files of your sites will be restored. This operation runs with “nginx”, but we have an option to use it alone if you want: sudo webinoly -server-reset=permissions.
The size of the SWAP file is calculated according to the amount of RAM available, if you need to force Webinoly to recalculate this value, you must use the parameter -recalculate=on. This option should be used with caution, reboot your server to clean the swap memory currently in use, and be sure to not do it with live traffic to prevent errors while unmounting the swap file.

You can use: sudo webinoly -dynvar=<variable> -value=<data> to modify variables in the Configuration File. Some restrictions apply, like using spaces or quotes is not allowed.

Integrity test

At any time you can verify the integrity of the files related to Webinoly and your web server.

sudo webinoly -verify

This will run a scan for all the main files and check some basic aspects of your configuration.

System information

To see all the information regarding the installation, configuration and optimization made by Webinoly on your server.

sudo webinoly -info

Normally we use it to debug and detect any errors if necessary.

You can also check the Webinoly version: sudo webinoly -version (-v, -V).

Webinoly Version – This is the official version, with each improvement to the Webinoly commands a new version is released.
Stack Version – This is the version of your web server configuration, we regularly improve the Webinoly commands, but on very few occasions we modify or update the configuration we use for Nginx, PHP or the server in general. Although it is not recommended, if you made any manual changes to the server configuration, it is very likely that it will be lost or overwritten during this update.

Uninstall Webinoly

Although we regret that you make this decision, the following command will completely remove Webinoly and all its files from the server.

sudo webinoly -uninstall

Notes:

This action will not delete your websites.
The configuration of your server, as well as the installed packages will not be affected or uninstalled.
The Webinoly commands to create and manage your server and websites will be removed and will no longer be available for use.

If you want to reinstall Webinoly your previous configuration will be recovered, in case you don’t want to generate this recovery file during the uninstall process you can use the -no-recovery parameter.

For a complete removing Webinoly guide, check our FAQ section.

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

Webinoly Settings