R-Ts NetWorks

Server the Best


httpd is the Apache HyperText Transfer Protocol (HTTP) server program

Q 1. How to check apache server path

Whereis httpd

Q 2. Ways to restart httpd

/usr/sbin/httpd -k start

/etc/init.d/httpd restart

service httpd restart

Q 3. How to check apache version

httpd –v

httpd –v

Server version: Apache/2.2.13 (Unix)
Server built: Sep 23 2009 05:43:01
Cpanel::Easy::Apache v3.2.0 rev4791

Httpd –V

It will show the httpd version along with build parameters of httpd

Httpd –V

root@explore [~]# httpd -V
Server version: Apache/2.2.13 (Unix)
Server built: Sep 23 2009 05:43:01
Cpanel::Easy::Apache v3.2.0 rev4791
Server’s Module Magic Number: 20051115:23
Server loaded: APR 1.3.8, APR-Util 1.3.9
Compiled using: APR 1.3.8, APR-Util 1.3.9
Architecture: 32-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with….
-D APACHE_MPM_DIR=”server/mpm/prefork”
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D HTTPD_ROOT=”/usr/local/apache”
-D SUEXEC_BIN=”/usr/local/apache/bin/suexec”
-D DEFAULT_PIDLOG=”logs/httpd.pid”
-D DEFAULT_SCOREBOARD=”logs/apache_runtime_status”
-D DEFAULT_LOCKFILE=”logs/accept.lock”
-D DEFAULT_ERRORLOG=”logs/error_log”
-D AP_TYPES_CONFIG_FILE=”conf/mime.types”
-D SERVER_CONFIG_FILE=”conf/httpd.conf”

Q 4. How to check modules compiled with apache

httpd –l

httpd –M

httpd –l only shows the list of modules but httpd –M shows static and shared modules

Q 5. How to check apache log paths and how to view the logs

Error Log : record any errors that it encounters in processing requests

Access log : all requests processed by the server

1. Httpd –V

2. Open httpc.conf file and search for “ErrorLog” directive.

Open httpd.conf file and search “ CustomLog” directive

To check the logs :

tail –f error log file path

Q 6. . How to find out config file paths and how to check syntax of conf file.

Redhat and CentOS stores httpd conf file at :


Apache is, by default, installed in /etc/httpd directory. But this path also depends on how apache has been compiled. Default configuration file name httpd.conf.

1. Using find command:
# find / -name ‘httpd.conf’ -print

2. Using locate command:
locate httpd.conf

To check syntax of httpd.conf file

After making any changes in httpd.conf file run following commands to check the syntax :

httpd –t

Service httpd configtest

Q 7 How to check process running – apache process

lsof -i :80

(List open file system)

Option –i : This option selects the listing of files any of whose Internet
address matches the address specified.

Output :

httpd 10978 root 5u IPv4 34261427 TCP *:http (LISTEN)
httpd 11000 root 5u IPv4 34261427 TCP *:http (LISTEN)
httpd 11010 nobody 5u IPv4 34261427 TCP *:http (LISTEN)

Command: Command or a process involved
Pid: process ID
User: A user running the command
FD: The file descriptor
Type: type of connection
Device: Device number
Node: TCP/UDP nodes
Name: Ports that are awaiting connections have the keyword LISTEN appended to them.

netstat -an | grep :80 | sort

Show only active Internet connections to the server at port 80 and sort the results. Useful in detecting single flood by allowing users to recognize many connections coming from one IP.

watch -n 1 netstat -ta

Q 8. Apache failed – different error and there solutions

1. Error : Unable to open file

Check for the log file path and cd to it.
Check the log file size
Echo > error_log
Echo > access_log

Service httpd restart

2. Error : httpd not started bad user name

Copy the user name
Open httpd.conf file
Search the virtualhost entry for the user name
Remove the virtualhost entry from the conf file
Save and exit
Check the configuration of conf file
Restart httpd

3. Error : Address already in use: make_sock: could not bind to address no listening sockets available, shutting down
This is caused by one or more processes running on the 443 (secure socket) port. To fix this problem first find the process ID’s that are running on port 443:-
fuser 443/tcp
Out put of the command will show you list of processes running on 443 port no. Kill all process
Kill -9 process id
Restart httpd service.
4. Address already in use: make sock: could not bind to address no listening sockets available, shutting down
fuser 80/tcp
Kill -9 process id
5. Error in error log : No space left on device: Couldn’t create accept lock
No space left on device: mod_rewrite: could not create rewrite_log_lock Configuration Failed
Checking your disk shows that you have plenty of space.
The problem is that apache didn’t shut down properly, and it’s left myriads of semaphore-arrays left, owned by my apache-user.
ipcs -s | grep nobody

Removing these semaphores immediately should solve the problem and allow apache to start.

ipcs -s | grep nobody | perl -e ‘while () { @a=split(/s+/); print `ipcrmsem $a[1]`}’
restart http service.

6. Error

Apache generates semaphores and when it can not generate more, you should get an error like this:

“No space left on device:mod_rewrite: could not create_rewrite: could not create rewrite_log_lockConfiguration Failed”

You should delete semaphores to fix it.

Listing and deleting semaphores :
# ipcs -s grep apache
# ipcs -s grep apache perl -e ‘while () { @a=split(/s+/); print `ipcrm sem $a[1]`}’

It should be fine now 🙂

7. If you are getting error when you restart apache server

[root@server httpd]# service httpd restart
Stopping httpd: [ OK ]
Remaining processes: 26467
Stopping httpd: [ OK ]
Starting httpd: Warning: SuexecUserGroup directive requires SUEXEC wrapper.
Warning: SuexecUserGroup directive requires SUEXEC wrapper.
Warning: SuexecUserGroup directive requires SUEXEC wrapper.
Warning: SuexecUserGroup directive requires SUEXEC wrapper.
Warning: SuexecUserGroup directive requires SUEXEC wrapper.
Warning: SuexecUserGroup directive requires SUEXEC wrapper.
Solution :

You need to set the sticky bit for suexec. below is my path, so your suexec may be in a different place. refer to the link

On shell

httpd -V |grep -i suexec it will give path for suexec


root@bond [~]# httpd -V |grep -i suexec

-D SUEXEC_BIN=”/usr/local/apache/bin/suexec”

root@bond [~]# httpd -V |grep -i suexec
-D SUEXEC_BIN=”/usr/local/apache/bin/suexec”

root@bond [~]# ll /usr/local/apache/bin/suexec
-rwxr-xr-x 1 root root 18190 Jan 23 11:03 /usr/local/apache/bin/suexec*

root@bond [~]# chmod 4755 /usr/local/apache/bin/suexec SET sticky bit

root@bond [~]# ll /usr/local/apache/bin/suexec
-rwsr-xr-x 1 root root 18190 Jan 23 11:03 /usr/local/apache/bin/suexec*

Q 9. Main apache modules
a. mod_rewrite
b. mod_security

a. mod_rewrite
Mod_rewrite allows you to rewrite a webpage’s url on the fly, and you can rewrite the url to almost anything. It has a lot of uses everything from redirecting multiple WebPages to a new domain without actually changing the title, to making dynamic pages appear static.

However, it is somewhat complicated to learn, and if you make a mistake its also possible to really mess-up your server and create endless loops. Need less to say I don’t recommend messing around with this on you live site. The solution, if you want to mess around and experiment with it is, to run a test server on your own computer for test purposes. Apache by default comes with the mod_rewrite module installed but not enabled

This module operates on the full URLs (including the path-info part) both in per-server context (httpd.conf) and per-directory context (.htaccess) and can even generate query-string parts on result. The rewritten result can lead to internal sub-processing, external request redirection or even to an internal proxy throughput.
Configuration Directives

* RewriteEngine
* RewriteOptions
* RewriteLog
* RewriteLogLevel
* RewriteLock
* RewriteMap
* RewriteBase
* RewriteCond
* RewriteRule

How to check if mod_rewrite is enabled on server

1. Create one directory in your account.
2. create one .htaccess file in it
Options +FollowSymLinks
RewriteEngine On
save the above code in it.

3. Run the directory in browser
4. If –
– No errors Congrats mod_rewrite engine is now enabled.

– 500, Internal Server Error If you get this message then mod_rewrite was not installed/enabled on your computer.


mod_security help to protect your server from exploits that are passed though apache. Mod_security does this by inspecting the information sent in apache and filtering out all of the “bad” requests as determined by the set of rules specified in the httpd.conf.

