WHM>Software>Install RPM
- installed openldap
- installed openldap-servers
- installed openldap-devel – if it is not installed, you’ll get “Cannot find ldap.h” error while recompiling – this also needs cyrus-sasl-devel installed
(If cyrus-sasl-devel won’t install – find your existing version and download it from the centos mirror
- installed openldap-clients – for working from command line

if you are using php5, add the following in /var/cpanel/easy/apache/rawopts/all_php5
–with-ldap=/usr

See this page for more info http://www.cpanel.net/support/docs/e…tom_flags.html – see that page for php4 support

then run /scripts/easyapache

It will then build apache / php and include ldap support for php.

Create a phpinfo page and you will see ldap listed there now.

Phpsuexec is a deprecated feature in cPanel where php is setup as cgi instead of apache module. All shared hosting servers have been updated from phpsuexec to suPHP. This KB applies to such clients that are still using phpsuexec on their VPSs/Dedicated servers. Phpsuexec brings a new level of security to the way php is used.

1) php scripts execute using the permissions of userid of the account holder instead of user “nobody”

2) world writable folders (chmod 777) is not required for file uploads through php

3) The php file need to have ownership of the user to execute in the user account (by default it is).

4) php file (script) does not need 755 permissions. 644 is fine. In fact 400 or 600 is ok too (especially good for sensitive information).

5) php_flag or php_value can NOT be used in .htaccess files (It will result in Internal Server Error).

6) The php flags that do not work in .htaccess can be moved to php.ini file in the same folder where php script exists. However, the php flag/value will be in the format of php.ini and not that of .htaccess. For example this from .htaccess

php_flag register_globals off

will go into php.ini as:

register_globals off

If php.ini exists in the folder where the php scripts exists, it will take all values from it (and nothing will be taken from main php.ini.

7) If the folder that contains a php file/script is world writable (chmod 777), it will result in Internal Server Error. This is similar to cgi/perl scripts under suexec that do not like such permissions for security reason. The normal folder permissions should be 755.

8)  Apache specific php functions do not work:

http://www.php.net/manual/en/ref.apache.php

9) If your .htaccess file contains “Options” directive, it should have + or – with the directive to keep the ExecCGI active.

10) Symbolic links do not work for php scripts for security reasons.

11) Some web applications (OS commerce, ZenCart etc.) check if its configure.php file is writable (since php is being executed with userid it should be), so it will complain that its writable. Please change the permissions to 444 via ssh. (chmod 444 /path/to/configure.php)

12) HTTP authentication via php code does not work. However you can continue to use it via .htaccess or password protected folder feature of the control panel.

13) If you use “AddType application/x-httpd-php” in .htaccess, it should be set to “AddHandler application/x-httpd-php”

Similarly if you are using ForceType in .htaccess to force a file to be treated as php, you will need to change it to SetHandler.

What is suPHP?
What is suPHP? What is being changed from phpsuexec to suPHP?

suPHP is a tool for executing PHP scripts with the permissions of their owners. Currently our servers use phpsuexec which also executes PHP with the permission of their owners. However these are two different tools and there are some improvements with moving to suPHP.

Once suPHP is available on your server, you can login to your control panel and find a link ‘PHP Configuration’ under ‘Software/Services’. On that page

1. You can switch your account’s php to php4 or php5

2. You can read how to configure php and how suPHP works. It is similar to phpsuexec as explained above excluding some improvements mentioned below.

3. Download server wide php.ini for php4 or php5 and customize it for your own needs. You may need to do this regularly to keep your php settings in synch with server level settings e.g after Zend Optimizer upgrade.

Changes from phpsuexec to suPHP:

1. By default php CLI is php5. Here are the paths for your reference:

/usr/bin/php (php5 cgi)
/usr/local/bin/php (php5 cli)
/usr/php4/bin/php (php4 cgi)
/usr/local/php4/bin/php (php4 cli)

2. There are some significant improvments in suphp such as

