When going to Fantastico De Luxe link in you cPanel under Paper Lantern theme, or some other theme you might get HTTP error 404 cPanel page shown, saying that requested page was not found.
Fantastico 404 page
Check your theme folder content for fantastico symlink
404 page will most likely be caused by the affected theme not having, a fantastico symlink, or symlink being misdirected.
Go to the folder of the theme, which in case of Paper Lantern theme will be /usr/local/cpanel/base/frontend/paper_lantern and check for file with name fantastico.
root@server [/usr/local/cpanel/base/frontend/paper_lantern]# ls -l | grep fantastico
root@server [/usr/local/cpanel/base/frontend/paper_lantern]#
Folder should have symlink in it, with name fantastico, pointing to /usr/local/cpanel/3rdparty/fantastico/, if the symlink is missing create one with ln -s command, also check if the file to which symlink is pointing is an existing file.
If you make an SMTP test on http://mxtoolbox.com you might be getting a following error shown in the test results “Reverse DNS does not match SMTP Banner”.
This error is showing because your SMTP greeting message is not matching the PTR records for the IP of the SMTP server used in test.
Following files need to be used and configured properly, for SMTP banner to match reverse DNS records.
Go to WHM to Home »Service Configuration »Exim Configuration Manager and in Basic Editor on Domains and IPs tab set following settings:
Send mail from account’s dedicated IP address: OFF Reference /etc/mailhelo for outgoing SMTP HELO: ON Reference /etc/mailips for outgoing SMTP connections: ON
Configure necessary values in configuration files
Edit or create /etc/mail_reverse_dnsfile and set the following in it for needed IPs.
x.x.x.x: rdns of the IP x.x.x.x
y.y.y.y: rdns of IP y.y.y.y
Edit or create /etc/mailhelo file and set following in it for the domains that you want to setup SMTP banner for.
example.com: reverse dns of the IP used for example.com domain
*: default SMTP HELO for unconfigured domains
Edit or create /etc/mailips file and set following in it:
example.com: x.x.x.x #x.x.x.x is the IP used for outgoing mail for domain example.com
*: y.y.y.y #y.y.y.y is the default IP that will be used for unconfigured domains
Configure exim.conf to use correct SMTP Banner
Following values need to be configured in exim.conf for SMTP Banner to be set to rDNS values set in /etc/mail_reverse_dns.
smtp_banner will probably look like this on your cPanel server.
"${primary_hostname} ESMTP Exim ${version_number} \#${compile_number} ${tod_full} \n We do not authorize the use of this system to transport unsolicited, \n and/or bulk e-mail."
Configure values in exim.conf over shell
Locate the line smtp_banner and change its value so it looks like following:
At this moment cPanel does not support ionCube Loader 5 on WHM/cPanel servers, which will cause issues for client running files made with ionCube v9.
cPanel currently installs ionCube PHP Loader v4.7.5, when you install PHP using cPanel EasyApache utility.
Your standard php -v output on cPanel server might look something like this.
root@server [~]# php -v
PHP 5.4.45 (cli) (built: Dec 14 2015 17:18:43)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
with the ionCube PHP Loader v4.7.5, Copyright (c) 2002-2014, by ionCube Ltd.
If you want to install, or upgrade current ionCube PHP Loader on your server to version 5, you can do so manually by downloading the latest version from http://www.ioncube.com/loaders.php, and editing your global or account custom php.ini file.
How to install ionCube Loader manually on cPanel or standard Linux servers with no control panel.
Download the latest loader to your server from http://www.ioncube.com/loaders.php.
If you are running 32 bit server used the following command:
It will create ioncube folder in the same directory where you downloaded the file.
If you need to install ionCube Loader for PHP 5.4 you will use ioncube_loader_lin_5.4* files, and if you need to install it for PHP 5.5 you will use ioncube_loader_lin_5.5* files, and similar for other PHP versions.
To replace the ionCube Loader for all the users on the server, you can just replace the extension file defined in the global php.ini at /usr/local/lib/php.ini
You can rename the original file, for restore purposes, if something goes wrong, and place the new version file from ioncube folder that was created with package extraction.
You can confirm the new version of ionCube Loader with php -v, and look for “ionCube PHP Loader” part of the output.
root@server [~]# php -v
PHP 5.4.45 (cli) (built: Dec 14 2015 17:18:43)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v5.0.19, Copyright (c) 2002-2015, by ionCube Ltd.
root@server [~]# php -v | grep "ionCube PHP Loader"
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v5.0.19, Copyright (c) 2002-2015, by ionCube Ltd.
root@server [~]#
Upgrade to ionCube Loader 5 on one cPanel account.
If you wanted to change the ion Cube Loader version for only one cPanel account, you can place the ioncube_loader_lin* files for the PHP version used by your client to some custom folder, and define zend_extension values inside a custom php.ini folder on a specific cPanel account.
tl;dr
ionCube Loader can be installed manually on any Linux server with following steps:
Download latest version of ionCube Loaders from http://www.ioncube.com/loaders.php
Unpack the downloaded package
move the ioncube_loader_lin_* files for your PHP version to your extension folder.
Point to the corresponding file in your php.ini file, example zend_extension="/usr/local/IonCube/ioncube_loader_lin_5.4.so"
After the WHM/cPanel update to 11.38 you might get the an error like this in your browser:
Internal Server Error 500 No response from subprocess (/usr/local/cpanel/whostmgr/docroot/cgi/addon_csf.cgi): subprocess exited with status 2
And something like this in /usr/local/cpanel/logs/error_log:
BEGIN failed–compilation aborted at /usr/local/cpanel/Cpanel/JSON.pm line 15. Compilation failed in require at /usr/local/cpanel/Cpanel/Template/Plugin/JSON.pm line 12. BEGIN failed–compilation aborted at /usr/local/cpanel/Cpanel/Template/Plugin/JSON.pm line 12. Compilation failed in require at /usr/local/cpanel/Cpanel/Template.pm line 53. BEGIN failed–compilation aborted at /usr/local/cpanel/Cpanel/Template.pm line 53. Compilation failed in require at /usr/local/cpanel/Whostmgr/HTMLInterface.pm line 12. BEGIN failed–compilation aborted at /usr/local/cpanel/Whostmgr/HTMLInterface.pm line 12. Compilation failed in require at /usr/local/cpanel/whostmgr/docroot/cgi/addon_cmc.cgi line 25. BEGIN failed–compilation aborted at /usr/local/cpanel/whostmgr/docroot/cgi/addon_cmc.cgi line 25. For help, please send mail to this site’s webmaster, giving this error message and the time and date of the error.
when going to ConfigServer cPanel plugins in WHM like:
ConfigServer Explorer
ConfigServer Mail Manage
ConfigServer Mail Queues
ConfigServer ModSecurity Control
ConfigServer Security & Firewall
This happens if the installed ConfigServer scripts on a cPanel/WHM server don’t get updated.
The solution for this error is simple.
To resolve this error simply SSH into your server as a root user and run the following command from command line:
curl -s configserver.com/free/csupdate | perl
This script will update: cmm, cmc, cmq, cse, csf, cxs, msinstall, msfe
You can see the ConfigServer blog post about the update here.
WHM/cPanel all packages get reapplied, and Upgrade/Downgrade notification is sent for all accounts.
lvemanager-1.0-9.9 has been released in production by CloudLinux yesterday, and it has caused issues on WHM/cPanel servers, by reapplying packages to all accounts.
All accounts that had their quotas and limits modified, without modifying the related packages, have been reassigned to values that are specified in the package, they are assigned to. This will cause quota or bandwidth being exceeded on a lot of accounts on the server, if you haven’t been modifying them properly.
If you have received a following type of mail for all accounts on your server, that account Upgrade/Downgrade was made, then it is due to lvemanager update to lvemanager-1.0-9.9.
Upgrade/Downgrade: %account" from <root@%hostname> for [email protected]
If you check your yum update logs, you will see lvemanager-1.0-9.9 has been installed on the server overnight, which is the cause of the issues with the packages being reapplied.
# grep lve /var/log/yum.log | tail -2
Dec 17 05:09:12 Updated: lve-utils-1.5-2.3.el6.cloudlinux.i686
Dec 17 05:09:27 Updated: lvemanager-1.0-9.9.el6.cloudlinux.noarch
#
According to the comments on CloudLinux blog
“You can find their last allocated settings from your last backup –
less /cpb/incremental/accounts/domainname/cp/domainname”
CloudLinux has in the meantime issued a statement regarding LVE Manager 1.0-9.9 issues, with some details on how to revert the values to one prior the upgrade.
If you have cPanel backups enabled, you can get previous limits from backups. Here is an example how to do it:
cd /backup/cpbackup/daily
tar -zxvf username.tar.gz username/cp
tar -zxvf username.tar.gz username/quota
cat username/quota
cat username/cp/username | egrep "MAX|BWLIMIT"
Then set limits manually with WHM –> Modify account.
UPDATED: Dec 18, 07:16 AM UTC
Here are some commands that should help you returning quotas back, if you have cpanel backups enabled.
Get list of users over quota:
cd /backup/cpbackup/daily/
repquota -a | grep "+" | awk '{ print $1 }' > users_overquota
Extract only quota files for them:
for i in `cat users_overquota` ; do echo "tar -zxvf "$i".tar.gz "$i"/quota" ; done | sh
Echo username and quota limit, the output value means Mb:
for i in `cat users_overquota` ; do echo "echo -e '\n'; echo "$i"; cat "$i"/quota " ; done | sh
Now use cpanel’s script to set quotas, based on above output add ‘M’ key for it. Copy-paste username and %value% and run command for each:
/scripts/editquota username %value%M
Another update:
CloudLinux has made another updated about the issue, and have provided a script that could be used to restore those limits if cPanel backups were enabled.
Due to number of servers affected with custom package limits reset to package defaults we prepared a script that could be used to restore those limits if cPanel backups were enabled. It restores all limits if:
package was not changed since backup time;
limits are the same as package limits;
all package limits in backup are the same as current package limits.
Required files: %backup_location%/files/_etc_quota.conf.gz and %backup_location%/dirs/_var_cpanel.tar.gz . Please, restore them from a day/week before LVE Manager update (before December 16). Better to place them in the same /root/ directory.
Download the following script and make it executable:
./autorestore.py /root/_var_cpanel.tar.gz /root/_etc_quota.conf.gz
The script will back up current user limits to /var/cpanel/users.%timestamp% before changing limits.
