Elasticsearch is a platform for distributed search and analysis of data in real-time. Its popularity is due to its ease of use, powerful features, and scalability.

Elasticsearch supports RESTful operations. This means that you can use HTTP methods (GET, POST, PUT, DELETE, etc.) in combination with an HTTP URI (/collection/entry) to manipulate your data. The intuitive RESTful approach is both developer and user-friendly, which is one of the reasons for Elasticsearch’s popularity.

Elasticsearch is free and open-source software with a solid company behind it — Elastic. This combination makes it suitable for use anywhere from personal testing to corporate integration.

This article will introduce you to Elasticsearch and show you how to install, configure, and start using it.

Prerequisites

Before following this tutorial, please make sure you complete the following prerequisites:

A CentOS 7 Droplet
A non-root sudo user (Check out Initial Server Setup with CentOS 7 for details.)

Except otherwise noted, all of the commands that require root privileges in this tutorial should be run as a non-root user with sudo privileges.

Assumptions

This tutorial assumes that your servers are using a VPN like the one described here: How To Use Ansible and Tinc VPN to Secure Your Server Infrastructure. This will provide private network functionality regardless of the physical network that your servers are using.

If you are using a shared private network, such as DigitalOcean Private Networking, you must use a VPN to protect Elasticsearch from unauthorized access. Each server must be on the same private network because Elasticsearch doesn’t have security built into its HTTP interface. The private network must not be shared with any computers you don’t trust.

Step 1 — Installing Java

First, you will need a Java Runtime Environment (JRE) on your Droplet because Elasticsearch is written in the Java programming language. You can use the native CentOS OpenJDK package for the JRE. This JRE is free, well-supported, and automatically managed through the CentOS Yum installation manager.

You can install the latest OpenJDK with the command:

sudo yum install java-1.8.0-openjdk.x86_64

To verify your JRE is installed and can be used, run the command:

java -version

The result should look like this:

Output of java -version
openjdk version "1.8.0_65"
OpenJDK Runtime Environment (build 1.8.0_65-b17)
OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)

When you advance in using Elasticsearch and you start looking for better Java performance and compatibility, you may opt to install Oracle’s proprietary Java (Oracle JDK 8). For more information on how to do this, please check the article on How To Install Java on CentOS and Fedora.

Step 2 — Downloading and Installing Elasticsearch

Elasticsearch can be downloaded directly from elastic.co in zip, tar.gz, deb, or rpm packages. For CentOS, it’s best to use the native rpm package which will install everything you need to run Elasticsearch.

At the time of this writing, the latest Elasticsearch version is 1.7.3. Download it in a directory of your choosing with the command:

wget https://download.elastic.co/elasticsearch/elasticsearch/elasticsearch-1.7.3.noarch.rpm

Then install it in the usual CentOS way with the rpm command like this:

sudo rpm -ivh elasticsearch-1.7.3.noarch.rpm

This results in Elasticsearch being installed in /usr/share/elasticsearch/ with its configuration files placed in /etc/elasticsearch and its init script added in /etc/init.d/elasticsearch.

To make sure Elasticsearch starts and stops automatically with the Droplet, add its init script to the default runlevels with the command:

sudo systemctl enable elasticsearch.service

Step 3 — Configuring Elastic

Now that Elasticsearch and its Java dependencies have been installed, it is time to configure Elasticsearch.

The Elasticsearch configuration files are in the /etc/elasticsearch directory. There are two files:

elasticsearch.yml — Configures the Elasticsearch server settings. This is where all options, except those for logging, are stored, which is why we are mostly interested in this file.
logging.yml — Provides configuration for logging. In the beginning, you don’t have to edit this file. You can leave all default logging options. You can find the resulting logs in /var/log/elasticsearch by default.

The first variables to customize on any Elasticsearch server are node.name and cluster.name in elasticsearch.yml. As their names suggest, node.name specifies the name of the server (node) and the cluster to which the latter is associated.

If you don’t customize these variables, a node.name will be assigned automatically in respect to the Droplet hostname. The cluster.name will be automatically set to the name of the default cluster.

The cluster.name value is used by the auto-discovery feature of Elasticsearch to automatically discover and associate Elasticsearch nodes to a cluster. Thus, if you don’t change the default value, you might have unwanted nodes, found on the same network, in your cluster.

To start editing the main elasticsearch.yml configuration file:

sudo nano /etc/elasticsearch/elasticsearch.yml

