"The mind of a Mad Tech!"

Run the following commands to install OpenSSL  on your server:

mkdir /root/setup && cd /root/setup
wget http://www.openssl.org/source/openssl-0.9.8q.tar.gz
tar -xvzf openssl-0.9.8q.tar.gz
cd openssl-0.9.8q
./config
make
make install

*Be  sure you allow all processes to finish gracefully before proceeding.*

Run the following command to verify the installation was successful:

openssl version

This should return the build information for the build you just installed.

Run the following commands to ensure the include files are in the correct place(s):

cd /home/root/openssl/openssl-0.9.8q
cd include/openssl
cp * /usr/include
cp * /usr/local/ssl/include
cp * /usr/local/ssl/include/openssl

Run the following commands to ensure the lib files are in the correct place(s):

cd /home/root/openssl/openssl-0.9.8q
cp lib* /usr/local/ssl/lib/
cp lib* /usr/lib/ ldconfig

You will need to halt the version of OpenSSL your running so WHM doesn’t write over it while compiling Apache. This requires you to exclude it from the yum updates, by altering /etc/yum.conf. The first line of which will read something a long the lines of:

exclude=mod_ssl* httpd* perl mysql* php* spamassassin* kernel* exim* courier* apache*

You need to add OpenSSL to this, which should get it to end up looking more like this:

exclude=mod_ssl* httpd* perl mysql* php* spamassassin* kernel* exim* courier* apache* openssl*

*Do not revert this! If you do, when cPanel runs it’s update, it will overwrite your version of OpenSSL and revert it back to an older instance*

You will then need to rebuild Apache in the normal manor (you can use Easy Apache in WHM or do it manually) using the ‘Apache Update’ link in WHM.

Thanks to Linux.com

I can’t stress this point enough and it’s good to see that this was published in an article. Bluelock has published an article entitled, “Common Myths When Architecting Distributed Systems” and it address several well known myths in the computer hosting industry, including one point that I agree with 100%;

“Myth #2: If you need to speed up your application, just add more machines
There is a big difference between speed and throughput. Speed is how fast an operation can be executed, while throughput deals with how many operations you can perform in a given time.

If you have a stored procedure that takes 30 seconds, adding two servers won’t change a thing. You can add RAM to prevent disk access, attempt to add cores and multi-thread the process or increase the speed of your storage tier, but unless you break the stored procedure into several smaller procs you cannot spread the workload effectively across a farm.

A great use case of horizontal scalability is raw HTTP traffic. When it comes down to the number of simultaneous worker threads that need to be available a sea of HTTP servers behind a nice, robust load balancer that performs MAC re-writing can make a huge difference.”

YES YES YES! If you are having a application / software issues, throwing more resources at the issues is likely not going to help! Of course there are always exceptions to this, but for the most part this is 100% correct.

You can read the entire article by going here.

Seeing that the company I work for has viewed the “Cloud” platform a viable and neccessary ground for extending its hosting, I’ve been devoted to looking at our existing and expanding “Cloud” environment as well as comparing it to other hosting solutions from hunderds (ok, not hundred’s, but see get what I mean) of vendors. Doing so I’ve come to realize that the major of key “Cloud” players are using Vmware’s ESX/ESXi, Microsoft’s Hyper-V (Not a huge fan), Xen/Xen Server (only small scale and only offering Linux) and even custom “Cloud” suites such as Amazon’s EC2.

Today I just wanted to through out a comparions of Softlayer’s “Cloud” offerings as it compares to Amazon and Rackspace and the differences in tech and pricing.

http://http.cdnlayer.com/softlayerweb/PS_EC2vsCL.pdf

Pretty interesting regarding the huge difference in price compared to what they offering you in terms of CPU, Storage and Memory.

If you have ever encountered the issue with Plesk 9, where you run a backup and the domain is suspended and you are not able to bring the account back by telling it to unsuspend the account in the domain settings, there is a way to do so via SSH.

To do this, you simply need to do the following;

1. Log into the server via SSH.

2. Type the following at your shell promp;

” /usr/local/psa/bin/domain -u domainname.com -status enabled”

Make sure you replace “domainname.com” with your domain name.

3. Once you do this, Plesk will bring the domain out of suspension.

“SUCCESS: Update of domain ‘domainname.com’ complete.

Now your domain is no longer suspended.

As of Plesk 8.x, Parallel’s has yet to provide SuPHP support for Plesk. However it is possible to add this manually, however it does involve using a 3rd party repo and involves recompiling php. If you are running a VPS, you will need to check with your Hosting provider to see if this is something they can do for you or if you would be responsible for doing so.

And with that, let’s get to the good stuff!

1. In order to install SuPHP on the server, download and install the atomic script

# wget -q -O – http://www.atomicorp.com/installers/atomic | sh

2. Once the script is installed, install SuPHP module using yum

# yum install mod_suphp

3. The next step is to load the SuPHP module with Apache. The suphp installation automatically creates a “mod_suphp.conf” file under the Apache configuration directory, if not create it.

# vi /etc/httpd/conf.d/mod_suphp.conf

and insert the following lines:

#Load the Mod_SuPHP module
LoadModule suphp_module modules/mod_suphp.so

### Uncomment to activate mod_suphp
suPHP_AddHandler x-httpd-php
AddHandler x-httpd-php .php

#Enable the SuPHP engine
suPHP_Engine on

#Specify the path to the configuration directory
suPHP_ConfigPath /etc

Apache calls all the configuration files from the /etc/httpd/conf.d directory by default so there is no need to include the module in the httpd.conf file separately.

4. Now,  configuration file under /etc should be present (if not create it)

vi /etc/suphp.conf

copy/paste the following contents as it is:

[global]
logfile=/var/log/suphp.log
loglevel=info
webserver_user=apache
docroot=/var/www/vhosts
allow_file_group_writeable=true
allow_file_others_writeable=false
allow_directory_group_writeable=true
allow_directory_others_writeable=false
errors_to_browser=false
umask=0022
min_uid=30
min_gid=30
x-httpd-php=”php:/usr/bin/php-cgi”
x-suphp-cgi=”execute:!self”

Make sure the “handle_userdir” directive is commented or removed from the file since it is deprecated from the latest version.

5. At the end, we have to restart the httpd service for all these changes to take effect

# service httpd restart

6. Test the SuPHP installation: Create a phpinfo.php file with 777 permission and it should show you an “Internal Server Error” on browsing.