How to disable mod_security on server
comment out (put a # in front of) the AddModule mod_security.c line and restart apache

How to disable mod_security for that individual account ?

Error :

[Sat Feb 07 08:14:37 2009] [error] [client] ModSecurity: Access denied with code 501 (phase 2). Match of “rx (?:^(?:application\\/x-www-form-urlencoded(?:;(?:\\s?charset\\s?=\\s?[\\w\\d\\-]{1,18})?)??$|multipart/form-data;)|text/xml)” against “REQUEST_HEADERS:Content-Type” required. [id “960010”] [msg “Request content type is not allowed by policy”] [severity “WARNING”] [hostname “www.nuclearfreefinland.org”] [uri “/admin/build/views/ajax/config-item/calendar/default/filter/status”] [unique_id “61e4N0g3s7cAAB0CYsUAAAAD”]

Error : Your webserver has the mod_security module enabled. As a result, you may see the “403 Forbidden” or “Not Acceptable” error messages after submitting forms that contain “curl”, “perl”, “set”, etc. It is recommended to disable this module or reconfigure it so that these words are not forbidden.

If you are receiving the error for mod_security, access denied with error code 403 when you check the error logs for any account. You can disable the mod_security for that account by adding a simple code in his .htaccess

SecFilterEngine Off
SecFilterScanPOST Off


Include “/usr/local/apache/conf/modsec2.conf”


php.ini file
• What is php.ini file
The php.ini file is where you declare changes to your PHP settings. You can edit the existing php.ini, or create a new text file in any subdirectory and name it php.ini.
• How to locate php.ini file
find / -name php.ini
locate php.ini
• Path of php.ini file
• Main options in php.ini
* open_basedir =
Error : open_basedir restriction in effect
Solution : Security >> Security Center >> Tweak PHP open_basedir Security
*. disable_functions = dl, system, passthru, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close,
pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid
* Resource Limits
max_execution_time = 30 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
memory_limit = 32M ; Maximum amount of memory a script may consume (32MB)

* display_errors = Off

Print out errors as a part of output. Keep it off

* log_errors_max_len = 1024

Error log file size is set to 1024 bytes.
* magic_quotes_gpc = On
Magic quotes for incoming GET/POST/Cookie data.
* upload_max_filesize = 16M
Maximum allowed size for uploaded files.
* * allow_url_fopen = Off
As long as allow_url_fopen is enabled in php.ini, you can use HTTP and FTP URLs with most of the functions that take a filename as a parameter. In addition, URLs can be used with the include(), include_once(), require() and require_once() statements (since PHP 5.2.0, allow_url_include must be enabled for these). See List of Supported Protocols/Wrappers for more information about the protocols supported by PHP.
* session.save_path = /tmp
session.save_path defines the argument which is passed to the save handler. If you choose the default files handler, this is the path where the files are created

Apache allows for decentralized management of configuration via special files placed inside the web tree. The special files are usually called .htaccess, but any name can be specified in the AccessFileName directive. Directives placed in .htaccess files apply to the directory where you place the file, and all sub-directories. The .htaccess files follow the same syntax as the main configuration files. Since .htaccess files are read on every request, changes made in these files take immediate effect.

Using .htaccess is enabled or not?

Options All
AllowOverride All

# In the server configuration file, put
# AllowOverride None
# This prevents the use of .htaccess files in all directories apart from those specifically enabled.

PHPSuExec Explained

This webpage will explain file/directory permissions, the differences between running PHP as an Apache module and running PHP as a CGI with Suexec, and it will also touch on some common problems experienced when running PHP as a CGI with Suexec.

A Brief Overview on File Permissions

0400 read by user
0200 write by user
0100 execute by user

0040 read by group
0020 write by group
0010 execute by group

0004 read by world
0002 write by world
0001 execute by world

By adding the permissions together, you will come up with the number that corresponds to the permission. For example, 400+200+100+40+20+10+4+2+1=777 – read/write/execute by user/group/world.

What is PHPSuexec?

PHPSuexec is the shortened term often used to describe running PHP as a CGI with Suexec. Running PHP as a CGI with Suexec creates a much more secure environment compared to running PHP as an Apache module. Below we will describe the differences in the two forms of PHP, with examples on how security differs with the two.

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!


When PHP runs as an Apache module you are able to manipulate PHP using .htaccess – since .htaccess is an Apache feature. When PHP runs as a CGI, you can no longer do this because Apache no longer understand the PHP flags and values. Instead, when PHP runs as a CGI, you will need to create your own PHP initialization file, this file is called php.ini — php.ini works almost the same as .htaccess — it is simply a text file with directives that will be used instead of the servers default directives.

To give you a better understanding about how both work in regards to PHP, we have listed a .htaccess file and a php.ini file below.

php_value magic_quotes_gpc on

magic_quotes_gpc = on

There is one main difference to the use of .htaccess vs php.ini — a .htaccess file can be placed at the root directory and effect all subdirectories with just 1 file, php.ini does not work this way. A php.ini file needs to be placed in every directory and subdirectory that requires the altered directives. This is a downfall for using PHPSuexec, however we hope that in the future PHP can be written to handle the php.ini file in a more workable fashion.. Last but not least, there is a directive used in .htaccess that needs to be altered in order to work under PHPSuexec. The directive ForceType needs to be changed to SetHandler. For example:

PHP as an Apache Module .htaccess Style

ForceType application/x-httpd-php

PHP as a CGI with Suexec .htaccess Style

SetHandler application/x-httpd-php

It is important to understand that you can still use .htaccess for a variety of Apache functions, such as mod_rewrite directives, password protection directives, etc. The only difference is that it can no longer process PHP directives.

How to check if phpsuexec is enabled on the server :

You can easily check if your server has phpsuexec enabled by accessing your server’s phpinfo

Simply look for the box which show

‘Server API’ :-
“Server API: Apache” , this means that your server is currently running php as an Apache module. If within the phpinfo page you see the following:-

“Server API: CGI”, then your server has a CGI installation of PHP with suexec enabled.

Common Problems experienced with PHPSuexec If your PHP scripts are reporting 500 Internal Server errors, please check the following:

* Make sure the directory permissions the PHP file is in are no greater than 755

* Make sure the PHP file permissions are no greater than 755 – 644 is the default permissions for files uploaded by FTP and will work fine for most PHP files.

* Make sure you do not have any .htaccess files which contain PHP flags/values or ForceType directives. These directives need to be handled differently, as explained above. Courtesy of hostmagik.

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.


August 3, 2012 - Posted by | Linux

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: