httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leif W" <>
Subject Re: [users@httpd] CGI + Virtual host difficulty
Date Fri, 30 Apr 2004 08:49:50 GMT
----- Original Message ----- 
From: "Charles Ulrich" <>
To: <>
Cc: <>
Sent: Monday, April 26, 2004 3:40 PM
Subject: Re: [users@httpd] CGI + Virtual host difficulty

> Joshua Slive said:
> >> Nope, no suexec in sight...
> >
> > Please double-check that, since it is a very likely cause of your
> > problems, assuming you didn't compile apache yourself.
> No suexec binary exists on the entire system, there is no package
> installed with the 'suexec' string in its name, and I can find no
> of it in any config files on the system.
> I also checked that the perl binary was executable by the www user,
and it
> is indeed executable by everyone. (Would have been extremely weird if
> wasn't, but hey, I'm grasping at straws here.)
> > Let's summarize:
> >
> > 1. The printenv script works when you call it from the command line
> Correct. './index.cgi' (what I named the printenv script for testing)
> fine with no errors and all of the expected outout.
> > 2. The printenv script fails with "premature end of script headers"
> > called as a cgi script.
> Correct.

Not sure if this would help, but I did see this behaviour in one
condition in the past.  When I was editing a file on a  Linux box from
Windows via a Samba share, when using TextPad, with the option to lock a
file and open it read-only.  Even after my TextPad was closed, my
Windows machine was turned off, and random lengths of time had passed,
the file would still fail through Apache, but run fine from the shell.
The problem in my case was some funky file-locking that didn't translate
too well between Windows and Linux.  'ls -al' listed only as 755.  But
of course, UNIX has like 5 bytes I think, world, group, owner, mode, and
a fifth and sixth (filetype), and one other.  What I could do, was cat
oldfile > newfile, then chmod 755 newfile, then ./newfile, then hit the
newfile from the web, then rm oldfile.  This is at least one quick and
painless test to rule out some funky locking.

> > 3. You are positive that your aren't running suexec or any other cgi
> > wrapper.
> suxec is not installed, as far as I can tell. There are existing
vhosts on
> this system, but they all use PHP. I don't think this would be a
> but then I've never used PHP, so I thought it might be worth

Well, did you run updatedb; locate suexec; (or your OS equivalent of
this Linux program)?  updatedb runs a recursive "find", so it's disk
intensive.  Not sure how to slow it down, it just goes nuts.  You an of
course prune directories (i.e. customer websites with non-Apache
program-data).  "As far as you can tell" sound like you're maybe 1-3%
unsure.  A regular "updatedb" leave no doubts whatsoever (unless the
binary was hacked by a rootkit ^^).  Manual inspection of all standard
PATH locations, all places where Apache might look (in it's current
install diretory, or any of the old ones or backups).  Are you loading
mod_suexec?  Do you have any User/Group/SuexecUserGroup directives?
What are they set to?  I use this little test script to see what a
program is executing as, similar to the other example farther down,
which apparently doesn work yet (but assuming you can get something to
try to run but fail with permissions error, not end of script headers

echo "Content-type: text/plain"
echo ""
echo "id="`id`

Maybe change the echo "..." lines to echo -n "...\r\n" so they give the
strictly more correct CRLF HTTP response, just to rule that out.

echo -n "Content-type: text/plain\r\n"
echo -n "\r\n"
echo "id="`id`"

Oh, does your main server error_log show this message:  [notice] suEXEC
mechanism enabled (wrapper: /path/to/suexec)

> > If this is the case, you have some weird stuff going on.  I'd look
at the
> > following:
> >
> > - Are you using any third-party modules?
> I checked this system's httpd.conf against one from a fresh install. T
> only difference, module-wise, is that this system loads and adds a
> php4_module, which is required by the other vhosts already running on
> system. I currently cannot remove the module to see if it fixes
> CGI scripts without causing a lot of phone calls to come my way. :)
> > - Can you make an sh cgi script run, as in
> > #!/bin/sh
> > echo Content-Type: Text/plain
> > echo
> > echo Hellow world.
> >
> > Joshua.
> Okay, did that... Made it executable by all users. Double checked that
> /bin/sh exists and is executable. (Couldn't hurt.) No dice. Same exact
> error, even in the logs.
> One thing I tried, on a tip from Bao, is creating a simple HTML file
> trying to access it through the vhost. This works.

Also, just tripple checking.  All the error messages are showing up in
the correct error logs?  Not some ambiguous vhost issue?

> I next tried removing a symlink from the vhost path to see if that was
> confusing something, but I still get an error.
> I also tried moving the printenv script to a different vhost to see if
> was just the configuration for the bugzilla vhost that was causing a
> problem, but the script fails to execute in the other,
> vhost as well.

As mentioned with my funky file lock, moving a file didn't create any
new inodes, just moved the existing inode within the file system
hierarchy, so I had the same end of script headers even after moving a
file around.  Had to be recreated, the old file removed, and the new
file renamed to the old filename.  Not sure what else to try... but
maybe rule out any other program dependencies by writing a simpel C
program to do the "Hello World!" instead, and compile it statically.

> Quite an odd little problem I've got here, it seems. I'm *very*
> the tips and suggestions that you've offered so far and hope the
> will come to light relatively soon.



The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message