* HTTP based authentication auth works via php
* symbolic links to php files also work
* permissions of public_html does not need to be changed for using shared SSL with php5
* Custom error pages will work with both php4 and php5

3. ionCube PHP Loader will be available server wide alongwith Zend Optimizer. If you use custom php.ini you will need to update it by downloading it from your control panel so that latest Zend Optimizer can load for your scripts as well.

4. If you are setting up custom php settings, the custom php.ini file will be required in a folder where the php script needs to execute. Or you can place php.ini anywhere and have this directive in public_html/.htaccess

suPHP_ConfigPath /home/username/php5-config

where username is your cpanel account username, and php5-config is just a folder name (you can name it anything) and it will pick php.ini from that folder. Yes, you can have php.ini outside of your webroot in suPHP. This is a new feature.

5. To activate php5 on a subfolder or in your whole account, this directive was added in .htaccess in phpsuexec

AddHandler application/x-httpd-php5 .php .php3 .phtml

or a variant of it. Now this must be proceeded by the marker comment to block cpanel from changing your settings:

# Use PHP5 as default
AddHandler application/x-httpd-php5 .php .php3 .phtml

Or if you use control panel to activate php5 (upgraded servers), then you do not need to manually add the above directive.

Other updates

1. For semi-dedicated clients, ffmpeg will be available via both php4 and php5.

2. mod_gzip is being installed as well on all servers.

________________________________________________________

One more time..

Differences between phpsuexec and regular php

When using the common PHP installation on a webserver, php runs as the user nobody and it doesn’t require the execute flag to be enabled.

The problem on this is that if mod_openbasedir is not installed, every user will be able to read your php files because everyone is virtually sharing the same username (nobody).

As most of you already know, PHP Files are not meant to be read, but parsed, and that is where the problem resides. PHP Files have to be parsed, otherwise everyone who is able to read your php file will see settings that you would probably want to keep private, such as your MySQL username and password.

PHPSUEXEC fixes all this because it requires php to be run as the file owner’s username. (for example: andre)

This is not everything it fixes though. PHPSUEXEC is also here to fix file ownership problems. This has been a common issue on a few Content Management Systems such as Joomla and also on the popular blog software: WordPress.

It also adds security to your files as you can use permissions such as 600 or 700 in your files and your visitors will still be able to view them (parsed) in their browsers.

PHPSUEXEC will also refuse to serve any pages that are at security risk, for example with 777 as permissions. (will generate an Internal Server Error)

PHP as an Apache Module

When PHP runs as an Apache module, PHP files work under the Apache user/group known as “nobody”. For example, when a PHP file needs to write to another file or create/remove a file, it does so under the name “nobody”. In order to allow “nobody” to do this, you need to set specific permissions on the file/directory, such as 777 – which translates to read/write/execute by user/group/world. This is insecure because you have not only allowed the webserver (Apache) to read/write to the file, you have also allowed everyone else on the server to read/write to the file as well!

Due to the above conditions, when a PHP file creates or uploads a new file under your account, the new file will be owned by the user “nobody”. If you FTP into your account, all files owned by “nobody” will not be available for you to move, rename or delete. In this case the only way to remove the “nobody” owned files would be through a file on the server or to contact support and ask for the file ownership to be changed back to your username.

PHP as a CGI with Suexec

When PHP runs as a CGI with Suexec, PHP files work under your user/group. PHP files no longer require loose permissions to function, now they will require strict permissions. Setting your directories or PHP files to 777 will cause them to produce a 500 Internal Server Error, this happens to protect your PHP files from being abused by outside sources.

Under PHPSuexec your directories and PHP files can have permissions no greater than 755 (read/write/execute by your username, read/execute by group/world). Since you own your files, your scripts can function in any directory your user has created and can’t be manipulated by any outside users, including “nobody”.

Now, when a PHP file creates or uploads a new file under your account, the new file will be owned by your username. You will no longer have to worry about the webserver taking over your files and even more important, you will no longer have to worry about a stranger reading or writing to your files either!

How To Enable WHM Apache PHP SuExec

