I am trying to setup a web server running Apache + mod_fcgid + mod_security chroot enabled and having a real hard time to get this working. Apache was installed from official CentOS repo and mod_fcgid and mod_security were installed from EPEL repo.

At first, I even was unable to start Apache while chroot is enabled but I've fixed lots of stuff but there's still some I need to sort out.

First problem, when I try to start Apache while it's stopped, it does start with no problems, however, when I try to restart it while running this is what I get;

$ service httpd restart
Stopping httpd:                                            [FAILED]
Starting httpd: (98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address
no listening sockets available, shutting down
Unable to open logs

Apache Error Log;

[Mon Jun 17 07:47:51 2013] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Jun 17 07:47:52 2013] [notice] ModSecurity: chroot checkpoint #1 (pid=954 ppid=953)
[Mon Jun 17 07:47:52 2013] [notice] ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/) configured.
[Mon Jun 17 07:47:52 2013] [notice] ModSecurity: APR compiled version="1.3.9"; loaded version="1.3.9"
[Mon Jun 17 07:47:52 2013] [notice] ModSecurity: PCRE compiled version="7.8 "; loaded version="7.8 2008-09-05"
[Mon Jun 17 07:47:52 2013] [notice] ModSecurity: LUA compiled version="Lua 5.1"
[Mon Jun 17 07:47:52 2013] [notice] ModSecurity: LIBXML compiled version="2.7.6"
[Mon Jun 17 07:47:52 2013] [notice] Digest: generating secret for digest authentication ...
[Mon Jun 17 07:47:52 2013] [notice] Digest: done
[Mon Jun 17 07:47:53 2013] [notice] ModSecurity: chroot checkpoint #2 (pid=955 ppid=1)
[Mon Jun 17 07:47:53 2013] [notice] ModSecurity: chroot successful, path=/var/www
[Mon Jun 17 07:47:53 2013] [notice] Apache/2.2.15 (Unix) DAV/2 mod_fcgid/2.3.7 configured -- resuming normal operations

The second problem is that regular HTML files are being served with no problems but PHP pages are not.

mod_security logs;

[17/Jun/2013:08:01:37 --0400] Ub76oUJVtI0AAAPEDiYAAAAG CLIENT_IP_GOES_HERE 51722 SERVER_IP_GOES_HERE 80
GET /testphp.php HTTP/1.1
Host: hostname
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: PHPSESSID=5a9jqak7dt30l2vvrs9c74lo81
Connection: keep-alive
Cache-Control: max-age=0

HTTP/1.1 500 Internal Server Error
Content-Length: 543
Connection: close
Content-Type: text/html; charset=iso-8859-1


Apache-Error: [file "fcgid_proc_unix.c"] [line 637] [level 4] [status 104] mod_fcgid: error reading data from FastCGI server
Apache-Error: [file "/builddir/build/BUILD/httpd-2.2.15/server/util_script.c"] [line 435] [level 19] Premature end of script headers: testphp.php
Apache-Handler: fcgid-script
Stopwatch: 1371470497629709 2809 (- - -)
Stopwatch2: 1371470497629709 2809; combined=25, p1=3, p2=10, p3=1, p4=1, p5=9, sr=0, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/).
Server: Apache
Engine-Mode: "ENABLED"


Where I'm wrong at? What I'm missing?


First issue

The first problem is relatively easy. That means that another daemon/service is already using port 80, which is the TCP port that Apache wants to use for listening for connections from browsers.

This command will show you what's using it:

$ netstat -tapn |grep :80
For example:
$ netstat -tapn |grep :80
tcp        0      0 :::80                       :::*                        LISTEN      13415/httpd         
tcp        0      0 ::ffff:         ::ffff:      TIME_WAIT   -                   
tcp        0      0 ::ffff:         ::ffff:      TIME_WAIT   -                   
tcp        0      0 ::ffff:     ::ffff:    TIME_WAIT   -                   
tcp        0      0 ::ffff:     ::ffff:    TIME_WAIT   -   

Here we can see that Apache (httpd) is already running and it's process ID is 13415.

You can either kill it or figure out what else it is that's listening on port 80.

Second issue

For you second issue, I think what's going on is that you've already got an Apache server running, just not the one you think it is. So kill it and see if your second issue goes away.

If it doesn't then you'll need to install some additional packages from the CentOS repositories. Specifically PHP and anything else that is needed for your particular application.

Incidentally, make sure you're stopping/starting the Apache service as either root or using the sudo command. Normal users aren't allowed to stop/start this service.

Third issue

As the OP pointed out the use of suEXEC in a chrooted jail isn't supported directly by suEXEC, so it's necessary to patch it. This would seem to still be the case with the current version of suEXEC.

Here's a pretty good tutorial that goes over the general architecture of setting up Apache in this manner along with the steps to recompile suEXEC so that it can support chroot.

  • Thanks for pointing that out. Once httpd is started, it isolates itself to chrooted directory and after that this makes it impossible to stop the service with regular ways. I belive this is the reason why I receive that error? I'm able to start the httpd again right after the existing process from previous start is killed. As for PHP, I have started think as if it's related with suEXEC of Apache? -> continues below. – compixtr Jun 17 '13 at 15:42
  • As you may guess, I am using wrapper scripts and I believe everything's configured properly considering the errors I've received about these wrapper scripts when they were inaccessible by the virtual host owner at the very first. I've found this; blog.modsecurity.org/2006/03/apache-suexec-c.html while searching around. Is this really the reason behind this? – compixtr Jun 17 '13 at 15:43
  • @compixtr - see my updates, I believe you're correct that suEXEC doesn't natively support running inside a chrooted environment. – slm Jun 17 '13 at 16:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.