Us administrators eventually come to the realization that when you have a wildcard SSL certificate for 40 subdomains, you can’t practically have separate IPs and cPanel accounts for all of them. If you have a wildcard SSL certificate for all your subdomains, you can easily install the certificate on a single IP address for all the subdomains. For this particular scenario to work:

• All subdomains must be on the same IP and cPanel account
• You must have a wildcard SSL qualifying for *.tld.com

Keep in mind that for a wildcard SSL to work, it really does have to be installed for each subdomain. You can’t install it once and have it automatically work in the fly like wildcard DNS does – Apache just doesn’t work that way.  Luckily, we’ve scripted an easy solution for you.

Create the following files:

• /etc/ssl/certs/tld.crt

This file will contain the actual certificate, and should be named off of your top-level domain. For example, if the certificate is for *.mydomain.com, name the file mydomain.com.crt

• /etc/ssl/certs/tld.cabundle

This file will be the CA bundle for your wildcard certificate, if you have one.  If the certificate is for *.mydomain.com, name the file mydomain.com.cabundle

Now download the install script from here.

This is basically just a bash script that you can use to install a wildcard SSL for a domain. Running it will install the certificate on all subdomains of the domain passed to the script:

chmod 755 wildcardssl.sh

./wildcardssl.sh $domain

After it runs, all you need to do is restart Apache. Please make a copy of /var/cpanel/userdata before running the script for the first time, until you’ve verified that it works on your setup.  Please note that this script would need to be run again if more subdomains are added later on.

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

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:

One of the servers here at work was giving a 500 Internal Server error whenever a PHP page was loaded. Among the various things that can cause this error when you’re running PHP in CGI mode (suPHP), this error showing up in the Apache log was most unusual. Turns out it’s due to the suphp binary missing its sticky/suid permissions.

SecurityException in Application.cpp:188: Do not have root privileges. Executable not set-uid root?

To fix, simply chmod +s the suphp binary:

chmod +s /opt/suphp/bin/suphp

Cpanel has a lot of supporting software that you may be using on your server. In case something goes amiss, here is a list of scripts that reinstall cpanel-provided software on your system. For most all of these, you can pass a –force as an argument to force a reinstall of the application.

cPanel
/scripts/upcp

MySQL
/scripts/mysqlup

PostgreSQL
/scripts/installpostgres

Roundcube
/usr/local/cpanel/bin/update-roundcube

Horde
/usr/local/cpanel/bin/update-horde

Squirrelmail
/usr/local/cpanel/bin/update-squirrelmail

phpMyAdmin
/usr/local/cpanel/bin/updatephpmyadmin

pureFTP
/scripts/ftpup –force (See: Installing and Configuring pure-FTP)

Exim
/scripts/eximup

Courier IMAP
/scripts/courierup –force (See: Installing/Configuring Courier IMAP)

Dovecot
/scripts/dovecotup –force (See: Installing and Configuring Dovecot)

cpAddons
/scripts/cpaddonsup

NSD/BIND
/scripts/setupnameserver (NSD:/scripts/nsdup)

Apache/PHP
/scripts/easyapache (See: EasyApache)

suPHP
/scripts/suphpup

cPanel Internal PHP
/scripts/makecpphp

FrontPage Extensions
/scripts/fpupgrade

Mailman
/scripts/reinstallmailman (will not remove list data)

cpHulkd
/usr/local/cpanel/bin/hulkdsetup

Ruby
/scripts/installruby

Mod_python is one of the trickier things to install on cPanel servers. Below are the two methods I’ve used to get mod_python up and running on Apache 2.

yum -y install subversion (IF it’s not already installed)
svn co https://svn.apache.org/repos/asf/quetzalcoatl/mod_python/trunk mod_python
cd mod_python
./configure –with-apxs=/usr/local/apache/bin/apxs
make && make install

Then add to httpd.conf in the top section where the other modules are loaded:

LoadModule python_module modules/mod_python.so

And run the distiller to save the change in the configuration:

/usr/local/cpanel/bin/apache_conf_distiller –update

Using cPanel’s custom mod:

At the time this article was written, this method only worked with Apache 2.0 (not Apache 2.2). It will add a mod_python option to EasyApache so you can enable during the build. Follow the below instructions and then run EasyApache to select mod_python.

cd /var/cpanel/easy/apache/custom_opt_mods
wget http://www.cpanel.net/apps/easyapache/optmods/custom_opt_mod-mod_python.tar.gz
tar -C /var/cpanel/easy/apache/custom_opt_mods -xzf custom_opt_mod-mod_python.tar.gz
rm custom_opt_mod-mod_python.tar.gz