Let’s Encrypt Plugin in cPanel

To use Let’s Encrypt in cPanel, you need to install a special plugin.
To do this, connect to the server by SSH and execute the command from the root user:

/scripts/install_lets_encrypt_autossl_provider

After installing the Let’s Encrypt plug-in, you can use it in the AutoSSL management menu (WHM >> Home >> SSL/TLS >> Manage AutoSSL).

If you need to remove the plugin, then run the command:

/usr/local/cpanel/scripts/uninstall_lets_encrypt_autossl_provider

See also:
Установка Certbot в Ubuntu

The solution to the warning “mismatch_cnt is not 0 on /dev/md*”

Replaced once the junk drive in the software RAID1, added it to the raid, it successfully synchronized, installed GRUB.
After a while I received an email message:

Subject: Cron <root@server> /usr/sbin/raid-check
WARNING: mismatch_cnt is not 0 on /dev/md2

In my case, raid-check found that the mismatch_cnt counter is not equal to 0 for /dev/md2, which means that there may be broken sectors on the disk, or it simply needs to be resynchronized. Since I installed GRUB after adding the disk to the raid, this is probably the cause.

Example of viewing the counters of all arrays:

cat /sys/block/md*/md/mismatch_cnt

Or each in turn:

cat /sys/block/md0/md/mismatch_cnt
cat /sys/block/md1/md/mismatch_cnt
cat /sys/block/md2/md/mismatch_cnt

View the status of raids:

cat /sys/block/md*/md/sync_action

If mismatch_cnt is not 0 for any array, then you can try to resynchronize it:

echo 'repair' >/sys/block/md2/md/sync_action

And check:

echo 'check' >/sys/block/md2/md/sync_action

If you want to cancel the action:

echo 'idle' >/sys/block/md2/md/sync_action

Let’s see the synchronization status and other data of the array:

cat /proc/mdstat

If errors appear due to a bad disk, I recommend that you look at SMART and check it as I wrote in these articles:
Diagnostics HDD using smartmontools
Linux disk test for errors and broken sectors

See also:
How to fix the problem with mdadm disks

Migration from EasyApache 3 to EasyApache 4

On the test I migrated from EasyApache 3 to EasyApache 4.

Before starting the process, you must always make a backup copy of the server.

Opened the “WHM” – “Home” – “Software” panel – “EasyApache 4” and clicked the “Migrate” button.

The migration process lasted about 5 minutes.
Since the old EasyApache 3 used Apache2.2, and it is not supported on EasyApache 4, it was automatically updated to Apache2.4.
The configuration and version of PHP remained the same as 5.5, but since it was outdated, after migration, I opened the same menu (WHM – Home – Software – EasyApache 4), chose the version of PHP 5.6, the necessary PHP modules had to be selected, because for each versions of PHP they are selected individually.
The PHP version 7 decided not to choose to fix the code of sites less.

After the PHP update, you need to configure the php.ini file, it is located at /opt/cpanel/ea-php56/root/etc/php.ini, and on EasyApache 3 was /usr/local/lib/php.ini.

The Apache2 error log file is here by default /etc/apache2/logs/error_log and here /usr/local/apache/logs/error_log.

The error file PHP file, for some reason in php.ini by default was specified without a path:

error_log = error_log

Because of this, it was created in all the directories of the web server where errors occurred, so I indicated the full path.

This completes the migration, further actions depend on the errors that will be displayed in this file, if necessary, you will probably need to install missing PHP modules or fix the outdated site code.

See also:
Troubleshooting PHP Warning “Permission denied /var/cpanel/php/sessions/ea-php56/”

Troubleshooting PHP Warning “Permission denied /var/cpanel/php/sessions/ea-php56/”

Once I updated EasyApache 3 to EasyApache 4 in cPanel and noticed in the PHP logs the following:

[29-Mar-2018 15:54:45 UTC] PHP Warning:  Unknown: open(/var/cpanel/php/sessions/ea-php56/sess_3d96o7nnlnnr473p8619vqkdm1, O_RDWR) failed: Permission denied (13) in Unknown on line 0
[29-Mar-2018 15:54:45 UTC] PHP Warning:  Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/cpanel/php/sessions/ea-php56) in Unknown on line 0

