cgiwrap-users

Re: [cgiwrap-users] 'with rewrite' option

[Mark M. <mar...@um...>]

On Fri, 19 Oct 2001, Joe Hourcle wrote:

> 	--with-rewrite=FILE
> 	       use a file to rewrite user directories
>
> Unfortunately, I can't seem to find documentation on what the format of
> this file is.  Can someone point me in the right direction?

The format of the file is lines of the form:

username:relative/path/to/cgi-bin/directory/from/home/directory

Documentation begins on line 1149 of the file util.c :)


> [I mean, hell, I ideally, I'd love to be able to tell it to completely
> ignore the password file, and use something else, but without breaking
> digging through the code, I'm going to assume that it's just using
> standard system calls, [which doesn't necessarily use the standard
> password file, of course]]

Well, digging through the code, on line 90 of cgiwrap.c we have:

        /* Now, get whatever information that is available about that */
        /* user - fetch this information from the passwd file or NIS */
        if ( !(user = getpwnam(userStr)) )
        {
                MSG_Error_NoSuchUser(userStr);
        }

So you don't need a /etc/passwd file as long as your getpwnam()
function in the standard library knows where to get user information.
In other words, your assumption appears to be a valid one.

By the way, many thanks to Nathan for a great program!  I think it
is much better than suEXEC.

                Mark Montague
                LS&A Information Technology
                The University of Michigan
                mar...@um...

[cgiwrap-users] 'with rewrite' option

[Joe H. <on...@dc...>]

I was going to install CGIWrap on a new machine (well, machines, as it's a
cluster), and I noticed:


	--with-rewrite=FILE
	       use a file to rewrite user directories

Unfortunately, I can't seem to find documentation on what the format of
this file is.  Can someone point me in the right direction?


[I mean, hell, I ideally, I'd love to be able to tell it to completely
ignore the password file, and use something else, but without breaking
digging through the code, I'm going to assume that it's just using
standard system calls, [which doesn't necessarily use the standard
password file, of course]]

-----
Joe Hourcle

RE: [cgiwrap-users] Sending email using perl scripts.

[Neulinger, N. <nn...@um...>]

This is a error in the script or in the configuration/behavior of sendmail
on the machine. (Sendmail is generating the error message that is causing
the httpd process to say that invalid headers were returned.). It has
nothing to do with cgiwrap, other than that cgiwrap in it's standard
configuration sends stderr output to the browser. 

You can also try adding:

$| = 1; 

to the top of your script, as that may help the situation by moving the
error output to later in the results.

-- Nathan

> -----Original Message-----
> From: David DelBiondo [mailto:dav...@ol...]
> Sent: Wednesday, October 03, 2001 1:24 PM
> To: Joe Hourcle
> Cc: Piotr Klaban; cgi...@li...
> Subject: Re: [cgiwrap-users] Sending email using perl scripts.
> 
> 
> I apologize for sending the attachments.  I too am skeptical 
> about attachments from people I do not know.  I believe my 
> problem is not with sendmail, but with cgiwrap.  All of the 
> emails are delivered.  If the email does not have a period in 
> the name, the browser returns "Thank you for your CD-ROM 
> catalog request.  You will receive a conformation by e-mail". 
>  If there is a period in the name the browser returns 
> "Internal Server Error. The server encountered an internal 
> error or misconfiguration and was unable to complete your 
> request".  But as I said the emails are being sent.
> 
> I will try the suggestion of writing the email to a file first.
> 
> Thank you all again for your help.
> 
> David
> 
> 
> The following message was sent by Joe Hourcle 
> <on...@dc...> on Wed, 3 Oct 2001 13:44:14 -0400 (EDT).
> 
> > 
> > 
> > On Wed, 3 Oct 2001, David DelBiondo wrote:
> > 
> > > My emails are being sent.  The problem is the response to the web
> > > browser.  If the name on the email has a period in it
> > > (som...@so...)  a script error is produced.  If 
> the email
> > > does not have a period in it, the response page is displayed.  I
> > > attached two gifs showing what happens (if they made it through).
> > > The error log has a malformed header error logged by 
> cgiwrap.  Thank
> > > you for the help.
> > 
> > Sorry, but I havea strict policy against attachments from 
> people I don't
> > know.  [Well, even from people I do know].
> > 
> > Anyway, I don't know exactly what the error message is in 
> the images, but
> > I would suggest changing the open() call to write out to a 
> file, and then
> > trying the call to sendmail by hand:
> > 
> > 	cat msgfile | sendmail -t
> > 
> > (where 'msgfile' is whatever name you write it out to).
> > 
> > This will ensure that you get whatever error sendmail's 
> trying to throw.
> > [There may be some bad address matching call, etc, that's 
> corrupting the
> > address before writing to sendmail, or any one of a number 
> of problems
> > which could cause sendmail to crap out]
> > 
> > -----
> > Joe Hourcle
> > 
> > 
> 
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 

Re: [cgiwrap-users] Sending email using perl scripts.

[David D. <dav...@ol...>]

I apologize for sending the attachments.  I too am skeptical about attachments from people I do not know.  I believe my problem is not with sendmail, but with cgiwrap.  All of the emails are delivered.  If the email does not have a period in the name, the browser returns "Thank you for your CD-ROM catalog request.  You will receive a conformation by e-mail".  If there is a period in the name the browser returns "Internal Server Error. The server encountered an internal error or misconfiguration and was unable to complete your request".  But as I said the emails are being sent.

I will try the suggestion of writing the email to a file first.

Thank you all again for your help.

David


The following message was sent by Joe Hourcle <on...@dc...> on Wed, 3 Oct 2001 13:44:14 -0400 (EDT).

> 
> 
> On Wed, 3 Oct 2001, David DelBiondo wrote:
> 
> > My emails are being sent.  The problem is the response to the web
> > browser.  If the name on the email has a period in it
> > (som...@so...)  a script error is produced.  If the email
> > does not have a period in it, the response page is displayed.  I
> > attached two gifs showing what happens (if they made it through).
> > The error log has a malformed header error logged by cgiwrap.  Thank
> > you for the help.
> 
> Sorry, but I havea strict policy against attachments from people I don't
> know.  [Well, even from people I do know].
> 
> Anyway, I don't know exactly what the error message is in the images, but
> I would suggest changing the open() call to write out to a file, and then
> trying the call to sendmail by hand:
> 
> 	cat msgfile | sendmail -t
> 
> (where 'msgfile' is whatever name you write it out to).
> 
> This will ensure that you get whatever error sendmail's trying to throw.
> [There may be some bad address matching call, etc, that's corrupting the
> address before writing to sendmail, or any one of a number of problems
> which could cause sendmail to crap out]
> 
> -----
> Joe Hourcle
> 
> 

Re: [cgiwrap-users] Sending email using perl scripts.

[Joe H. <on...@dc...>]

On Wed, 3 Oct 2001, David DelBiondo wrote:

> My emails are being sent.  The problem is the response to the web
> browser.  If the name on the email has a period in it
> (som...@so...)  a script error is produced.  If the email
> does not have a period in it, the response page is displayed.  I
> attached two gifs showing what happens (if they made it through).
> The error log has a malformed header error logged by cgiwrap.  Thank
> you for the help.

Sorry, but I havea strict policy against attachments from people I don't
know.  [Well, even from people I do know].

Anyway, I don't know exactly what the error message is in the images, but
I would suggest changing the open() call to write out to a file, and then
trying the call to sendmail by hand:

	cat msgfile | sendmail -t

(where 'msgfile' is whatever name you write it out to).

This will ensure that you get whatever error sendmail's trying to throw.
[There may be some bad address matching call, etc, that's corrupting the
address before writing to sendmail, or any one of a number of problems
which could cause sendmail to crap out]

-----
Joe Hourcle

Re: [cgiwrap-users] Sending email using perl scripts.

[David D. <dav...@ol...>]

My emails are being sent.  The problem is the response to the web browser.  If the name on the email has a period in it (som...@so...)  a script error is produced.  If the email does not have a period in it, the response page is displayed.  I attached two gifs showing what happens (if they made it through).  The error log has a malformed header error logged by cgiwrap.  Thank you for the help. 

David

The following message was sent by Piotr Klaban <ma...@ma...> on Wed, 3 Oct 2001 08:57:52 +0200.

> On Tue, Oct 02, 2001 at 05:55:03PM -0400, David DelBiondo wrote:
> > I added the error trapping like you said, but unfortunally it still did 
> 
> > not work.
> > 
> > open (MAIL, "|$mailprog -t 2>&1") || &Error('Unable to Open Sendmail');
> 
> If you use perl <5.6 then it is probable, that the above code
> do not catch the error. Then you have to check close(MAIL) return code:
> 
> close(MAIL) || &Error("Unable to send mail: $!");
> 
> -- 
> Piotr Klaban
> 
> 

Re: [cgiwrap-users] Sending email using perl scripts.

[David D. <dav...@ol...>]

I added the error trapping like you said, but unfortunally it still did 
not work.

open (MAIL, "|$mailprog -t 2>&1") || &Error('Unable to Open Sendmail');

I am going to try a diffrent script and see if the results are the 
same.  I will let you know what happens.

Thanks,
David

Joe Hourcle wrote:

> 
> On Tue, 2 Oct 2001, David DelBiondo wrote:
> 
>> I believe you are correct in thinking it is my script. I also have a
>> web based email program that I am using, which is written in perl,
>> that works fine.  The line that calls the sendmail program I altered
>> as follows.  $mailprog = '/usr/sbin/sendmail 2>&1'; but it did not
>> work I still received the error.  Again, it is only when I put a
>> period in the email name.  I can use underscores and dashes, they
>> work. But that period?
>> 
>> Thanks for the help.  Let me know if you have any other thoughts.
> 
> 
> The '2>&1' needs to go at the end of the command.
> [It redirects stderr to stdout]
> 
> >From the way you have 'mailprog' defined at the beginning, I'm guessing
> that you're calling it elsewhere, and passing other arguments to it.
> You'll need to find where it's actually called, and place the redirection
> after all other args.
> 
> -----
> Joe Hourcle
> 
> 
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 
> 
> 

RE: [cgiwrap-users] Sending email using perl scripts.

[Joe H. <on...@dc...>]

On Tue, 2 Oct 2001, David DelBiondo wrote:

> I believe you are correct in thinking it is my script. I also have a
> web based email program that I am using, which is written in perl,
> that works fine.  The line that calls the sendmail program I altered
> as follows.  $mailprog = '/usr/sbin/sendmail 2>&1'; but it did not
> work I still received the error.  Again, it is only when I put a
> period in the email name.  I can use underscores and dashes, they
> work. But that period?
>
> Thanks for the help.  Let me know if you have any other thoughts.

The '2>&1' needs to go at the end of the command.
[It redirects stderr to stdout]

From the way you have 'mailprog' defined at the beginning, I'm guessing
that you're calling it elsewhere, and passing other arguments to it.
You'll need to find where it's actually called, and place the redirection
after all other args.

-----
Joe Hourcle

RE: [cgiwrap-users] Sending email using perl scripts.

[David D. <dav...@ol...>]

I believe you are correct in thinking it is my script. I also have a web based email program that I am using, which is written in perl, that works fine.  The line that calls the sendmail program I altered as follows.  $mailprog = '/usr/sbin/sendmail 2>&1'; but it did not work I still received the error.  Again, it is only when I put a period in the email name.  I can use underscores and dashes, they work. But that period?

Thanks for the help.  Let me know if you have any other thoughts.

David
  

The following message was sent by "Neulinger, Nathan" <nn...@um...> on Tue, 2 Oct 2001 09:02:33 -0500.