Remove the # character at the beginning of the lines for node.name and cluster.name to uncomment them, and then change their values. Your first configuration changes in the /etc/elasticsearch/elasticsearch.yml file should look like this:

/etc/elasticsearch/elasticsearch.yml

...
node.name: "My First Node"
cluster.name: mycluster1
...

Another important setting is the role of the server, which could be either “master” or “slave”. “Masters” are responsible for the cluster's health and stability. In large deployments with a lot of cluster nodes, it’s recommended to have more than one dedicated “master.” Typically, a dedicated “master” will not store data or create indexes. Thus, there should be no chance of being overloaded, by which the cluster health could be endangered.

“Slaves” are used as “workhorses” which can be loaded with data tasks. Even if a “slave” node is overloaded, the cluster health shouldn’t be affected seriously, provided there are other nodes to take additional load.

The setting which determines the role of the server is called node.master. If you have only one Elasticsearch node, you should leave this option commented out so that it keeps its default value of true — i.e. the sole node should be also a master. Alternatively, if you wish to configure the node as a slave, remove the # character at the beginning of the node.master line, and change the value to false:

/etc/elasticsearch/elasticsearch.yml

...
node.master: false
...

Another important configuration option is node.data, which determines whether a node will store data or not. In most cases, this option should be left to its default value (true), but there are two cases in which you might wish not to store data on a node. One is when the node is a dedicated “master,” as we have already mentioned. The other is when a node is used only for fetching data from nodes and aggregating results. In the latter case, the node will act up as a “search load balancer”.

Again, if you have only one Elasticsearch node, you should leave this setting commented out so that it keeps the default true value. Otherwise, to disable storing data locally, uncomment the following line and change the value to false:

/etc/elasticsearch/elasticsearch.yml

...
node.data: false
...

Two other important options are index.number_of_shards and index.number_of_replicas. The first determines into how many pieces (shards) the index will be split into. The second defines the number of replicas that will be distributed across the cluster. Having more shards improves the indexing performance while having more replicas makes searching faster.

