Archives for July 2008

Which Firewall Ports are needed to be open on a cPanel/WHM Server

July 23, 2008 By Christoph Puetz Leave a Comment

Which Firewall Ports are needed to be open on a cPanel/WHM Server

As a system admin today you have several choices to protect your system when it comes to picking a firewall. While all firewall products are probably a little different in functionality and setup, the one thing they have in common is that theyt provide you with the option open or close specific ports to protect your web server.

cPanel and WHM install and use a number of different services on your system. Many of these services require an outside connection to function properly. Therefore, specific ports in the firewall will need to be opened for these services to function properly. The following list is a starting point you can use to make your system secure. You should carefully review this list and make adjustments to meet your server needs accordingly.

Firewall Ports
20 FTP (Consider SFTP over SSH as is more secure than FTP)
21 FTP (Consider SFTP over SSH as is more secure than FTP)
22 SSH (Consider switching SSH to a different, non-standard port for security reasons)
25 SMTP (some ISPs block port 25 so that a mail client cannot reach the mail server to send mail)
26 SMTP (alternate SMTP port option – see notes for port 25)
37 rdate (needed to retrieve date and time information)
43 whois (part of generic DNS features)
53 bind (DNS)
80 http (Apache / Web)
110 POP3 (Email)
113 ident (authentication)
143 IMAP (Email)
443 https (Web / HTTP over SSL)
465 SMTP (TLS/SSL)
873 rsync (remote sync)
993 (IMAP SSL)
995 (POP3 SSL)
2083 cPanel (SSL encrypted)
2087 WHM (SSL encrypted)
2089 Licensing (Must be open to contact license server)
2096 Webmail (Horde, Squirrelmail)
3306 MySQL (MySQL remote connections)

This list should be a good starting point to secure your web server. Make sure to test carefully as otherwise server functionality might be at stake. Also make sure not to lock yourself out. I usually have a running SSH session + WHM at the same time, just to be safe.

How to repair all MySQL Databases on a cPanel/WHM Server

July 8, 2008 By Christoph Puetz 2 Comments

How to repair all MySQL Databases on a cPanel/WHM Server

There can be different reasons why one wants to repair a MySQL database. Database corruption maybe due to a lack of disk space or an unexpected server shutdown that caused the database to go bad. Queries that worked before suddenly stopped working and overall the database is not behaving anymore as expected. This guide shall not be a full database troubleshooting guide, but rather give you a hand on doing a MySQL repair on all databases on a cPanel/WHM server (or any other server running MySQL).

The situation: Your server crashed hard and when it is back up the MySQL side of the house is not working anymore. You do your normal troubleshooting. If all other troubleshooting and verifications are done, you come to the conclusion that you will need to run a repair as the next step. A full database restore from a (hopefully existing) good database backup would be your last choice.

Repairing one MySQL database is fairly easy, but how do you do this for an entire server holding20, 30, 50 or over 100 databases? You will need SSH access as the root user to the server running MySQL. So, log in as the root user and then do the following to repair your MySQL databases:

Option #1

Check if you any need DB repair:
myisamchk –check /var/lib/mysql/*/*.MYI

Then try a ‘safe-recover’ as the first step:
myisamchk –safe-recover /var/lib/mysql/*/*.MYI

If the ‘safe-recover’ does not work, run a full recover:
myisamchk –recover /var/lib/mysql/*/*.MYI

Then use the ‘force’ flag to get things back to normal:
myisamchk –safe-recover –extend-check –force /var/lib/mysql/*/*.MYI

or:
myisamchk –recover –extend-check –force /var/lib/mysql/*/*.MYI

Option #2

Use the mysqlcheck tool to repair your databases.

mysqlcheck –all-databases -r #repair
mysqlcheck –all-databases -a #analyze
mysqlcheck –all-databases -o #optimize

There you have it. By using one of these two options you should be able to repair and recover your databases. Please be advised that you should backup critical databases before running any of the commands above. If something goes wrong you can revert back and try again.