By default PHP on WHM/Cpanel is loaded as DSO (Dynamic Shared Object) module and is run by the user “nobody” by default. Though this method of loading the PHP module is normally the fastest way to serve PHP request, running it as using user “nobody” will be a real pain in the ass if you are serving multiple sites run by multiple users, you will be for sure run into file permission problems.

This is where the SuExec comes in play, every executed PHP scripts will be executed by the user who owns the VirtualHost that is server the request, this method has a lot of drawbacks too on both speed and security.

Anyway, if you still want to enable it then read on below.

1. Login to your Web Host Manager as root account then under the Service Configuration menu, look for the “Configure PHP and SuExec” and click on it.

2. On the “Configure PHP and SuExec” page, under “alter configuration” section, look for the PHP handlers and then change its values to “cgi” and then set the Apache SuExec to On. (by default the value is on)

3. Finally, click on “Save new configuration” button and wait til the Apache server restarted and your done.

To verify that SuExec is working as intended, try to upload a file or create a folder using an upload file script on PHP.

That’s all about it.

Troubleshooting Internal Server Errors (Error 500)

Everytime an internal server error occurs, it will be added to your Error Log in cPanel. (cPanel »» Error Log). This will usually give you a clue on where the error resides. In most cases it will be either a permission error on a bad command in your .htaccess file (remember that all php values have to go to your php.ini file).

Directories that need to be written onto will no longer require 777 as permissions and phpsuexec will refuse to write or read on directories exposed with such permissions. You will have to chmod them to 755 always.

To simplify it, just remember that you should never have a file or folder with world-writeable permissions, because you no longer have to.

MIMETypes

If you added a Mimetype to the system in order to run html files as php scripts (AddType as .htaccess command), you will have to remove it and add an ApacheHandler instead. This is easy to do though. Just log into your control panel, then click on Apache Handlers and add the following:

Extension: html (or htm) : AddHandler application/x-httpd-php

To permanently remove the open_basedir restrictions for a domain, create a vhost.conf file

vi /home/httpd/vhosts/example.com/conf/vhost.conf

and place the following lines:

<Directory /home/httpd/vhosts/example.com/httpdocs/>
php_admin_value open_basedir none
</Directory>

Once done, rebuild the include file with the command:

/usr/local/psa/admin/bin/websrvmng -a

and restart the Apache service:

service httpd restart

To verify the new settings, place a phpinfo.php file under the account, browse the file and check the “Local Value” column.

The advantages of having suPHP are:

1. Files and Directories those need 777 permissions to write into, via the browser will now need a maximum of 755 permissions. The files/directories with 777 permissions will result in an “Internal Server Error”.

2. If you need to manipulate the value of a php directive for a domain, for ex. register_globals, it needs to be placed in the php.ini of a domain instead of the .htaccess file as it will result in an “Internal Server Error”.

3. All the files and directories uploaded using a script will have the ownership of the user instead of user ‘apache’ (i.e. the Apache user).

4. A user can edit/remove the files using Ftp that are uploaded via the browser.

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

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

Once the script is installed, install SuPHP module using yum

# yum install mod_suphp

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.

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.

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

# service httpd restart

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

Note: The double-quotes ( ” ) in the suphp.conf file may change to dots ( . ) if the contents are pasted as it is, so make sure you change them to double-quotes.

ERROR: PleskFatalException
Unable to connect to database: mysql_connect() : Too many connections
0: /usr/local/psa/admin/plib/common_func.php3:190
psaerror(string ‘Unable to connect to database: mysql_connect() Too many connections’)

To resolve the “Mysql: Too many connections” issue, ssh to your server as root and restart the Mysql service

# /etc/init.d/mysqld restart

If the problem occurs quite frequently, you need to increase the “max_connections” on your server. First check the number max_connections set on your server

# mysqladmin variables -uadmin -p`cat /etc/psa/.psa.shadow` | grep max_connections

To increase the max_connections, edit the Mysql configuration file my.cnf

# vi /etc/my.cnf

and set the following parameter

max_connections = xxx

where, xxx is the number of connections you wish to set.

Save the file and restart the Mysql service for the changes to take affect:

# /etc/init.d/mysqld restart

qmail-queue-handlers[xxxx]: Unable to change group ID: Operation not permitted
qmail-queue[xxxx]: files: write buf 0xbff4dfe0[156] to fd (5) error – (32) Broken pipe
qmail-queue[xxxx]: files: cannot write chuck from 4 to 5 – (32) Broken pipe

It is due to the incorrect permission/ownership of the ‘qmail-queue’ file under the “/var/qmail/bin” directory. Make sure
the ownership is ”mhandlers-user:popuser’
the permission is 2511.

Check the current ownership/permission:

# ls -la /var/qmail/bin/qmail-queue

It should be as follows:

-r-x–s–x  1 mhandlers-user popuser 67804 May  4 08:41 /var/qmail/bin/qmail-queue

If not, correct the ownership

# chown mhandlers-user.popuser /var/qmail/bin/qmail-queue

set the proper permissions,

# chmod 2511 /var/qmail/bin/qmail-queue

Restart Qmail once and see if the email works.

Note: If the emails still doesn’t work, please comment this post with the error message and the output of the following command and I will find out the solution for you:

ls -la /var/qmail/bin/qmail-queue*

On a Plesk server, the mod_deflate module is installed by default, however it may be disabled in the Apache configuration file. To enable the module edit the Apache configuration file

vi /etc/httpd/conf/httpd.conf

Search for the line

#LoadModule deflate_module modules/mod_deflate.so

and uncomment it i.e. remove the ‘#’ mark

LoadModule deflate_module modules/mod_deflate.so

Save the file and restart the httpd service

service httpd restart

Now, create a .conf file under the /etc/httpd/conf.d/ directory since Apache reads all the .conf files from that directory on a Plesk server

vi /etc/httpd/conf.d/deflate.conf

and place the following code in it

<Location />
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI  \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary
</Location>

Save the file and restart the httpd service. The compression code will compress all the files except the .gif, .jpe, .jpeg and .png files. To test the compression, use the tool

http://www.whatsmyip.org/mod_gzip_test/

To enable compression for a specific directory or domain, specify the directory path in the <Location> directive in deflate.conf and restart the Apache server.

How to access the psa database in Plesk?
There are 2 ways to access the Plesk psa database, from the Linux command line (via ssh) and from the Plesk control panel.

Method 1) To access the psa database from command line:

SSH to your server as root. and execute the mysql command. The /etc/psa/.psa.shadow file contains the Plesk admin password.

# mysql -uadmin -p`cat /etc/psa/.psa.shadow`

You will be taken to the Mysql prompt. To switch to the psa database, execute,

mysql> use psa;

You are now in the psa database and can view all the tables

mysql> show tables;

Method 2) From the Plesk control panel.

Login to Plesk as user ‘admin’ and password from /etc/psa/.psa.shadow file.

Click “Settings” >> “Database Hosting Preferences” >> click OK >>
“Local MySQL server” >> “Databases” tab >> “Webadmin”.

Once you click “Webadmin”, phpMyAdmin will open in a new window from where you can access all the databases including the ‘psa’ database. Make sure pop-ups are enabled in your browser.

Determining the packages that need to be installed.
ERROR: Unable to install the “psa-backup-manager-9.x.x-cos5.buildxxxxxxx.00.i586? package.
Not all packages were installed.
Please, contact product technical support.

Solution:

Check if the required db4 packages are installed by executing:

# rpm -qa | grep db4

It will list the db4 packages. If the db4-devel and db4-utils are missing from the above output, install the packages using yum

# yum install db4-utils
# yum install db4-devel

That’s it. You can start the Plesk installation once again and it will install the psa-backup-manager successfully.

To fix the issue, go to

Plesk –> Click ‘Settings’ –> click “IP Addresses” –>
click the number under the ‘Users’ coloumn in front of the IP address –>
Assign the IP to the owner.

This will update the ‘psa’ database and allow the user to manage the domain from Plesk.