There’s been a long-standing issue from a hosting provider’s point of where cPanel runs on abnormal ports, causing users behind firewalls to be unable to access cPanel. At first, there was cpanelproxy.net which offered (at that time) an automated script that users could install on their hosting accounts to route cPanel traffic over port 80. Around the time that cPanel 11 came out, the script no longer worked, and users behind corporate or school firewalls were out of luck.

cPanel 11 introduced its own proxy to allow users to get around firewall restrictions.

To enable this feature without inconveniencing users, check these three options in WHM > Tweak Settings:

Add proxy VirtualHost to httpd.conf to automatically redirect unconfigured cpanel, webmail, webdisk and whm subdomains to the correct port (requires mod_rewrite and mod_proxy)

Automatically create cpanel, webmail, webdisk and whm proxy subdomain DNS entries for new accounts. When this is initially enabled it will add appropriate proxy subdomain DNS entries to all existing accounts. (Use /scripts/proxydomains to reconfigure the DNS entries manually)

Allow users to create cpanel, webmail, webdisk and whm subdomains that override automatically generated proxy subdomains

*Keep in mind that if you’re establishing these settings on an existing server, it’s going to update the zones for each domain on the server and synchronize them out to the DNS cluster. This got us in trouble once, as we had a number of suspended accounts on a server that ended up having their DNS reverted back when the proxy subdomains were updated.

To enable proxydomains for the whole server:

/scripts/proxydomains add

To enable for all domains on one user’s account:

/scripts/proxydomains –user=<user> add

To enable for a single domain:

/scripts/proxydomains –domain=<domain> add

To remove proxy domains, use the same commands as above, only use “remove” instead of “add”. From here, you can access the proxy at http://cpanel.domain.com (or webmail/whm, respectively), or access cPanel normally and let it detect whether you are behind a firewall.

Wildcard DNS allows a server to display and combination of subdomains for a website. For example, wildcard DNS for thecpaneladmin.com will allow any subdomain to resolve to this website, even if they have not been specifically created.  Subdomains that have been created individually in cPanel will still route to their respective folders, but anything else will go to the document root of the domain the subdomains are based on. Wildcard DNS is most used for implementation of applications like WordPress MU. To set up wildcard DNS:

In the DNS zone for the parent domain, simply create an A  or CNAME record for *. For example, either of these will work:

*   IN   A   5.5.5.5

*   IN CNAME mywebsite.com.

Now on the server, edit /var/cpanel/userdata/$user/$parentdomain, and look for the serveralias line. This is where the parked domains/aliases for a domain are listed, so you just need to append *.parentdomain to the same line. A serveraliase line for thecpaneladmin.com may look like this:

serveralias: www.thecpaneladmin.com thecpaneladmin.net www.thecpaneladmin.net *.thecpaneladmin.com

Now run:

/scripts/rebuildhttpdconf

And restart Apache. You can test the Wildcard subdomains by going to any subdomain of the parent domain, and it should go to the parent domain’s site. This may not be what you wanted it to do though. With wildcard DNS and virtualhosts, you need an .htaccess rewrite to redirect the subdomains. For example:

<IfModule mod_rewrite.c>
Options +FollowSymLinks
Options +Indexes
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !www.domain.com$ [NC]
RewriteCond %{HTTP_HOST} ^(www.)?([a-z0-9-]+).domain.com [NC]
RewriteRule (.*) %2/$1 [L]
</IfModule>

In the above example, if your subdomain is test.domain.com, the rewrite will send you to http://domain.com/test/page.html. You can modify the rewrite accordingly to achieve the results you want.

Keep in mind that the Apache configuration has to be done by someone with access to the user’s Apache config files, as you can’t add *.domain.com to cPanel as a subdomain or parked domain at this time. cPanel may change this in the future, but for now it’s something that the end user cannot do without administrator access.

A lot of hosts that deploy a large number of servers are automating updates instead of running them manually. While cPanel updates can be automated as well, it’s become a common question of how to automate Apache and PHP updates across a large number of servers without having to manually run EasyApache on each server, which can be a very time-consuming process. If Apache and PHP were built via RPM, you could simply run a yum update. However, since they are built with EasyApache it’s not quite as simple as updating an RPM, but it’s still very easy to automate.

A few things I want to mention before you consider automating Apache and PHP updates:

• You shouldn’t do this unless you have cPanel updates running automatically as well, for stable and release builds only. This reduces the chance of something going wrong and leaving you with broken builds across a ton of servers
• Always test your build first on one server before deploying

Scenario:

You have a large number of servers that are set up almost identically, and you want to schedule monthly updates to make sure PHP and Apache are always up to date, but still similar to provide consistency.

The easiest way to set this up is as follows:

1) Run EasyApache on one of the servers, configure your build as you wish, then save the profile. I would also recommend running the build to make sure that it works properly before you deploy it.

2) Go into /var/cpanel/easy/apache/profile and look for a file called _last_success.yaml. This will be the one you just saved, unless you updated a template that was already named, or you know for a fact that it’s named something else. Rename this template to something you would recognize, like latest.yaml. Edit the yaml file and change these fields:

name: Shared server build
note: “Default build for all shared servers”

The name and note will identify the build in your EasyApache interface.

3) Move this script to the ‘custom’ folder (/var/cpanel/easy/apache/profile/custom)

From here, what I recommend doing is uploading the build template to a repository so it can be easily “grabbed”. That way each time you update the build, you would update the template in the repository and automate the command that downloads it and builds Apache.  Since I named my yaml file latest.yaml, this is the command I’d run via cron on all my servers:

wget -O /var/cpanel/easy/apache/custom/latest.yaml http://repo.mydomain.com/ea/latest.yaml && /scripts/easyapache –profile=latest.yaml –build

The following command builds the profile automtically:

/scripts/easyapache –profile=latest.yaml –build

The latest.yaml file is the file name of the template I’m using, and –build indicates that the build should be started immediately instead of loading the EA configuration screen.

Here are a couple other options you might want to pass to /scripts/easyapache:

• –do_not_revert_on_conf_failure : Use if you want to fix httpd.conf problems manually after the build. NOT recommended for automated EA updates
• –skip-cpanel-version-check: Use if you don’t run automated cPanel updates and don’t want EasyApache to prompt for an update
• –always_do_the_latest_phps : Always use the latest PHP version, keeping in mind that “latest version” refers to the latest version available in EA
• –always_do_the_oldest_phps : Always use the oldest PHP version available in EA

You may also want to consider using hooks to automate post-build tests, and report any issues that may arise. Hooks are events/commands that run before or after a specific action. You can read more about hooks below:

http://etwiki.cpanel.net/twiki/bin/view/EasyApache3/EasyApacheHooks

A wildcard ssl basically allows you to use unlimited subdomains on a given domain name with one SSL certificate.  A user will need to purchase a wildcard SSL from a vendor that supplies them.

Similar to having multiple certificates installed on a server, each subdomain containing the certificate needs its own IP as well.  Wildcard SSL’s do not work like Wildcard DNS – you really do have to specifically install the certificate on each subdomain. Here are two methods to setting up Wildcard certificates for a domain.

Multiple Accounts

In this scenario, you’d have each subdomain hosted as a separate cPanel account, and each of those cPanel accounts will have its own IP address.

1. Generate the Certificate Signing Request (CSR) in WHM, using *.domain.com
2. Read this article to learn how to assign each account its own IP address
3. When you’re obtained the certificate,go to WHM > Install a SSL Certificate and Setup the Domain and paste in the CRT and CA Bundle for *.domain.com
4. The fields should auto-populate, in which case you need to make sure the IP is correct, then change the SSL hostname from *.domain.com to the target subdomain
5. Click install to install the certificate

One Account

This method may be best for users that are not resellers or that are on shared hosting servers, where having multiple cpanel accounts may not be ideal. In this case, you’d have one cPanel account and assign multiple IPs to its subdomains.

