First create an include file:
/usr/local/apache/conf/userdata/std/2/username/domain.com/custom.conf

Add directive to custom.conf:

php_admin_flag allow_url_include On


Then run to enable include:
/scripts/ensure_vhost_includes --user=username --verbose

Alternatively, enabling allow_url_include globally (server-wide) is done by editing /usr/local/lib/php.ini and adding “allow_url_include = On” directive to the Fopen wrapper section.
;;;;;;;;;;;;;;;;;;
; Fopen wrappers ;
;;;;;;;;;;;;;;;;;;

;Whether to allow the treatment of URLs (like http:// or ftp://) as files.
allow_url_fopen = On
allow_url_include = On

and restarting apache by issuing “service httpd restart” command as root.

Installation process is very straightforward provided you met the requirements like php-pear, gnupg, libgpg-error, and gpgme. You can install it directly from WHM -> Module Installers -> PHP Pecl, enter ‘gnupg‘ and click the Install button. You can do the same via shell with this command ‘pecl install gnupg‘. Then restart your Apache. Be sure to double check if the extension was added to you php.ini.

On Cpanel servers most of the requirements are present, like php-pear (if you compiled your apache/php with pear), gnupg, libgpg-error, etc, except for gpgme which is the main library used by gnupg extension. Our system is running CentOS 4.7 with latest STABLE branch of Cpanel (S35075 at this time of writing), PHP 5.2.9 with pear and libgpg-error (version 1.0-1 only). Only missing requirement was gpgme which i installed from source as it was not available on our default yum repository. You can also install it from other repositories like centos.karan.org. At this time the latest gpgme version is 1.1.8 but I installed version 1.1.2 because it’s the latest version compatible with our libgpg.

I also encountered an error library path when I check the extension, "error while loading shared libraries: libgpgme.so.11: cannot open shared object file: No such file or directory", so I had to add ‘/usr/local/lib‘ to /etc/ld.so.conf and run ldconfig, so that libraries in this directory are detected automatically.

This time I let the developer slide and implemented a fix on system end by appending umask 022 into /usr/local/apache/bin/envvars file and restarting apache. This will apply a umask of 022 to the default permission of 666 for newly created files. The result is that anytime apache creates a file be it via php or another way it will always have 644 permissions and will be world readable.
But wait the fun doesn’t end there as we are running cPanel on this particular server and this env change will be lost next time Apache is rebuilt via EasyApache. To make this change persistent create a file called umask with the digits 022 as contents in /var/cpanel/easy/apache/rawenv/

Installation:

ImageMagick
Check first if it’s installed:
/scripts/checkimagemagick
Proceed with Installation:
/scripts/installimagemagick
Installation will take a couple minutes as it will install other packages needed by ImageMagick. After the installation, you can check your ImageMagick version:
/usr/bin/convert --version
It will give you something like:
Version: ImageMagick 6.4.8 2009-05-11 Q16 OpenMP http://www.imagemagick.org
Copyright: Copyright (C) 1999-2009 ImageMagick Studio LLC

Imagick
Go to WHM -> Software -> Module Installers -> PHP Pecl (manage). On the box below “Install a PHP Pecl” enter “imagick” and click “Install Now” button – that’s all.

Restart Apache and check your phpinfo page to see the details of Imagick and ImageMagick as well. See linked images for reference: image1, image2.

Uninstall:

If you decide to uninstall it’s as easy as the installation process:
ImageMagick: /scripts/cleanimagemagick
Imagick: WHM -> Software -> Module Installers -> PHP Pecl (manage). Click on Uninstall button for Imagick.

hostname newhos.name.tld

Note: Don’t forget to create an A entry for your new hostname, otherwise you will get a popup message during WHM login.

2.)  Issue /usr/local/cpanel/cpkeyclt to update your Cpanel License Key, otherwise you will get Invalid License when you login to WHM/Cpanel interface.