> You're probably getting an error from sendmail sent to stderr. This is 
> a
> problem with your script. 
> 
> Suggest adding 2>&1 to the cmd line where you execute sendmail. 
> 
> -- Nathan
> 
> > -----Original Message-----
> > From: David DelBiondo [mailto:dav...@ol...]
> > Sent: Tuesday, October 02, 2001 8:54 AM
> > To: cgi...@li...
> > Subject: [cgiwrap-users] Sending email using perl scripts.
> > 
> > 
> > Hello Everyone,
> > 
> > A few months ago I purchased a Cobalt RaQ4i for my web 
> > server.  I ran into a strange problem.  I use perl scripts to 
> > process forms on my clients web sites and email them using 
> > sendmail, confirmation web page would be delivered back to 
> > the web browser.   All seemed to be working well until I had 
> > a person with a "." in their email 
> > address(som...@so...).  When the submit button is 
> > selected, the form is processed and the emails are sent, but 
> > a server error is returned to the web browser.  The error log 
> > has the following information in it.
> > [Tue Oct  2 07:52:17 2001] [error] [client 158.106.50.3] 
> > malformed header from script. Bad 
> > header=som...@so...... No su: /usr/cgiwrap/cgiwrap 
> > 
> > I posted on the cobalt site and my hosting companies site but 
> > no replys were given.  Is this a condition being created by 
> > cgiwrap and if it is, how can I fix it.
> > 
> > Thanks,
> > 
> > David     
> > 
> > _______________________________________________
> > cgiwrap-users mailing list
> > cgi...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> > 
> 
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 
> 

RE: [cgiwrap-users] Sending email using perl scripts.

[Neulinger, N. <nn...@um...>]

You're probably getting an error from sendmail sent to stderr. This is a
problem with your script. 

Suggest adding 2>&1 to the cmd line where you execute sendmail. 

-- Nathan

> -----Original Message-----
> From: David DelBiondo [mailto:dav...@ol...]
> Sent: Tuesday, October 02, 2001 8:54 AM
> To: cgi...@li...
> Subject: [cgiwrap-users] Sending email using perl scripts.
> 
> 
> Hello Everyone,
> 
> A few months ago I purchased a Cobalt RaQ4i for my web 
> server.  I ran into a strange problem.  I use perl scripts to 
> process forms on my clients web sites and email them using 
> sendmail, confirmation web page would be delivered back to 
> the web browser.   All seemed to be working well until I had 
> a person with a "." in their email 
> address(som...@so...).  When the submit button is 
> selected, the form is processed and the emails are sent, but 
> a server error is returned to the web browser.  The error log 
> has the following information in it.
> [Tue Oct  2 07:52:17 2001] [error] [client 158.106.50.3] 
> malformed header from script. Bad 
> header=som...@so...... No su: /usr/cgiwrap/cgiwrap 
> 
> I posted on the cobalt site and my hosting companies site but 
> no replys were given.  Is this a condition being created by 
> cgiwrap and if it is, how can I fix it.
> 
> Thanks,
> 
> David     
> 
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 

[cgiwrap-users] Sending email using perl scripts.

[David D. <dav...@ol...>]

Hello Everyone,

A few months ago I purchased a Cobalt RaQ4i for my web server.  I ran into a strange problem.  I use perl scripts to process forms on my clients web sites and email them using sendmail, confirmation web page would be delivered back to the web browser.   All seemed to be working well until I had a person with a "." in their email address(som...@so...).  When the submit button is selected, the form is processed and the emails are sent, but a server error is returned to the web browser.  The error log has the following information in it.
[Tue Oct  2 07:52:17 2001] [error] [client 158.106.50.3] malformed header from script. Bad header=som...@so...... No su: /usr/cgiwrap/cgiwrap 

I posted on the cobalt site and my hosting companies site but no replys were given.  Is this a condition being created by cgiwrap and if it is, how can I fix it.

Thanks,

David     

Re: [cgiwrap-users] cgiwrap php continued

[Brian A. <ba...@no...>]

You sure go above and beyond the call of duty troubleshooting with a 
newborn around, but I'm sure glad you did.  The suggestion to compile php
with the option "--enable-discard-path" works perfectly.  I had it set
aside in what I thought were all of php's configure security options, and
I was going to add them in one by one after I got a basic setup working.

Thanks again.
Brian Allen

On Wed, 5 Sep 2001, Nathan Neulinger wrote:

> Argh... damn... php is using PATH_TRANSLATED to locate the script. WTF
> does it need to be doing that when it is passed the script's location w/
> #!. 
> 
> ----
> cessna(70)> printenv
> QUERY_STRING=
> SCRIPT_NAME=/cgi-bin/cgiwrap/nneul/test.php
> PATH_INFO=
> PATH_TRANSLATED=/users/nneul/public_html/cgi-bin
> REQUEST_METHOD=GET
> cessna(71)> /users/nneul/public_html/cgi-bin/test.php
> cessna(72)> setenv PATH_TRANSLATED
> /users/nneul/public_html/cgi-bin/test.php
> cessna(73)> /users/nneul/public_html/cgi-bin/test.php
> X-Powered-By: PHP/4.0.6
> Content-type: text/html
> 
> <html>
> <head>
> <title>PHPTest</title>
> Testing1234
> ----
> 
> Well, that means that the path-translated setting in cgiwrap is STILL
> not right. I'll see about fixing that. I've asked people to send me
> information on correct behavior of this variable before, but have never
> gotten an answer, or any interest in changing the behavior, despite it's
> having been altered several times in cgiwrap's history.
> 
> If we set SCRIPT_FILENAME, which cgiwrap definately does, it still does
> not work.
> 
> Ah ha! If you build php with --enable-discard-path, it works.
Apparently
> php has some code in it to locate the script using path-translated and
> such so that people can install php directly inside cgi root (Ok, I
> relaly don't understand what would possess someone to do that. That
> sounds just like putting perl.exe inside cgi dir on windows...
> Whatever.)
> 
> Anyway, seems that adding --enable-discard-path will correct the
> problem. 
> 
> -- Nathan
> 
> Nathan Neulinger wrote:
> > 
> > Brian Allen wrote:
> > >
> > > Hi Nathan,
> > >         I still can't get php to work with cgiwrap or php-cgiwrap.  Here
> > > are the main points in my process:
> > >
> > > 1) Download the patch per Piotr's instance, cgiwrap-3.7, and php-4.0.6.
> > > 2) Apply patch to cgiwrap-3.7.  (I verified by hand that the patch was
> > >         applied correctly.)
> > 
> > Ok. That patch should not be necessary unless you are trying to run php
> > scripts without having a valid #! line and/or not executable. (It's a
> > patch for people too lazy to do normal script installation.)
> > 
> > > 3) Configure php with the following command:
> > >         ./configure --disable-force-cgi-redirect
> > > 4) Configure cgiwrap with the following command:
> > >         ./configure --with-cgi-dir=www/cgi-bin --with-httpd-user=www
> > >                     --with-php=/usr/local/bin/php
> > > 5) Edit apache's httpd.conf file:
> > >         AddHandler php-cgiwrap .php
> > >         Action php-cgiwrap /cgi-bin/php-cgiwrap
> > >
> > > I have attached two truss output files which I describe below:
> > >
> > > file1:          command1:
> > > ------------    --------------------------------------------------------
> > > apache.truss    truss -r all -w all -f -o apache.truss ./apachectl start
> > >
> > > (Note: after I ran the above command, I first tried the following url:
> > >
> > >         http://kosh.umuc.edu/cgi-bin/php-cgiwrap/ballen/hello.php
> > >
> > > Then I tried this url:
> > >
> > >         http://kosh.umuc.edu/cgi-bin/php-cgiwrap/ballen/test.cgi
> > >
> > > I did this so I could compare a successful call of php-cgiwrap versus a
> > > call which produces an error.)
> > >
> > > file:           command2:
> > > ---------       ---------------------------------------------------
> > > php.truss       truss -r all -w all -f -o php.truss ./php hello.php
> > >
> > > (Note: I wanted this truss output so I could compare the previous php
> > > failure versus a successful php call.)
> > >
> > > I still think the problem, or maybe it's just a symptom, is what I
> > > mentioned before, which is that the script name is not being passed to
> > > php-cgiwrap because the hello.php script is never opened while test.cgi is
> > > opened.  And in the php.truss output, the script hello.php is opened.
> > 
> > Ok. Depending on when the open occurs, it could be cgiwrap trying to
> > execute the script, or it could be cgiwrap trying to find the script -
> > although those should only be stat calls.
> > 
> > One possibility is that php is completely ignoring the fact that it was
> > executed via #! and is trying to find the script itself, despite already
> > knowing exactly where the script is.
> > 
> > Since I'm not having any luck diagnosing your problem here, I'm going to
> > try and set up php locally and see if I can reproduce your problem.
> > (However, I can't promise I'll get to it today, as I am home with a new
> > baby (born 8/31), so am pretty swamped.)
> > 
> > Only thing I can suggest at the moment, is try to reproduce the cgiwrap
> > execution environment variables (use that test script I mentioned) and
> > see what is different in that environment from the environment where the
> > script works. Then see if there is a minimal change necessary to get it
> > to function. (That's what I'll do as soon as I get it installed.)
> > 
> > -- Nathan
> > 
> > ------------------------------------------------------------
> > Nathan Neulinger                       EMail:  nn...@um...
> > University of Missouri - Rolla         Phone: (573) 341-4841
> > CIS - Systems Programming                Fax: (573) 341-4216
> 
> -- 
> 
> 
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nn...@um...
> University of Missouri - Rolla         Phone: (573) 341-4841
> CIS - Systems Programming                Fax: (573) 341-4216
> 

[cgiwrap-users] mod_cgiwrap and mod_phpcgiwrap

[Steven H. <st...@ha...>]

hi all,

please check out:

  http://steven.haryan.to/mod_cgiwrap/

it was some hack work which i did a while back. haven't got the 
time to properly package it or write a more complete 
documentation though, but i hope you can build and use it 
without much difficulty.

mod_cgiwrap is basically a replacer for mod_cgi + suexec. i 
needed something more flexible than suexec, but i hate the 
configuration part of cgiwrap. with mod_cgiwrap, wrapping is 
completely transparent to users, he/she can use the standard 
handler (cgi-script) in his/her .htaccess.

mod_phpcgiwrap is a module to do transparent wrapping of PHP CGI 
scripts. it is basically the same as mod_cgiwrap, but calls the

both works only with apache, obviously. to use the modules, you 
will need to patch cgiwrap (provided in the above url, but 
sorry, i last worked with 3.6.4) and rebuild it. you basically 
need to make cgiwrap not fixing environment variables (since 
mod_cgiwrap will supply the already correct ones, there are no 
redirections with the mod_cgiwrap scenario). plus it will add 
php wrapping support.

i hope the modules can be useful to you. so far it works for me.

comments welcome.

--
sh

Re: [cgiwrap-users] cgiwrap php continued

[Nathan N. <nn...@um...>]

Argh... damn... php is using PATH_TRANSLATED to locate the script. WTF
does it need to be doing that when it is passed the script's location w/
#!. 

----
cessna(70)> printenv
QUERY_STRING=
SCRIPT_NAME=/cgi-bin/cgiwrap/nneul/test.php
PATH_INFO=
PATH_TRANSLATED=/users/nneul/public_html/cgi-bin
REQUEST_METHOD=GET
cessna(71)> /users/nneul/public_html/cgi-bin/test.php
cessna(72)> setenv PATH_TRANSLATED
/users/nneul/public_html/cgi-bin/test.php
cessna(73)> /users/nneul/public_html/cgi-bin/test.php
X-Powered-By: PHP/4.0.6
Content-type: text/html

<html>
<head>
<title>PHPTest</title>
Testing1234
----

Well, that means that the path-translated setting in cgiwrap is STILL
not right. I'll see about fixing that. I've asked people to send me
information on correct behavior of this variable before, but have never
gotten an answer, or any interest in changing the behavior, despite it's
having been altered several times in cgiwrap's history.

If we set SCRIPT_FILENAME, which cgiwrap definately does, it still does
not work.

Ah ha! If you build php with --enable-discard-path, it works. Apparently
php has some code in it to locate the script using path-translated and
such so that people can install php directly inside cgi root (Ok, I
relaly don't understand what would possess someone to do that. That
sounds just like putting perl.exe inside cgi dir on windows...
Whatever.)

Anyway, seems that adding --enable-discard-path will correct the
problem. 

-- Nathan

Nathan Neulinger wrote:
> 
> Brian Allen wrote:
> >
> > Hi Nathan,
> >         I still can't get php to work with cgiwrap or php-cgiwrap.  Here
> > are the main points in my process:
> >
> > 1) Download the patch per Piotr's instance, cgiwrap-3.7, and php-4.0.6.
> > 2) Apply patch to cgiwrap-3.7.  (I verified by hand that the patch was
> >         applied correctly.)
> 
> Ok. That patch should not be necessary unless you are trying to run php
> scripts without having a valid #! line and/or not executable. (It's a
> patch for people too lazy to do normal script installation.)
> 
> > 3) Configure php with the following command:
> >         ./configure --disable-force-cgi-redirect
> > 4) Configure cgiwrap with the following command:
> >         ./configure --with-cgi-dir=www/cgi-bin --with-httpd-user=www
> >                     --with-php=/usr/local/bin/php
> > 5) Edit apache's httpd.conf file:
> >         AddHandler php-cgiwrap .php
> >         Action php-cgiwrap /cgi-bin/php-cgiwrap
> >
> > I have attached two truss output files which I describe below:
> >
> > file1:          command1:
> > ------------    --------------------------------------------------------
> > apache.truss    truss -r all -w all -f -o apache.truss ./apachectl start
> >
> > (Note: after I ran the above command, I first tried the following url:
> >
> >         http://kosh.umuc.edu/cgi-bin/php-cgiwrap/ballen/hello.php
> >
> > Then I tried this url:
> >
> >         http://kosh.umuc.edu/cgi-bin/php-cgiwrap/ballen/test.cgi
> >
> > I did this so I could compare a successful call of php-cgiwrap versus a
> > call which produces an error.)
> >
> > file:           command2:
> > ---------       ---------------------------------------------------
> > php.truss       truss -r all -w all -f -o php.truss ./php hello.php
> >
> > (Note: I wanted this truss output so I could compare the previous php
> > failure versus a successful php call.)
> >
> > I still think the problem, or maybe it's just a symptom, is what I
> > mentioned before, which is that the script name is not being passed to
> > php-cgiwrap because the hello.php script is never opened while test.cgi is
> > opened.  And in the php.truss output, the script hello.php is opened.
> 
> Ok. Depending on when the open occurs, it could be cgiwrap trying to
> execute the script, or it could be cgiwrap trying to find the script -
> although those should only be stat calls.
> 
> One possibility is that php is completely ignoring the fact that it was
> executed via #! and is trying to find the script itself, despite already
> knowing exactly where the script is.
> 
> Since I'm not having any luck diagnosing your problem here, I'm going to
> try and set up php locally and see if I can reproduce your problem.
> (However, I can't promise I'll get to it today, as I am home with a new
> baby (born 8/31), so am pretty swamped.)
> 
> Only thing I can suggest at the moment, is try to reproduce the cgiwrap
> execution environment variables (use that test script I mentioned) and
> see what is different in that environment from the environment where the
> script works. Then see if there is a minimal change necessary to get it
> to function. (That's what I'll do as soon as I get it installed.)
> 
> -- Nathan
> 
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nn...@um...
> University of Missouri - Rolla         Phone: (573) 341-4841
> CIS - Systems Programming                Fax: (573) 341-4216

-- 


------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216

Re: [cgiwrap-users] cgiwrap php continued

[Piotr K. <ma...@ma...>]

On Tue, Sep 04, 2001 at 04:41:37PM -0400, Brian Allen wrote:
> get php to work with cgiwrap on a netscape enterprise server or an
> apache server.  My next plan was to truss the output of cgiwrap as I

I assume you are talking about running the php scripts through
cgiwrap-php (cgiwrap v. 3.7 with cgiwrap-php patch).
If you are using that version of cgiwrap (ie. 3.7 with the patch)
and you can not run php scripts from the apache server, then
there is something wrong with your configuration. Did you add to the
server config the lines:

    AddHandler php-cgiwrap .php
    Action php-cgiwrap /cgi-bin/php-cgiwrap

and reload the apache server.

>     22981: open("/users/systems/ballen/www/cgi-bin", O_RDONLY) = 3
> 
> Notice that the script name, hello.php, was not passed to cgiwrap so it
I also would like to see the whole truss output (*DO NOT SEND THIS to the list*).

> could be opened.  I have seen one mention of this possible problem at
> this website by Piotr Klaban where it says:
> 
>     "There is new variable SCRIPT_FILENAME necessary with new php
> version"
Right, but I said that you have to use cvs version or cgiwrap v3.7.
Then with the newest version the SCRIPT_FILENAME variable is set.
IMHO this is not the problem we should look for.
I will change the text on the website (because everyone
should already upgrade cgiwrap to the version 3.7).

> Then I ran ./cgiwrap from the commandline, but I received no output so
> that idea did not work.

If you wish to run php scripts with cgiwrap, that is compiled with
the cgiwrap-php you need to run it with php-cgiwrap, not cgiwrap.

Regards,

-- 
Piotr Klaban

Re: [cgiwrap-users] cgiwrap php continued

[Nathan N. <nn...@um...>]

For testing purposes, can you create the following cgi and run it in
both cgiwrap and normal:

---
#!/bin/sh
echo Content-type: text/plain
echo ""
printenv
---

Just for the hell of it, you might also try

--- 
#!/bin/sh
echo Content-type: text/plain
echo ""
echo "execcing script:"
exec /path/to/php /path/to/script.php
---


Brian Allen wrote:
> 
> Thanks for the feedback.  Unfortunately, I still haven't been able to
> get php to work with cgiwrap on a netscape enterprise server or an
> apache server.  My next plan was to truss the output of cgiwrap as I
> called my script, hello.php, and compare it to the truss output of a cgi
> script, test.cgi, which is known to work with cgiwrap.
> 
> Here is the interesting part of the truss output from the good test.cgi
> call:
> 
>     23001: open("/users/systems/ballen/www/cgi-bin/test.cgi", O_RDONLY)
> = 3
> 
> Here is the corresponding line in the hello.php call:
> 
>     22981: open("/users/systems/ballen/www/cgi-bin", O_RDONLY) = 3

Is your hello.php marked executable? I'd have to see the rest of the
truss output for this to be very useful info though.

> Notice that the script name, hello.php, was not passed to cgiwrap so it
> could be opened.  I have seen one mention of this possible problem at
> this website by Piotr Klaban where it says:
> 
>     "There is new variable SCRIPT_FILENAME necessary with new php
> version"
>     http://www.klaban.torun.pl/patches/cgiwrap/
> 
> I was hoping Piotr or someone else could elaborate on this.
> 
> To work around this I ran a test and set the following variables:
>     setenv REQUEST_METHOD GET
>     setenv QUERY_STRING ""
>     setenv PATH_INFO /ballen/test.cgi
>     setenv SCRIPT_FILENAME test.cgi
> 
> Then I ran ./cgiwrap from the commandline (I made sure to use the
> correct --with-httpd-user and --with-cgi-dir when compiling cgiwrap).
> It worked, and here is the output:
>     testing
> 
> Then I did a similar test with the following variables:
>     setenv REQUEST_METHOD GET
>     setenv QUERY_STRING ""
>     setenv PATH_INFO /ballen/hello.php
>     setenv SCRIPT_FILENAME hello.php
> 
> Then I ran ./cgiwrap from the commandline, but I received no output so
> that idea did not work.
> 
> Could someone please explain exactly what this SCRIPT_FILENAME problem
> is and then how to work around it?
> (Note: I'm not convinced it's entirely a php problem because when I type
> ./php hello.php I see the php output, thus php does work by itself.)
> 
> Thank you very much for all feedback.
> Brian Allen

I think the underlying problem is that php is re-execcing the script or
something, despite being executed directly. I know the current 3.7 and
cvs cgiwrap has osme code in it to set script_filename.


> 
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users

-- 


------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216

[cgiwrap-users] cgiwrap php continued

[Brian A. <ba...@um...>]

Thanks for the feedback.  Unfortunately, I still haven't been able to
get php to work with cgiwrap on a netscape enterprise server or an
apache server.  My next plan was to truss the output of cgiwrap as I
called my script, hello.php, and compare it to the truss output of a cgi
script, test.cgi, which is known to work with cgiwrap.

Here is the interesting part of the truss output from the good test.cgi
call:

    23001: open("/users/systems/ballen/www/cgi-bin/test.cgi", O_RDONLY)
= 3

Here is the corresponding line in the hello.php call:

    22981: open("/users/systems/ballen/www/cgi-bin", O_RDONLY) = 3

Notice that the script name, hello.php, was not passed to cgiwrap so it
could be opened.  I have seen one mention of this possible problem at
this website by Piotr Klaban where it says:

    "There is new variable SCRIPT_FILENAME necessary with new php
version"
    http://www.klaban.torun.pl/patches/cgiwrap/

I was hoping Piotr or someone else could elaborate on this.

To work around this I ran a test and set the following variables:
    setenv REQUEST_METHOD GET
    setenv QUERY_STRING ""
    setenv PATH_INFO /ballen/test.cgi
    setenv SCRIPT_FILENAME test.cgi

Then I ran ./cgiwrap from the commandline (I made sure to use the
correct --with-httpd-user and --with-cgi-dir when compiling cgiwrap). 
It worked, and here is the output:
    testing

Then I did a similar test with the following variables:
    setenv REQUEST_METHOD GET
    setenv QUERY_STRING ""
    setenv PATH_INFO /ballen/hello.php
    setenv SCRIPT_FILENAME hello.php

Then I ran ./cgiwrap from the commandline, but I received no output so
that idea did not work.

Could someone please explain exactly what this SCRIPT_FILENAME problem
is and then how to work around it?
(Note: I'm not convinced it's entirely a php problem because when I type
./php hello.php I see the php output, thus php does work by itself.)

Thank you very much for all feedback.
Brian Allen

Re: [cgiwrap-users] another cgiwrap php question

[Jack O. <ja...@he...>]

Brian Allen wrote:
> 
> ... "Invalid Header" error:
> 
> [27/Aug/2001:13:04:32] failure (19812): for host sinclair.umuc.edu
> trying to GET /cgi-bin/cgiwrap/ballen/hello.php, cgieng_scan_headers
> reports: the CGI program /usr/local/ns-home/cgi-bin/cgiwrap did not
> produce a valid header (program terminated without a valid CGI header.
> Check for core dump or other abnormal termination)
> 
> The hello.php script is very simple:
> 
> #!/usr/local/bin/php
> <html>
> <body>
> my first php script<P>
> <?
> echo "hello world<P>";
> $today = date( "l dS of F Y h:i:s A" );
> PRINT "today is $today.";
> ?>
> <body>
> <html>
> 
> My question is why would there be a header problem?  There is no header
> error when I run the php script without cgiwrap. I didn't see any
> headers in the php script Jack Olszewski recently posted. 

Your script works for me alright under apache. There was the bang line
in my script:

#!/usr/local/bin/php

> Another bit
> of info (maybe related?) is I cannot figure out is why hello.php
> produces the following odd output when it is run without cgiwrap:
> 
> #!/usr/local/bin/php My first PHP script
> 
> Hello World
> 
> Today is: Thursday 30th of August 2001 12:39:17 PM.
> 
> Why is that "#!/usr/local/bin/php" showing up in the output?

It looks like being run in mod_php.

--
Jack

[cgiwrap-users] another cgiwrap php question

[Brian A. <ba...@um...>]

I have php(4.0.6) installed as a cgi and it works fine.  I also have
cgiwrap(3.7, no patch) installed which works fine as well.  We are using
Netscape Enterprise Server 3.63, not Apache.  However, I have never been
able to get cgiwrap to work with php.  Could anyone at least verify that
cgiwrap handles php scripts or am I wasting my time? I don't see any
reason why cgiwrap couldn't handle php, but when I try to pull up a php
page using cgiwrap I get the following "Invalid Header" error:


[27/Aug/2001:13:04:32] failure (19812): for host sinclair.umuc.edu
trying to GET /cgi-bin/cgiwrap/ballen/hello.php, cgieng_scan_headers
reports: the CGI program /usr/local/ns-home/cgi-bin/cgiwrap did not
produce a valid header (program terminated without a valid CGI header. 
Check for core dump or other abnormal termination)


The hello.php script is very simple:


#!/usr/local/bin/php
<html>
<body>
my first php script<P>
<?
echo "hello world<P>";
$today = date( "l dS of F Y h:i:s A" );
PRINT "today is $today.";
?>
<body>
<html>	


My question is why would there be a header problem?  There is no header
error when I run the php script without cgiwrap. I didn't see any
headers in the php script Jack Olszewski recently posted.  Another bit
of info (maybe related?) is I cannot figure out is why hello.php
produces the following odd output when it is run without cgiwrap:


#!/usr/local/bin/php My first PHP script

Hello World

Today is: Thursday 30th of August 2001 12:39:17 PM.


Why is that "#!/usr/local/bin/php" showing up in the output?
Thank you for any advice you can provide.
Brian Allen
University of Maryland University College

Re: [cgiwrap-users] cgiwrap and php

[Jack O. <ja...@he...>]

Nathan Neulinger wrote:
> 
> > It's been my suspicion all along that cgiwrap should know about php,
> > as it knows about perl (see --with-perl).
> 
> Um. It doesn't know anything special about perl. That's just so the log
> analyze script in the unsup dir can be built and customized with the
> local path to perl instead of wiring /usr/bin/perl.
> 
> -- Nathan
> 

Yes, it is the way php checks uid in safe mode rather than anything
wrong with cgiwrap. I wrote a little test script that writes and reads
the same file under cgiwrap:

-----------------------------------------------------------------------
#!/usr/local/bin/php

Testing phprun.cgi for <b>
<?
  echo "$user";
?>
</b><p>writing index.php ...
<?
  $f = fopen("/www/$user/index.php","w");
  if ($f) {
           echo "success.\n";
           fputs($f,"file written by $user\n");
           fclose($f);
  } else {
           echo "failure.\n";
  }
?>
<p>reading index.php ...
<?
  $f = fopen("/www/$user/index.php","r");
  if ($f) {
           echo "success.\n";
           $content = fgets($f);
           fclose($f);
           echo "<br>content: $content<br>";
  } else {
           echo "failure.\n";
  }
?>
---------------------------------------------------------------------

When executed in the absence of /www/dran/index.php, it succeeds in
creation of the file:

-rw-r--r--    1 dran     hermes         21 Aug 30 08:14
/www/dran/index.php

But it fails in reading the file back:

--- first run - no index.php in /www/dran ------------------------
Testing phprun.cgi for dran

writing index.php ... success. 

reading index.php ... 
Warning: SAFE MODE Restriction in effect. The script whose uid is 0 is
not allowed to access /www/dran/index.php
owned by uid 502 in /home/dran//E/runphp.cgi on line 19

Warning: fopen("/www/dran/index.php","r") - No such file or directory
in /home/dran//E/runphp.cgi on line 19
failure. 
------------------------------------------------------------------

When run for the second time:

--- second run - after index.php has been created -----------------
Testing phprun.cgi for dran

writing index.php ... 
Warning: SAFE MODE Restriction in effect. The script whose uid is 0 is
not allowed to access /www/dran/index.php
owned by uid 502 in /home/dran//E/runphp.cgi on line 8

Warning: fopen("/www/dran/index.php","w") - Inappropriate ioctl for
device in /home/dran//E/runphp.cgi on line 8
failure. 

reading index.php ... 
Warning: SAFE MODE Restriction in effect. The script whose uid is 0 is
not allowed to access /www/dran/index.php
owned by uid 502 in /home/dran//E/runphp.cgi on line 19

Warning: fopen("/www/dran/index.php","r") - Inappropriate ioctl for
device in /home/dran//E/runphp.cgi on line 19
failure. 
-------------------------------------------------------------------

In conclusion, the user dran is able to create files, but not to read
them, or rewrite them, even in the same php script under cgiwrap. 

--
Jack

Re: [cgiwrap-users] cgiwrap and php

[Nathan N. <nn...@um...>]

> It's been my suspicion all along that cgiwrap should know about php,
> as it knows about perl (see --with-perl).

Um. It doesn't know anything special about perl. That's just so the log
analyze script in the unsup dir can be built and customized with the
local path to perl instead of wiring /usr/bin/perl. 

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216

Re: [cgiwrap-users] cgiwrap and php

[Jack O. <ja...@he...>]

Piotr Klaban wrote:
> 
> On Wed, Aug 29, 2001 at 09:45:24AM +1000, Jack Olszewski wrote:
> > <b>Warning</b>:  SAFE MODE Restriction in effect.  The script whose
> > uid is 99 is not allowed to access /www/dran/index.php owned by uid
> > 502 in <b>/home/dran//E/runphp.cgi</b> on line <b>5</b><br>
> > ...
> > ---------------------------------------------------------------------
> >
> > The question is why php sees the uid of /home/dran//E/runphp.cgi as
> > still 99 despite its change into 502 by cgiwrap.
> >
> > Hope someone might be able to explain,
> 
> I will try to.
> 
> 1. The message is not from cgiwrap, but from php - that is clear.
>    Then it is probably not cgiwrap related, the OT.
> 2. You have in line 5 of /home/dran//E/runphp.cgi
>    something like
>     require('/www/dran/index.php');
>    where /www/dran/index.php is owned by 502 and /home/dran//E/runphp.cgi
>    is owned by 99.
> 

Yes, exactly.

> 3. Lets check it a while:
> 
> % cat > testres.php
> <?php
> require('/etc/passwd');
> ?>
> 
> % php -f testres.php
> PHP Warning:  SAFE MODE Restriction in effect.  The script whose
>   uid is 202 is not allowed to access /etc/passwd owned by uid
>   0 in testres.php on line 2
> 

Of course, if run directly rather than by cgiwrap.

> % ls -lan testres.php /etc/passwd
> -rw-r--r--   1 0        0              x Aug 27 09:43 /etc/passwd
> -rw-r--r--   1 202      200           33 Aug 29 09:37 testres.php
> 
> For running the php programs from the cgiwrap, you can try
> the patch available at:
>   http://www.klaban.torun.pl/patches/cgiwrap/

It's been my suspicion all along that cgiwrap should know about php,
as it knows about perl (see --with-perl).

> But I need to check if it compiles cleanly with the last cgiwrap
> release - the most recent will be available today.
> 

Eagerly awaiting,
--
Jack

ps Piotr, you might be interested to know the full name of my test
user dran, Zimny Dran   :)

Re: [cgiwrap-users] cgiwrap and php

[Piotr K. <ma...@ma...>]

On Wed, Aug 29, 2001 at 09:45:24AM +1000, Jack Olszewski wrote:
> <b>Warning</b>:  SAFE MODE Restriction in effect.  The script whose
> uid is 99 is not allowed to access /www/dran/index.php owned by uid
> 502 in <b>/home/dran//E/runphp.cgi</b> on line <b>5</b><br>
> ...
> ---------------------------------------------------------------------
> 
> The question is why php sees the uid of /home/dran//E/runphp.cgi as
> still 99 despite its change into 502 by cgiwrap.
> 
> Hope someone might be able to explain,

I will try to.

1. The message is not from cgiwrap, but from php - that is clear.
   Then it is probably not cgiwrap related, the OT.
2. You have in line 5 of /home/dran//E/runphp.cgi
   something like
    require('/www/dran/index.php');
   where /www/dran/index.php is owned by 502 and /home/dran//E/runphp.cgi
   is owned by 99.

3. Lets check it a while:

% cat > testres.php
<?php
require('/etc/passwd');
?>

% php -f testres.php 
PHP Warning:  SAFE MODE Restriction in effect.  The script whose
  uid is 202 is not allowed to access /etc/passwd owned by uid
  0 in testres.php on line 2

% ls -lan testres.php /etc/passwd
-rw-r--r--   1 0        0              x Aug 27 09:43 /etc/passwd
-rw-r--r--   1 202      200           33 Aug 29 09:37 testres.php

For running the php programs from the cgiwrap, you can try
the patch available at:
  http://www.klaban.torun.pl/patches/cgiwrap/
But I need to check if it compiles cleanly with the last cgiwrap
release - the most recent will be available today.

Best regards,

-- 
Piotr Klaban

[cgiwrap-users] cgiwrap and php

[Jack O. <ja...@he...>]

Hello everybody,

I seem to have a problem with cgiwrap (v.3.7) and php (v.4.0.6, safe
mode) running under apache (v.1.3.12). It is illustrated here by a
copy of what I get with cgiwrapd:

---------------------------------------------------------------------
...
Environment Variables:
     QUERY_STRING: ''
      SCRIPT_NAME: '/E/cgiwrapd/dran/E/runphp.cgi'
  SCRIPT_FILENAME: '/home/dran//E/runphp.cgi'
        PATH_INFO: ''
  PATH_TRANSLATED: '/home/dran/'
      REMOTE_USER: 'dran'
      REMOTE_HOST: '<NULL>'
      REMOTE_ADDR: '203.35.8.197'

Logging Request (File)

UIDs/GIDs Changed To:
   RUID: '502'
   EUID: '502'
   RGID: '503'
   EGID: '503'

Changing current directory to '/home/dran//E'



Output of script follows:
=====================================================
X-Powered-By: PHP/4.0.6
Content-type: text/html


Testing phprun.cgi
 for <b>dran</b><hr>
<br>
<b>Warning</b>:  SAFE MODE Restriction in effect.  The script whose
uid is 99 is not allowed to access /www/dran/index.php owned by uid
502 in <b>/home/dran//E/runphp.cgi</b> on line <b>5</b><br>
...
---------------------------------------------------------------------

The question is why php sees the uid of /home/dran//E/runphp.cgi as
still 99 despite its change into 502 by cgiwrap.

Hope someone might be able to explain,
--
Jack

[cgiwrap-users] Help needed w/cgi wrap!

[<Mj...@cs...>]

I have no clue what it is and never had to deal with it! I recently moved my 
hosting accounts, and found my self in more trouble than it was worth! I am 
now getting some CGIWRAP error and simply don't understand what to do! I get 
this error code at http://www.freetoresale.com/cgi-bin/stats.cgi if you can 
help me please do so!

Sincerely, 
Michael Orta
President/Founder
http://www.FreeToResale.com
=======================================
       ~~~ Please Visit Our Other Sites ~~~
=======================================
http://www.AandEGifts.com (For Sale)
http://MikesAdClub.Tripod.com (Just Opened)
http://www.AandEGiftsStore.com (For Sale)
http://www.Scriptsinabox.8m.com
http://www.UltimateEbooK.8m.com
http://MoneyMakingPackage.Tripod.com
http://www.TheUltimateEbooks.com
http://QualityLists.Tripod.com
=======================================
        ~~~ Domain Names For Sale: ~~~
=======================================
AandEGifts.com and AandEGiftsStore.com
To make an offer please email me at mj...@cs...
=======================================
Join FreeToReSale.com Affiliate program and make

$22.61 per sale you refer! It is FREE and nothing to
loose so join today at 
http://www.FreeToReSale.com/affiliate.html 
=======================================
Want Something To Do? Check Out These offers!

=======================================
Place Your Ad Here for 30 Days Only $5.00
***********************************************************
                      Featured Advertiser
-----------------------------------------------------------------------
Get Results with GUARANTEED REFERRALS for
your favorite affiliate program! You could earn a lot 
of money with us! http://TasiasPaidLinks.com
----------------------------------------------------------------------
***********************************************************
-Free Business Cards Just For You! To get your free 
business cards <A HREF="http://service.bfast.com/bfast/click?bfmid=26298982&siteid=38084229&bfpage=trackingforvp1">click here</A>! 
***********************************************************
-Do you need or want to accept credit cards for your 
business or auctions? How would you like to accept 
them for free? Send a blank email to pay...@se...
today for a list of free merchant accounts!
***********************************************************