The warning occurs because PHP can not write session files to a directory to which it does not have access rights.
I looked at the rights of this directory, the group and owner was root, and it was also allowed to write and execute for everyone, except reading.

To resolve this warning, you can open full access for everyone:

chmod 777 /var/cpanel/php/sessions/ea-php56

Or open a PHP configuration, for example in the nano editor:

nano /opt/cpanel/ea-php56/root/etc/php.ini

To find:

session.save_path = "/var/cpanel/php/sessions/ea-php56"

And change to:

session.save_path = "/tmp"

That used to be on the old EasyApache3 in the PHP configuration /usr/local/lib/php.ini.

After that, the warning did not appear.

See also:
Migration from EasyApache 3 to EasyApache 4

The warning solution “The MaxMind Geolite databases will soon be deprecated” in Cpanel

Once launched a server security check by clicking “Check Server Security” in “Main” – “Plugins” – “ConfigServer Security & Firewall” and saw a warning:

Firewall Check
CC_OLDGEOLITE option check
The MaxMind Geolite databases will soon be deprecated, disable CC_OLDGEOLITE to start using the new Geolite2 databases

This option determines which database to use, the old MaxMind Geolite or the new MaxMind Geolite2.
If the option “CC_OLDGEOLITE” is 1, which is in my case, then the old one is used, and if 0, then the new one.

To enable the use of a new one, open the CSF configuration for example in the text editor nano:

nano /etc/csf/csf.conf

Find the option CC_OLDGEOLITE and change its value from 1 to 0:

CC_OLDGEOLITE = "0"

In the nano editor, the Ctrl+X keys are used to exit, and y/n and Enter to save or discard the changes.

After the changes, restart CSF by clicking “Firewall Restart” in the menu “Main” – “Plugins” – “ConfigServer Security & Firewall”.

Configuring Cron Jobs in cPanel and WHM

Cron jobs are added separately for each user through the cPanel and WHM web interface, namely cPanel “Advanced” -> “Cron Jobs“.
Through the WHM panel “Home” -> “Server Configuration” -> “Configure cPanel Cron Jobs“.

But there are also system tasks that can not be seen through the panel.
They can be seen by connecting through SSH to the server and running the command from the root user:

crontab -e

or from another user via sudo:

sudo crontab -e

In the nano editor, the shortcut Ctrl+X is used to exit, and y/n to save or discard the changes.
The file itself with the tasks is located on the path /var/spool/cron/root

If an annoying report is sent to an e-mail when executing an assignment, you can hide the output of the task by adding the following code to the end of the command:

>/dev/null 2>&1

To restart the Cron service, use the command:

service crond restart

See also a similar article: Using and configuring CRON

How to start ClamAV scanning from the command line on the cPanel server

Here is an example of checking the public_html directory with the removal of infected files:

/usr/local/cpanel/3rdparty/bin/clamscan -ri --remove /home/user/public_html

Similarly, other directories are checked.

To start checking only the mail and public_html directory for all users:

/usr/local/cpanel/3rdparty/bin/clamscan -ri /home/*/mail
/usr/local/cpanel/3rdparty/bin/clamscan -ri /home/*/public_html

To update the anti-virus database, use the command:

/usr/local/cpanel/3rdparty/bin/freshclam

See also my article:
Installing and using ClamAV antivirus software

How to restart services in cPanel

The services must be restarted through the WHM interface, by opening “Home” > “Restart Services”.

If the restart of the service through the WHM interface failed, then the script should be used:

/usr/local/cpanel/scripts/restartsrv_*

If you are using IPv6 and the command was executed:

service network restart

That IPv6 does not work to solve the problem:

/etc/init.d/cpipv6 restart (for cPanel & WHM version 11.52 and earlier)
/usr/local/cpanel/scripts/restartsrv_cpipv6 (for cPanel & WHM version 54 and later)

In extreme cases, you can try to restart the service directly:

/etc/rc.d/init.d/service restart
systemctl restart service-name.service

See also:
Location of log files cPanel