Assuming that you are still exploring and testing Elasticsearch on a single node, it’s better to start with only one shard and no replicas. Thus, their values should be set to the following (make sure to remove the # at the beginning of the lines):

/etc/elasticsearch/elasticsearch.yml

...
index.number_of_shards: 1
index.number_of_replicas: 0
...

One final setting which you might be interested in changing is path.data, which determines the path where data is stored. The default path is /var/lib/elasticsearch. In a production environment, it’s recommended that you use a dedicated partition and mount point for storing Elasticsearch data. In the best case, this dedicated partition will be a separate storage media which will provide better performance and data isolation. You can specify a different path.data path by uncommenting the path.data line and changing its value:

/etc/elasticsearch/elasticsearch.yml

...
path.data: /media/different_media
...

Once you make all the changes, please save and exit the file. Now you can start Elasticsearch for the first time with the command:

sudo service elasticsearch start

Please allow at least 10 seconds for Elasticsearch to fully start before you are able to use it. Otherwise, you may get errors about not being able to connect.

Step 4 — Securing Elastic

Elasticsearch has no built-in security and can be controlled by anyone who can access the HTTP API. This section is not a comprehensive guide to securing Elasticsearch. Take whatever measures are necessary to prevent unauthorized access to it and the server/virtual machine on which it is running. Consider using iptables to further secure your system.

The first security tweak is to prevent public access. To remove public access edit the file elasticsearch.yml:

sudo nano /etc/elasticsearch/elasticsearch.yml
Find the line that contains the network.bind_host, uncomment it by removing the # character at the beginning of the line, and changing the value to localhost so it looks like this:

/etc/elasticsearch/elasticsearch.yml

...
network.bind_host: localhost
...

Warning: Because Elasticsearch doesn’t have any built-in security, it is very important that you do not set this to any IP address that is accessible to any servers that you do not control or trust. Do not bind Elasticsearch to a public or shared private network IP address!

Also, for additional security, you can disable dynamic scripts which are used to evaluate custom expressions. By crafting a custom malicious expression, an attacker might be able to compromise your environment.

To disable custom expressions, add the following line is at the end of the /etc/elasticsearch/elasticsearch.yml file:

/etc/elasticsearch/elasticsearch.yml

...
script.disable_dynamic: true
...

For the above changes to take effect, you will have to restart Elasticsearch with the command:

sudo service elasticsearch restart

Step 5 — Testing

By now, Elasticsearch should be running on port 9200. You can test it with curl, the command line client-side URL transfers tool, and a simple GET request like this:

curl -X GET 'http://localhost:9200'

You should see the following response:

Output of curl
{
  "status" : 200,
  "name" : "CentOS Node",
  "cluster_name" : "mysqluster",
  "version" : {
    "number" : "1.7.3",
    "build_hash" : "05d4530971ef0ea46d0f4fa6ee64dbc8df659682",
    "build_timestamp" : "2015-10-15T09:14:17Z",
    "build_snapshot" : false,
    "lucene_version" : "4.10.4"
  },
  "tagline" : "You Know, for Search"
}

If you see a response similar to the one above, Elasticsearch is working properly. If not, make sure that you have followed correctly the installation instructions and you have allowed some time for Elasticsearch to fully start.

Step 6 — Using Elasticsearch

To start using Elasticsearch, let’s add some data first. As already mentioned, Elasticsearch uses a RESTful API, which responds to the usual CRUD commands: Create, Read, Update, and Delete. For working with it, we’ll use again curl.

You can add your first entry with the command:

curl -X POST 'http://localhost:9200/tutorial/helloworld/1' -d '{ "message": "Hello World!" }'

You should see the following response:

Output
{"_index":"tutorial","_type":"helloworld","_id":"1","_version":1,"created":true}

With curl, we have sent an HTTP POST request to the Elasticseach server. The URI of the request was /tutorial/helloworld/1. It’s important to understand the parameters here:

the tutorial is the index of the data in Elasticsearch.

helloworld is the type.

1 is the id of our entry under the above index and type.

You can retrieve this first entry with an HTTP GET request like this:

curl -X GET 'http://localhost:9200/tutorial/helloworld/1'

The result should look like:

Output
{"_index":"tutorial","_type":"helloworld","_id":"1","_version":1,"found":true,"_source":{ "message": "Hello World!" }}

To modify an existing entry you can use an HTTP PUT request like this:

curl -X PUT 'localhost:9200/tutorial/helloworld/1?pretty' -d '
{
  "message": "Hello People!"
}'

Elasticsearch should acknowledge successful modification like this:

Output
{
  "_index" : "tutorial",
  "_type" : "helloworld",
  "_id" : "1",
  "_version" : 2,
  "created" : false
}

In the above example, we have modified the message of the first entry to “Hello People!”. With that, the version number has been automatically increased to 2.

You may have noticed the extra argument pretty in the above request. It enables a human-readable format so that you can write each data field on a new row. You can also “prettify” your results when retrieving data and get much nicer output like this:

curl -X GET 'http://localhost:9200/tutorial/helloworld/1?pretty'

Now the response will be in a much better format:

Output
{
  "_index" : "tutorial",
  "_type" : "helloworld",
  "_id" : "1",
  "_version" : 2,
  "found" : true,
  "_source":{ "message": "Hello World!" }
}

Setup web server to host ElasticSearch Application

These options depend on the webservers you have currently installed

For example, if you have installed nginx/varnish/apache you can use:
i. nginx -> custom port - This will proxy directly to ElasticSearch Application(RECOMMENDED)
ii. nginx/varnish/apache -> custom port - This will proxy to varnish cache and then to apache and then to ElasticSearch Application

So far we have added to and queried data in Elasticsearch. To learn about the other operations please check the API documentation.

Conclusion

That’s how easy it is to install, configure, and begin using Elasticsearch. Once you have played enough with manual queries, your next task will be to start using it from your applications.

Please read more detailed info here.

Create configuration file: /root/dns_sync_slave2.conf

USERNAME="slave"
SERVER="121.122.123.124"
SSHPORT="22"
SOURCESYNCLOCATION="/var/named/slave"
CHECKMAINDNS="centos-webpanel.com"
LOCALSYNCLOCATION="/var/named/slave"
LOCALCONFFILE="/etc/named/slave_additional.conf"

* SERVER = IP of Slave DNS Server & Manager.
* SSHPORT = SSH-Port of Slave DNS Server & Manager.
* SOURCESYNCLOCATION = Location of DNS zone files on Slave DNS Server & Manager.
* CHECKMAINDNS = This is a domain used for testing Slave DNS Server & Manager, it can be any and it doesn't need to be on the server.
* LOCALSYNCLOCATION = Location for DNS zone files on this local server.
* LOCALCONFFILE = Configuration files which contains the list of all zone files on this local server.

Setup cron how often you want to check for changes

crontab -e

* On servers with many clients and domains 100+ we recommend 5min cron.
* For servers with 1000+ you can go even with every 1-2 minutes.
example every 1 minute

* * * * * sh /scripts/dns_sync_slave2

In file /etc/named.conf after last include add:

include "/etc/named/slave_additional.conf";

Prepare config files

touch /etc/named/slave_additional.conf
chown named.named /etc/named/slave_additional.conf

go in cwp.admin -> Server Settings -> SSH Key Generator
there you need to generate new Keys

Go to Slave DNS Server & Manager
add key to the Slave DNS Server & Manager user you are using as "slave"

mkdir /home/slave/.ssh
nano /home/slave/.ssh/authorized_keys

** paste your key here which you had generated on the Slave2 DNS Server

chown -R slave.slave /home/slave/.ssh
chmod 600 /home/slave/.ssh/authorized_keys
chmod 700 /home/slave/.ssh/

You will also need to enable bash shell for that user so rsync could work

chsh -s /bin/bash slave

You can now test ssh connection like this from Slave2 DNS Server to Slave DNS Server & Manager
ssh slave@SERVER-IP -p SSH-PORT
If your connection goes ok without asking for the password then you are fully set.

Latest Update: March 7, 2021

For Slave DNS Manager is recommended that you have a clean server with CWP which will be used as Slave DNS (ns2).

Create a New Account on the CWPpro Server
* This is the server you plan to use as Slave DNS Server & Manager
username: recommended is slave (as it will be used in the tutorial)
domain: domain which you plan to use for slave dns manager gui and API access

Download Slave DNS Manage and upload it to public_html folder on your cwp account
Latest update: July 20, 2019. (manual update required by overwriting files)

cd /home/USERNAME/public_html
wget http://dl1.centos-webpanel.com/files/cwp/addons/cwp-slave_dns.zip
unzip cwp-slave_dns.zip
mv slave_dns/* .
rm -f index.html

Fix file permissions (you can do that also from cwp)

chown -R USERNAME.USERNAME /home/USERNAME/public_html/*

MySQL: Create User and Database
Go to CWP module: MySQL Manager --> Create Database and User

Edit file /home/USERNAME/public_html/inc/db_conn.php.sample and enter your database connection details
Rename sample file to get DB connection into production

mv inc/db_conn.php.sample inc/db_conn.php

Import database by using PhpMyAdmin or with MySQL command

mysql DATABASENAME < sql/slave_dns.sql

Create permissions for the user to be able to control the bind DNS.
Replace USERNAME with the user of the account you had created in cwp

FILENAME: /etc/sudoers.d/USERNAME

%USERNAME  ALL= NOPASSWD: /bin/systemctl start named
%USERNAME  ALL= NOPASSWD: /bin/systemctl stop named
%USERNAME  ALL= NOPASSWD: /bin/systemctl restart named
%USERNAME  ALL= NOPASSWD: /bin/systemctl reload named
%USERNAME  ALL= NOPASSWD: /bin/systemctl status named
%USERNAME  ALL= NOPASSWD: /bin/systemctl is-active named

touch /etc/named/slave.conf
chmod 771 /etc/named
usermod -a -G named USERNAME
chown USERNAME.named /etc/named/slave.conf

mkdir /var/named/slave
chown named.named /var/named/slave

Edit File: /etc/named.conf and add this in options section before closing }

masterfile-format text;

Add after options{} where other include lines are specifed

//Slave dns configuration
include "/etc/named/slave.conf";

Now you can login to DNS Manager GUI by using a domain link of the account you have created

Default login for DNS Manager GUI admin/root
Username: root
Password: FX8QKxvQ
* Please change the default password after the first login

Adding WebServers to DNS
- On dns manager GUI create a new user for each server or use a single for all webservers if you plan to transfer accounts from one to another webserver.
- On CWP WebServer go to DNS Functions -> Slave DNS Manager

For Slave Host you need to use the same URL you are accessing DNS Manager GUI, example

http://slave-dns.manager.domain.com

* You can also add this as an addon domain to the account later.

CWPpro WebServer configuration

Edit File: /etc/named.conf and add this in options section before closing }

//Slave dns configuration
allow-transfer {111.112.113.114;};
allow-recursion {111.112.113.114;};
also-notify {111.112.113.114;};
masterfile-format text;

Mostly know issues
issue: domain/zone not deleted from /etc/named/slave.conf
apache logs file: /usr/local/apache/domlogs/DOMAIN.error.log
apache logs line: sed: couldn't open temporary file /etc/named/sedzizIXw: Permission denied
solution: chmod 771 /etc/named

issue: Slave BIND/DNS not showing changes
solution: try to restart named and check if the service has some errors in the /var/log/messages

Please note that we have two options of slave DNS:
- Slave DNS Server on our hosted server (you get an account with domain limit you need)
- Slave DNS Server download version (a full and FREE Slave DNS Manager where you can add/remove users, set domain limits and manage domains)
* The only requirement is to have a CWPpro license.

Slave DNS Server & Manager on our hosted server
For those having only a single VPS or dedicated server and with a need additional remote DNS server as ns2 they can order a slave DNS from our website.

Features of CWP Slave DNS server hosted by us:
- Automatic sync DNS zones from a master server (your CWPpro) on serial change.
- Automatic sync DNS zones on add/remove.
- Manage DNS zones/domains from your CWP or our Website GUI.
- You get an account on our Slave DNS Manager where you have a limited number of domains based on the package you order.
- You don't need to buy an additional server and manually setup DNS on it.

You can order it here.

Slave DNS Server & Manager download version
A Full and FREE Slave DNS Server & Manager where you can add/remove users, set domain limits and manage domains.
The most important part is that this is a completely FREE and scalable for bigger hosting providers with many domains.

Features of CWP Slave DNS Server & Manager download version:
- Completely FREE, The only requirement is to have CWPpro to be able to sync zones.
- Automatic sync DNS zones from a master server (your CWPpro) on serial change.
- Automatic sync DNS zones on add/remove.
- Unlimited number of accounts.
- Option to limit the number of domains per account (if you sell/offer DNS cluster to other clients).
- Ability to connect multiple Slave2 DNS Servers (used as DNS Cluster).
- Ability to connect multiple CWPpro WebServers on a single account.
- Ability to connect multiple CWPpro WebServers on separate accounts.

You can check the installation instructions here.

Possible scenarios:
You can connect multiple CWPpro WebServers to single Slave DNS Manager and make it as ns2 for all of the CWPpro Webservers.
You can also use it as ns1 and then add multiple additional Slave2 DNS Servers as ns2, ns3, ns4....

Slave DNS Server & Manager - How it works:
In CWPpro WebServer on dns zone serial change, new account/domain/subdomain add/remove/edit it syncs DNS zone to the Slave DNS Manager.
DNS Zone is added to Slave DNS Manager from CWPpro WebServer via API on the Slave DNS Manager then Bind dns server (on the slave) transfers zone to itself acting as a slave dns server.

Slave2 DNS Server - How it works:
Big providers mostly have a custom DNS Cluster which handles all dns domains they have on multiple webservers to reduce resource usage by dns on the webservers.
Slave2 DNS Server is designed to be an additional DNS Server for big providers which need to have stability if some DNS servers get overloaded or unavailable.

It's using rsync running via cron which checks for changes on the Slave DNS Manager and based on the changes from rsync it will add or remove dns zone from itself.
It also has the ability to check if Slave DNS Manage is responding on dns queries before accepting new changes to prevent multiple DNS servers to be down at the same time.

Slave DNS Servers can be located in different data centers worldwide.

You can check the installation instructions for Slave2 DNS Servere here.

INFO
* Only WebServers need to have CWPpro, DNS servers don't need to have it.

Available Scripts with the latest version

/scripts/upgrade_mysql

>> Upgrade phpMyAdmin and MySQL to 5.5

/scripts/install_imagick

>> Installs Image Magick

/scripts/install_maldet

>> Installs Maldet

/scripts/install_net2ftp

>> Installs Net2FTP, Usage http:>> IP/net2ftp

/scripts/user_backup

>> Create User backup, Usage: sh /scripts/user_backup USERNAME

/scripts/whoowns

>> Get Domain owner, Usage: sh /scripts/whoowns DOMAIN

/scripts/list_users

>> List all user accounts

/scripts/list_domains

>> List all addon domains

/scripts/list_subdomains

>> List all Sub-Domains

/scripts/cwp_bruteforce_protection

>> Enable CSF/LFD Brute/Force protection

/scripts/mysql_pwd_reset

>> Reset root MySQL password

/scripts/restart_cwpsrv

>> Restart CWP (restarts panel only)

/scripts/cwp_version

>> Check CWP version

/scripts/add_alert

>> Additional alert addition

/scripts/apache_mpm_calculator

>> To generate Apache MPM configuration

/scripts/autossl_fix_tmp_path

>> AutoSSL temp/tmp path correction

/scripts/autossl_generate_apache_conf

>> AutoSSL generation

/scripts/autossl_reload

>> AutoSSL reload

/scripts/bandwidth_run

>> Bandwidth check

/scripts/cgroups_blkio

>> Gets disk id for cgroups

/scripts/check_api

>> API detailed check

/scripts/checkdb

>> Database error check

/scripts/check_postqueue

>> MailQueue check

/scripts/chroot_add

>> To add JailKit

/scripts/chroot_remove

>> To remove JailKit

/scripts/clamd_fix_100_cpu_usage

>> Clamd 100% CPU usage fix

/scripts/cpanel_addhandlers

>> Add cPanel AddHandler into cwp suphp

/scripts/cron_fix_openbasedir

>> Openbase Dir Cron Fix

/scripts/cwp_bruteforce_protection

>> Apply BruteForce Protection to CWP

/scripts/cwp_monitor

>> Server load parameter check

/scripts/cwpsecure_update_rules

>> Secure Kernel rules update

/scripts/cwp_set_memory_limit

>> Memory limit variable change

/scripts/cwpsrv_rebuild_user_conf

>> Rebuild User Configuration files for all users

/scripts/disk_check

>> Disk Partition Usage check

/scripts/dns_sync_slave2

>> DNS Zones sync command

/scripts/dso_handler_remove

>> PHP DSO Handler remover

/scripts/el8_stream_convert_to_cwp_stable

>> CentOS 8 Stream to CentOS 8 Stable conversion (enable cwp delayed update repo)

/scripts/freshclam

>> ClamAV update

/scripts/generate_hostname_ssl

>> Server Hostname SSL Generation

/scripts/hostname_ssl_restart_services

>> Hostname Service Restart

/scripts/image_rebuild_server_config

>> Server Configuration rebuild to default

/scripts/install_acme

>> Install Let's Encrypt SSL Installer

/scripts/install_api

>> CWP API Generation/Installation

/scripts/install_cbpolicyd

>> Install Hourly Email sending limit

/scripts/install_imagick

>> Install PHP Imagick

/scripts/install_pure-ftpd_tls

>> Install TLS Services on FTP Server

/scripts/install_supportKey

>> Install Support Key to grant access of server to support team

/scripts/install_terminal

>> CWP INSTALL APP TERMINAL

/scripts/list_domains

>> List Hosted Domains

/scripts/list_subdomains

>> List hosted sub-domains

/scripts/list_users

>> List usernames on server

/scripts/mail_queue_stats

>> MailQueue statistics

/scripts/mail_roundcube_update

>> RoundCube version update

/scripts/mail_vmail_import

>> Script to import all email accounts from /var/vmail folder

/scripts/mail_rebuild_sni_certs

>> Script to rebuild mail postfix and dovecot certificates for all domains

/scripts/mysql_fix_myisam_tables

>> Repair MySQL MyISAM Tables

/scripts/mysql_phpmyadmin_update

>> PHPMyAdmin update

/scripts/mysql_set_max_connections

>> MySQL Max_Connection parameter settings

/scripts/mysql_show_max_connections

>> Shows Current Max_Connection parameter settings

/scripts/net_show_connections

>> CWP show connection number and sort them by size

/scripts/open_basedir-suphp

>> this script will activate and force open_basedir for all users

/scripts/php_big_file_upload

>> To set file upload limit

/scripts/phpfpm_rebuild_user_conf

>> Rebuild PHP-FPM user configuration file

/scripts/reinstall_clamd_amavisd

>> Reinstall Clamd and Amavis

/scripts/reinstall_pure-ftpd

>> Reinstall Pure-FTP

/scripts/reload_cwpsrv

>> Deamon Reload

/scripts/restart_cwpsrv

>> CWP Service restarts

/scripts/restart_httpd

>> Service Apache restarts

/scripts/security_is_my_server_hacked

>> Check for mostly know hacked servers

/scripts/softaculous_fix_update

>> If softaculous is not working

/scripts/ulimit_user_check

>> Limit check for specific user

/scripts/update_cwp

>> CWP Server Update to next version

/scripts/update_ioncube

>> IonCube installer (this script will update ioncube to latest possible version)

/scripts/user_backup

>> Backup a specific user

/scripts/varnish_clear_cache

>> Clear Varnish Cache

Usage
sh /scripts/SCRIPT-NAME
/scripts/SCRIPT-NAME

You can check for scripts in the /scripts/ folder.
...many others coming soon.