Here are the two common situations of adding custom changes:

1.)  Changes added inside a <VirtualHost>
This is very simple as we only need to create a single file that will contain our changes.  But we need to understand the correct location on where to place this file so that our changes will be read properly.

There are several cases of adding these changes and below are some samples and the coresponding directory where to put them:

- One virtualhosts (either SSL or standard)
Apache1/SSL:  /usr/local/apache/conf/userdata/ssl/1/<cpanel_user>/<domain>/<filename>.conf
Apache1/Standard:   /usr/local/apache/conf/userdata/std/1/<cpanel_user>/<domain>/<filename>.conf
Apache2/SSL:   /usr/local/apache/conf/userdata/ssl/2/<cpanel_user>/<domain>/<filename>.conf
Apache2/SSL:   /usr/local/apache/conf/userdata/std/2/<cpanel_user>/<domain>/<filename>.conf

-  All virtualhosts (both SSL and standard)
Apache 1/2:   /usr/local/apache/conf/userdata/<something>.conf

-  All SSL virtualhost or all Standard virtualhost
Apache 1/2 – all SSL:  /usr/local/apache/conf/userdata/ssl/<filename>.conf
Apache 1/2 – all Standard:   /usr/local/apache/conf/userdata/std/<filename>.conf

* If you need to put the above changes on a specific Apache version you can put them this way:
Apache 1 – all SSL:   /usr/local/apache/conf/userdata/ssl/1/<filename>.conf
Apache 2 – all Standard:  /usr/local/apache/conf/userdata/std/2/<filename>.conf

The same process is followed on subdomains, like on one of my implementation i added a custom virtualhost in a subdomain to take effect on standard (http), so i put it on this directory:
/usr/local/apache/conf/userdata/ssl/2/gerold/mysubdomain.gerold.com/custom.conf.

Take note that you also need to create the directories like “ssl”, “std”, “1″, “2″, or “mysubdomain.gerold.com” in order to have the correct directory structure/path.

You can verify if your custom changes were added correctly using this command:
/scripts/verify_vhost_includes

Then, update the include files:
For changes concerning single account/user you can use this command:
/scripts/ensure_vhost_includes –user=<username>
And for all users run:
/scripts/ensure_vhost_includes –all-users

And finally, restart Apache (/etc/init.d/httpd restart)

2.)  Changes added outside a <VirtualHost>

Adding custom changes outside of virtualhost can be done in different ways, like creating a templates or using the include editor.
On my example, i will discuss using Include editor as i usually used this on some of our client sites.

Cpanel have three ways to place our custom changes using Include editor, these are:
- Pre-Main Include – this is placed at the top of the httpd.conf file
Location:  /etc/httpd/conf/includes/pre_main_1.conf
- Pre-VirtualHost Include – codes in this file are added before the first Vhost configuration
Location:  /etc/httpd/conf/includes/pre_virtualhost_1.conf
- Post-VirtualHost Include – codes in this file are added at the end of httpd.conf
Location:  /etc/httpd/conf/includes/post_virtualhost_1.conf

So to add our changes we can go to WHM:  Main >> Service Configuration >> Apache Setup >> Include Editor, and select where you want to place your custom changes (pre-main, pre-vhost, or post-vhost).
You can also edit directly the files (pre_main_1.conf, pre_virtualhost_1.conf, post_virtualhost_1.conf) located at /etc/httpd/conf/includes/.
Finally, restart Apache (/etc/init.d/httpd restart) for changes to take effect.

NOTE: For complete referrence please refer to Cpanel Docs.

rm -fr ${DIR}/${SUBDIR}

Hint: add the following alias for all users to prevent this: alias rm=’rm –preserve-root”

We were lucky in two ways. First off, this was not a production server, just a development and testing server and secondly the databases and web sites on that server were unaffected. That’s where the good news ended and Murphy’s Law kicked in. A couple of days before we found that our backup server had a corrupt filesystem on its RAID array. Since we did not have enough space available on other servers to place all the backups on other servers we temporarily suspended (you guessed it) the backups of the development and testing server.

