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.
sudo webinoly <option>
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
# 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
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 upgradeat 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
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.
# 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!
# Exclude one page sudo webinoly -skip-cache=/test # Regex supported (sensitive|insensitive) sudo webinoly -skip-cache='^(one|two)$' -regex=insensitive # List of pages excluded (-raw is supported) 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.
-regex parameter for regular expressions support is described here.
Exclude Cookie from Cache
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!
# 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 (-raw is supported) 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
-regex parameter for regular expressions support is described here.
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 (-raw is 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:
query-string-cache-defaultis always on top.
skip-cacheare always added at the beggining (after query-string-cache-default). The final result depends on the order of how it was entered.
skip-cookie-cacheare 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=126.96.36.199
In the same
Or to list all the IP’s that have been blocked:
sudo webinoly -blockip -list
# Tip - RAW option is supported to remove format. sudo webinoly -blockip -list -raw # Remove IP from the list sudo webinoly -blockip -purge sudo webinoly -blockip=188.8.131.52 -purge # Multiple IP's sudo webinoly -blockip=184.108.40.206,220.127.116.11
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.
- Content-Security-Policy (CSP)
- HTTP Strict-Transport-Security (HSTS)
- 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 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
The “raw” option is also supported to remove format:
sudo webinoly -dbpass -raw.
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-resetis 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:
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
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: 18.104.22.168) # 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: 22.214.171.124:3306 External DB Master Username: masteruser External DB password: abcdefgh # And that's it!
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.
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 email@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]
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.
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:
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.
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
# 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
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
-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
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 and
-list -raw is supported to remove format characters.
-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
# 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
-list -raw option is supported to remove format characters.
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 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:
- Operating System
- Timezone (date.timezone)
- Kernel Optimization
- Percentage of RAM assigned to /run folder
- Size of Swap file
- IAM Role (AWS Credentials)
- 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
- 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)
- Redis maximum amount of memory before eviction policies (maxmemory)
- 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.
-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.
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.
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.
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
- 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
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.