Troubleshooting a HTTP 500 internal server error

[admin]

A HTTP 500 internal server error means your web server is experiencing problems, but it can't pinpoint the specific error or its root causes. When this happens, your website will serve up a general internal server error web page to your site's visitors.
If your server using PHP extension such as: IonCubeLoader and or ZendGuardLoader... then the web page could be blank. no information could be read, Nothing.
A 500 internal server error is, as the name implies, a general problem with the website's server. More than likely, this means there's an issue or temporary glitch with the website's programming.

Some potential causes of a 500 internal server error include:

• Corrupted or broken .htaccess file

• A permissions error

• Faulty third-party plugins or themes

• The PHP memory limit being exceeded

To fix the problems related broken .htaccess file?
If you're not using Wordpress, just make sure to uninstall wordpress-plugin/wp-toolkit (That's using PHP-FPM) from your sites.
Also...
It's likely there are some glitch within EasyApache related to:
Php-Composer and PHP-FPM.

EasyApache is a tool built into your WHM/cPanel server in order to make update and configure your Apache server,
Disconnect your PHP-FPM and set it to Off and set back your server to PHP-CGI, to protect your index.php and .htaccess from being automatically overwritten by WHM/cPanel update.

To monitor System Integrity, I'm using CSF Firewall LFD module such like this:

This is for example:
/======================================================================/
lfd on --myserver--: System Integrity checking detected a modified system file
Jun 9, 2022, 7:30 AM (13 days ago)

to root
Time: Wed Jun 8 17:30:09 2022 -0700

The following list of files have FAILED the md5sum comparison test. This means that the file has been changed in some way. This could be a result of an OS update or application upgrade. If the change is unexpected it should be investigated:

/usr/bin/cpapi1: FAILED
/usr/bin/cpapi2: FAILED
/usr/bin/cpapi3: FAILED
/usr/bin/doveadm: FAILED
/usr/bin/doveconf: FAILED
/usr/bin/dovecot-sysreport: FAILED
/usr/bin/dsync: FAILED
/usr/bin/pdns_control: FAILED
/usr/bin/pdnsutil: FAILED
/usr/bin/uapi: FAILED
/usr/bin/zone2json: FAILED
/usr/bin/zone2sql: FAILED
/usr/sbin/dovecot: FAILED
/usr/sbin/exicyclog: FAILED
/usr/sbin/exigrep: FAILED
/usr/sbin/exim: FAILED
/usr/sbin/exim_checkaccess: FAILED
/usr/sbin/exim_dbmbuild: FAILED
/usr/sbin/exim_dumpdb: FAILED
/usr/sbin/exim_fixdb: FAILED
/usr/sbin/exim_lock: FAILED
/usr/sbin/eximstats: FAILED
/usr/sbin/exim_tidydb: FAILED
/usr/sbin/exinext: FAILED
/usr/sbin/exiqgrep: FAILED
/usr/sbin/exiqsumm: FAILED
/usr/sbin/exiwhat: FAILED
/usr/sbin/pdns_server: FAILED
/usr/sbin/runq: FAILED
/usr/sbin/whmapi0: FAILED
/usr/sbin/whmapi1: FAILED
/usr/sbin/whmlogin: FAILED
/bin/cpapi1: FAILED
/bin/cpapi2: FAILED
/bin/cpapi3: FAILED
/bin/doveadm: FAILED
/bin/doveconf: FAILED
/bin/dovecot-sysreport: FAILED
/bin/dsync: FAILED
/bin/pdns_control: FAILED
/bin/pdnsutil: FAILED
/bin/uapi: FAILED
/bin/zone2json: FAILED
/bin/zone2sql: FAILED
/sbin/dovecot: FAILED
/sbin/exicyclog: FAILED
/sbin/exigrep: FAILED
/sbin/exim: FAILED
/sbin/exim_checkaccess: FAILED
/sbin/exim_dbmbuild: FAILED
/sbin/exim_dumpdb: FAILED
/sbin/exim_fixdb: FAILED
/sbin/exim_lock: FAILED
/sbin/eximstats: FAILED
/sbin/exim_tidydb: FAILED
/sbin/exinext: FAILED
/sbin/exiqgrep: FAILED
/sbin/exiqsumm: FAILED
/sbin/exiwhat: FAILED
/sbin/pdns_server: FAILED
/sbin/runq: FAILED
/sbin/whmapi0: FAILED
/sbin/whmapi1: FAILED
/sbin/whmlogin: FAILED
/usr/local/bin/crontab: FAILED
/usr/local/bin/passwd: FAILED

/======================================================================/

A very useful Linux tip on how to make files and directories undeletable even by the root user.
You can apply this tip on all important configuration files so that no one accidentally or intentionally delete it. To achieve this,
the chattr (Change Attribute) command is used in Linux. The chattr command “immunizes” the file not only from deletion but also modification. The chattr command does care about chmod values, even if a file has 777 permissions, immunizing the file will prevent it from being deleted or modified.

This command will add the “immutable” flag to the file.
If you're using your own dedicated server to host all of your websites, check your .htaccess file record and delete any un-neccesary records and save it. After saved, You may use CLI command like these to immutable flag to the file :

Code: Select all

# change username with your real cPanel user
chattr +i /home/username/public_html/index.php 
chattr +i /home/username/public_html/.htaccess

or

Code: Select all

# change username with your real cPanel user
cd /home/username/public_html
find . -type f index.php .htaccess -exec chown username:username chattr +i \{\} \;

To revert back?
Use these CLI command:

Code: Select all

# change username with your real cPanel user
chattr -i /home/username/public_html/index.php 
chattr -i /home/username/public_html/.htaccess

When you install WordPress Manager via the Install cPAddons Site Software interface, it installs four different RPMs:

• cpanel-wordpress-instance-manager-plugin

• cpanel-wp-cli

• wordpress-cpaddon

• wordpress-cpaddon-phpXX (the XX varies depending on the PHP versions on your server)

When you attempt to uninstall the WordPress Manager via Install cPAddons Site Software, you must deselect the option then update cPAddons config. You are then able to see the process of removing the software,
but upon accessing cPanel once more,
still... you can find that WordPress Manager in the cPanel account?
then you can use this CLI command:

Code: Select all

mv -v /usr/local/cpanel/whostmgr/addonfeatures/wordpress_manager{,.bak}

Also... Uninstall the RPM packages with the following CLI command:

Code: Select all

yum remove cpanel-wordpress-instance-manager-plugin cpanel-wp-cli wordpress-cpaddon wordpress-cpaddon-phpXX