in reply to Re^2: a classic : 'Premature end of script headers' problem
in thread a classic : 'Premature end of script headers' problem

oh wow.. ok .. you've got it easy on one hand because you have full access.. and hard on another because you have full access.

do this instead.. vim /usr/bin/debughttp (as root)

#!/bin/sh # this is just an example #tail -f /var/log/httpd/error_log tail -f /var/log/httpd/ssl_error_log | sed 's/^.\+0.41\]\|\, referer.\ ++\.cgi\|\?rm=\w\+//g' # or just # tail -f /var/log/httpd/error_log
(you know how to set perms on that? chmod 0700, just you everything, everyone else nothing)

Open a terminal and # debughttp forget the CGI::Carp 'fatalsToBrowser' crap.. get rid of all that, get rid of the open(STDERR, '>>' .. all that.

Make sure you have the right path to your httpd error log

call the script from your browser and enjoy the wonder that is POSIX.

Replies are listed 'Best First'.
Re^4: a classic : 'Premature end of script headers' problem
by hmbscully (Scribe) on Sep 19, 2007 at 18:52 UTC
    Ok, wow. Yeah, I may have root, but I don't understand any of that, so I'm not going to run off and put that on my server until I can spend sometime trying to figure out what tail does.
    In Apache that user is set up to have the error log at /home/account/logs, is this not the httpd error log?
    Thanks.

    UPDATE: In the /var/log/httpd/suexec.log, I found this:

    [2007-09-19 14:00:05]: uid: (506/devpreview) gid: (506/506) cmd: conse +nt.cgi [2007-09-19 14:00:05]: command not in docroot (/home/acccount/cgi-bin/ +asewk/consent.cgi)

    I assume this is a user account issue then and not my actual perl script?

    I learn more and more about less and less until eventually I know everything about nothing.

      If your answer to what I posted is '..trying to figure out what tail does..' Maybe you should not have root access on a server that serves outsite an intranet.

      You should know to # man tail

      You should really learn unix before you have that kind of control over a server.

      If you know what you're doing, you can secure a machine like that to be a fortress. If you don't- and you have root.. you can blow yourself up- maybe even take some people with you.

      I don't think there's any way I can prevent as coming accross as patronizing. I am sorry for that. I do not mean disrespect.

      I am sure you can learn this up and down and left and right. But until you do- I must stress - don't open that thing to accept outside requests- via the internet.

      A week or two of reading up could do a lot for you.

        Before you panic, this is a development box that is pretty severely restricted by a firewall to only be open to internal users and I'm not running commands, beyond looking at files, as root personally. When I say I'm root, I mean it in the sense that I can be root or have my network admins do whatever I want. I'm not restricted by a hosting provider account.

        The last line was pretty patronizing. I've actually been working in unix for 7 years, but I've never had root access before the last 2 months, so I haven't yet learned a lot of the admin stuff. I'd love to have a couple weeks of free time to "read up."


        I learn more and more about less and less until eventually I know everything about nothing.