1. Generate the Certificate Signing Request (CSR) in WHM, using *.domain.co
2. Read this article to learn how to assign dedicated IPs to multiple subdomains on the same account
3. When you’re obtained the certificate,go to WHM > Install a SSL Certificate and Setup the Domain and paste in the CRT and CA Bundle for *.domain.com
4. The fields should auto-populate, in which case you need to make sure the IP is correct, then change the SSL hostname from *.domain.com to the target subdomain
5. Click install to install the certificate

I wrote this script a while back to fix the permissions of alias files in /etc/valiases when users were having trouble creating forwarders. You can also download the script in plaintext here.

#!/bin/bash
 # Script to fix permissions of valiases
 # Written by: Vanessa Vasile 5/17/10
 # http://thecpaneladmin.com
 
 for domain in `cat /etc/userdomains |awk '{print $1}' | grep -v "*" | cut -d: -f1`
 do

if ! [ -f /etc/valiases/$domain ]; then
 touch /etc/valiases/$domain
 fi
 
 user=$(egrep "^$domain:" /etc/userdomains |awk '{print $2}');
 chown $user:mail /etc/valiases/$domain
 chown $user:mail /etc/vdomainaliases/$domain
 chmod 644 /etc/valiases/$domain
 chmod 644 /etc/vdomainaliases/$domain
 done

Update: cPanel now has a script to allow you to do this:

/scripts/fixvaliases

500 Internal Server Errors are one of the most common PHP issues that I see customer experience, and it will occur mostly on servers with suPHP or PHP running as CGI.  These errors can be caused by something on the server, or an issue on the user’s site. Here ‘s what you should do if you see errors:

Check the logs

You can solve most problems quickly just by looking at the logs:

/usr/local/apache/logs/error_log

/usr/local/apache/logs/suphp.log

Here are some common errors:

SoftException in Application.cpp:357: UID of script "/home/user/public_html/test.php" is smaller than min_uid

SoftException in Application.cpp:422: Mismatch between target UID (511) and UID (510) of file "/home/user/public_html/test.php"

SoftException in Application.cpp:264: File "/home/user/public_html/test.php" is writeable by others

These are all permission/ownership issues, indicating that the owner of the PHP file being called in incorrect, or the permissions are higher than what is allowed in suphp.conf.

Invalid directions in .htaccess

If you’re running PHP in CGI or suPHP mode, you can’t use php_flag or php_value directives in .htaccess – you either need to use htscanner to allow Apache to parse those commands, or make php-related changes in php.ini within the user’s account. You can check the Apache error log in /usr/local/apache/logs/error_log to see if you get something like this:

/home/user/public_html/.htaccess: Invalid command 'php_flag', perhaps misspelled or defined by a module not included in the server configuration

If the error log indicates a problem with .htaccess, you need to remove the directives indicated and make sure your ssyntax is correct, and that they are in the correct places.

Incorrect ownership or permissions

PHP scripts and their immediate parent folder will usually have permissions limits when PHP runs in CGI/suPHP mode. By default, PHP files and their parent folders can not have group or ‘other’ writable permissions, and cannot be owned by a user on the system other than than the user that owns the home folder it is located in. Additionally, cPanel’s implementation of suPHP does not allow PHP to execute via browser from locations that are not inside a user’s home folder. The first thing you should check is that the PHP script and its parent folder(s) are not writable by ‘group’ or ‘other’, or owned by a different system user. You can usually see if this is an issue by tailing the suphp log in /usr/local/apache/logs/suphp.log, or whatever the suphp.conf has set as the log location.

You can adjust suPHP’s permissions allowances in /opt/suphp/etc/suphp.conf to allow ‘group’ and ‘other’ writable permissions if it’s necessary by modifying these values:

allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

If the problem is with the min_uid value being too low (such as if you’re running a PHP script as root), you can also modify the “min_uid” and “min_gid” values to be more permissive. Changing anything in the suphp.conf requires a restart of Apache.

SuPHP binary missing its “sticky” permissions

Take a look at the suphp binary. It should look a bit like this, and in most shells, will be highlighted in red:

-rwsr-xr-x 1 root root 341K Mar 30 12:25 /opt/suphp/sbin/suphp*

If it’s missing the ‘s’ in the permissions column, you need to re-add the sticky bit to allow users on the system to execute it properly:

chmod +s /opt/suphp/sbin/suphp

Last resort

If all else fails, you could be running a bum Apache build.  Try running EasyApache to reinstall to see if that fixes the problem.  You can also submit a support request to us and we may be able to fix this for you:

By default, cPanel supports the usage of one dedicated IP per account. However, you can get around this by editing just a few files on the server. Here are the steps:

1. Edit /var/cpanel/userdata/$USER/$SUBDOMAIN.$DOMAIN for each subdomain (for addon/parked domains you’ll usually edit the file for the subdomain associated with the addon/parked domain) and change the ip value to a ‘dedicated’ ip.

2. Run /scripts/rebuildhttpdconf

3. Edit the dns zone for the subdomain (which will likely be attached to the parent domain) and update the a-record to point to that IP as well. Then syncronize the zone out to the DNS cluster, if one exists:

/scripts/dnscluster synczone <parentdomain>

4. Edit /etc/domainips and add an entry for that sudomain to point to the IP and run /scripts/rebuildippool to make sure the IP is marked as taken.

This is a simple bash script I wrote to fix the permissions and ownership of files within a cpanel account. To use, simply copy the script your server, chmod 755, and pass the usernames as arguments:

./fixperms user1 user2 user3

You can also run a server-wide loop like this:

for i in `ls -A /var/cpanel/users` ; do ./fixperms $i ; done

Below is the script, but I recommend downloading it from here to ensure that the formatting is correct.

#!/bin/bash
# Script to fix permissions of accounts
# Written by: Vanessa Vasile 5/13/10
# http://thecpaneladmin.com

if [ "$#" -lt "1" ];then
echo "Must specify user"
exit;
fi

USER=$@

for user in $USER
do

HOMEDIR=$(egrep ^${user} /etc/passwd | cut -d: -f6)

if [ ! -f /var/cpanel/users/$user ]; then
echo "$user user file missing, likely an invalid user"

elif [ "$HOMEDIR" == "" ];then
echo "Couldn't determine home directory for $user"

else

echo "Setting ownership for user $user"

chown -R $user:$user $HOMEDIR
chmod 711 $HOMEDIR
chown $user:nobody $HOMEDIR/public_html $HOMEDIR/.htpasswds
chown $user:mail $HOMEDIR/etc $HOMEDIR/etc/*/shadow $HOMEDIR/etc/*/passwd

echo "Setting permissions for user $USER"

find $HOMEDIR -type f -exec chmod 644 {} \; -print
find $HOMEDIR -type d -exec chmod 755 {} \; -print
find $HOMEDIR -type d -name cgi-bin -exec chmod 755 {} \; -print
find $HOMEDIR -type f \( -name "*.pl" -o -name "*.perl" \) -exec chmod 755 {} \; -print
fi
done

Passive FTP is not enabled with pure-ftp by default. To enable this, edit /etc/pure-ftpd.conf and uncomment out this line:

PassivePortRange          30000 50000

This means that FTP will answer passively on the range of ports between 30000 and 50000, so you may want to narrow the scope to something like 30000 to 35000.  Once you do this, you need to restart FTP and open the range of ports you selected in your server’s firewall.

If you’re running ProFTP, you can edit /etc/proftpd.conf and add this line, if it doesn’t already exist elsewhere:

PassivePorts 30000 50000

When adding an email forwarder you may see an error like this:

Fatal! Write Failure: /etc/valiases/thecpaneladmin.com. Ignore any messages of success this can only result in failure!

To fix this, run (replace user with username and domain with the domain name)

chown user:mail /etc/valiases/domain.com

chmod 644 /etc/valiases/domain.com