To undelete or not to undelete

To get back up and running we immediately closed off access to the server and considered how we could recover the deleted files. Unfortunately undeleting files on an ext3 file system can only be done under certain circumstances. If the deleted files are still opened by some process the lsof utility can help as is documented on some web sites (just Google “ext3 undelete lsof”) but for larger scale undeletes the first step is to create an image of the partition in question. That image can then be searched for inode entries which can be very useful for finding specific files. However, if you want perform a more general undelete this method is a lot less useful because the file names will not be recovered.

Apart from the limited usefulness that creating this image would yield it would have taken several hours to complete during which development and testing would be at a standstill. We decided not to do this and instead take our losses instead. It is important to note what data we were losing at that point. Among the missing directories were some binary directories (/usr/sbin and such) which were easily recoverable by copying them from similarly configured servers. The most important missing data was the version control repository and a custom scripts directory. All the history of changes in the repository was lost but the latest state of the code was easily restored. We copied the latest code from the developer who had last performed a complete update (which is a part of the daily development process) and put that code into the repository again. Since the versions did not match up anymore after that (all code versions were reinitialized) all developers had to retrieve the complete set of code files again and copy their latest versions over it to keep working.

Although this is definitely a loss for us the impact is limited by the fact that we keep copies of all released code. These copies were unaffected on the server in question but are also present on other servers. If need be we can go through that history to track down a change, but the comments are gone and it’s not a process the developers can do themselves.

Rebooting the server

After all this we were left with one task, rebooting that server. Since we did not know exactly what got deleted this might give us some severe problems. This was scheduled for a quiet night with several system admins present. Unfortunately our hand was forced when a change in the iptables configuration caused a kernel panic. Rebooting the server revealed several more problems, the main one being the privileges on the /tmp directory. This resulted in Apache not being able to write session info there and MySQL not being able to write temporary data either. This was quickly solved of course. Without going into too many details the final action we took was to update our Cpanel. This reinstalled many missing scripts and binaries.

I bet you’re wondering why we don’t use off site backups. Well, we do actually. The problem is that this involves copying many gigabytes over a limited line so we made a selection of what needed to be copied and we focused mainly on all our production servers. The main purpose of our off site backups is to recover production servers in case our data center becomes unavailable.

Conclusions

It’s been an annoying experience and it’s hard to draw positive lessons from mr. Murphy’s teachings but all in all it could have been a lot worse. Production was not down or affected and even testing and development impact was pretty limited. The main things on our agenda after this are to review our backup strategy for essential locations and reviewing the use of root privileges on our servers. Although we use non-root users most of the time there are tasks that are made a lot quicker by changing to root. We all know the danger of this and need to be a lot more aware of it.

If you are running tomcat on a cpanel server here is what you can do to help you from losing your tomcat instance:

• backup; newer cpanel versions backup apache, configs, etc. but they will not care about tomcat. This means it is your job to save the tomcat files. Here are some important folders you should save:
  /usr/local/jdk – this is a link to the real jdk used on the system (jdk1.5.0_05 or jdk1.6.0_02 for ex.); save the real jdk also, just in case…
  /usr/local/jakarta/tomcat - this will contain all your tomcat configs, apps, logs, etc.
  /usr/sbin/starttomcat and /usr/sbin/stoptomcat – scripts used to start and stop tomcat (in case you made local changes, memory tunings, etc.)

The files above can be lost during the rebuild, and it is important to have them on hand to restore tomcat if it fails starting after the apache build. For example last time this happened for us we had to fix the /usr/local/jdk link to point to the proper jdk (we use 1.5 and cpanel changed the link to 1.6) and also the startup scripts that contained various local customizations were obviously overwritten .

Hopefully this information will be useful for other people, and hopefully you will see it before running easyapache .