Re: Cgi permission Questions
- Original Message - From: "Joe Bifano" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 21, 2002 8:26 PM Subject: Cgi permission Questions > Hi all, > > My first time on the list. I have been looking at the archives but am not > able to find anything on this. > > I have 3 web servers, 1 development/nfs server and 2 database mysql servers > in a cluster server farm. All sites are owned by our company so nobody will > be on the system except for me. It is behind a firewall and a load-balancer > so it is pretty secure. > > I have several domains set up on the site called test.company.com, > demo.company.com, stage.company.com and company.com. company.com is only on > the 3 web servers and all the rest is on the development server. > > I have 2 employees that will be setting up a couple of things using a cgi > script called create.pl on test.company.com. When this script is run it has > to create new test companies or demo companies. > > Here is the problem: create.pl is owned by test and group test and has file > permissions 755. When the create.pl script is run it becomes owner apache > and group apache and has to create new files and directories on the machine. > All of the new files and directories then become owner apache and group > apace. I need them to stay as owner test and group test. Ummm I'm not completly sure, but if you activate the suid on create.pl, then create.pl will be executed as test and not as apache. And I think all files create.pl creates, also will own test:test chmod u+s create.pl that command will give create.pl the suid. > > I have used SuExec before and know that it will call create.pl and then > become owner test rather than owner apache but would like to know if there > was a different way to do this. The main reason for me not wanting to use > SuExec is because I want to learn and implement mod_perl and HTML::MASON for > this site down the road. > > Thanks for you reply's in advance. > > Joe > >
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Ged Haywood [mailto:[EMAIL PROTECTED]] > Enviado el: miercoles, 16 de enero de 2002 23:30 > Para: Oscar Serrano > CC: [EMAIL PROTECTED] > Asunto: Re: weird problem. Lost of the POST data Thank you Ged for your detailled information. I'm now debugging my scripts. I'm still not sure if the problem is in the way I code, in CGI.pm or in the Template Toolkit. Thank you very much. > > Hi Oscar, > > On Wed, 16 Jan 2002, Oscar Serrano wrote: > > > So, one mod_perl CGi can cache several modules and several > mod_perl cgis? > > It's not really a "mod_perl CGI", it's an Apache child process with > its own built-in (persistent) Perl interpreter. In that sense it's an > ordinary copy of the Perl interpreter which can load whatever Perl > modules you have the memory for. The child sits around waiting for > something to do. You give it something to do by handing a request to > Apache (usually from a browser) which may or may not be configured to > cause the Perl interpreter to do something with it. If it does > something with the request it may change things inside the memory > pages of that child's Perl interpreter which aren't changed in the > interpreters of any of the other apache children. > > > Apache::Registry which I'm interested in. > > Apache::Registry provides the Apache+mod_perl process with an environment > similar to what you see when you use mod_cgi in an ordinary (non-mod_perl) > process. But it's only similar, it's not identical. There are all sorts > of things (mentioned in the Guide) that you have to look out for, mostly > because it's only similar and because the Perl interpreter is persistent. > There are alternatives to Apache::Registry which might be better for you, > but none provides an exact replica of the CGI environment. > > > So the maximum size the httpd can grow is the size of all modules and > > mod_perl cgis cached in memory. Am I right? > > Not quite, there are reasons for example why the child might grow > without bound. It's covered in the Guide in great detail, including > methods of calculating the process sizes and ways of dealing with > any processes which misbehave. > > > print "Content-type: text/html\nPragma: no-cache\n\n"; > > $query=new CGI; > > $in=$query->Vars(); > > > > Now I have everything in $in. > > To be sure of it, why not print everything in $in to the error_log or > something like that? (There's a whole chapter on debugging techniques > in the Guide. :) > > > 501 Apache Error? > > In a properly written program, the ideal would be that no request > could cause a server error. I suspect that there's something wrong > with the way your code handles the request or (less likely) there's > something wrong with the build of the server. > > 73, > Ged. > >
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Enviado el: jueves, 17 de enero de 2002 0:06 > Para: [EMAIL PROTECTED]; Oscar Serrano > Asunto: Re: weird problem. Lost of the POST data > > > > There is something that may give a clue. When I restart apache, it takes > > some minutes to throw the first error. But the error get more and more > > frecuently. But not always I get the error. It seems as if some httpd > child > > get corrupted and then, when one of those corrupted childs processes a > > request, it throws this error. > > I've seen that sort of thing before. A common cause of this is > opening some > resource before the fork that shouldn't be shared across processes, like a > file handle or a socket. Check for that. Also, are you using any cleanup > handlers? Do you have any in-house code that uses XS to call C libraries? Ummm yes... you know, I'm using the Template Toolkit. It seems as if the httpd child executes the processing of the template so fast that CGI.pm has no time to get the POST data. I has no sense, because the script, the first thing it does is the $in=$query->Vars(), and the last thing it does is to process a template. But it seems as if it could process the template before getting the POST data. And that would explain why the POST data is mantained in STDIN and then appears concatenated to the very next request: a .gif file the template calls. But I repeat, it has no sense the script processing the template before reading the POST data :-? I'm not using any cleanup handlers. Somebody suggested me to use one to destroy CGI.pm data. But, the true is that the problem is CGI.pm I'll kick CGI.pm away because I only use it to get the variables from a GET or POST data. Thank you very much. > - Perrin > >
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Robert Landrum [mailto:[EMAIL PROTECTED]] > Enviado el: jueves, 17 de enero de 2002 0:26 > Para: Oscar Serrano; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Asunto: Re: weird problem. Lost of the POST data > > > At 3:11 PM +0100 1/16/02, Oscar Serrano wrote: > >Here I put the beggining of the file: > > > >#!/usr/bin/perl -w > >use CGI; > >use strict; > >use varcomunes; #library of my own > >use lib $LIBRERIAS_AT; > >use EnlacesAT; #library of my own > >use Idioma; #library of my own > >use DBI; > >use OrdenesComunes; #library of my own > >use Template; #template toolkit 2.03 > >my ($rentafijapup, $rentafijapumm, $accionesp, $accionesmm); > >#many other my (whatever) definitions... > >my($query,$in); > > > >print "Content-type: text/html\nPragma: no-cache\n\n"; > > > >$query=new CGI; > >$in=$query->Vars(); > > > > > Check to make sure that you do not have some strange version of CGI > in $LIBRERIAS_AT. I've been bitten by this in the past when a > developer pointed some code to his home directory and had bad/debug > copied of modules in there. Thank you for your advice. But that's not my case. in $LIBRERIAS_AT I only have Idioma.pm OrdenesComunes.pm and other modules of my own. Thanks. > Rob > > -- > When I used a Mac, they laughed because I had no command prompt. When > I used Linux, they laughed because I had no GUI. >
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Enviado el: jueves, 17 de enero de 2002 1:01 > Para: Oscar Serrano; [EMAIL PROTECTED] > Asunto: Re: weird problem. Lost of the POST data > > > > Ummm yes... you know, I'm using the Template Toolkit. > > Try using the Perl stash instead of the XS stash, and see if your problem > goes away. > > > It seems as if the > > httpd child executes the processing of the template so fast that CGI.pm > has > > no time to get the POST data. > > I don't think so. It seems to me like your processes are getting > corrupted > by some C code or an improperly shared file handle or socket. I > doubt this > has anything to do with CGI.pm, since so many people use it and > don't report > having the same problem. Well all my modules are written in Perl. When you say some C code you mean the C code in DBI, or CGI or Template, don't you? I know many people uses CGI.pm but not so many with Template Toolkit and mod_perl... > > If you want to experiment, you could replace CGI.pm and see if it improves > thing for you. There are plenty of other modules you can use to > parse POST > data. Yes, I'm doing that now in some CGIs. Thank you, and you all that are helping me with this problem. Oscar Serrano. > - Perrin > >
Re: weird problem. Lost of the POST data
Hi: some days ago I wrote to ask for this problem: The CGI.pm (sometimes) could not receive the POST data. I tried all you recomended me here in the list. But I still had the problem. Finally I decide to kick out CGI.pm and start to use the old cgi-lib.pl. But I still had the same problem. Then I turnet to Apache::Request, and since I use it, I've never had the same problem. I just tell you because perphaps somebody may have the same problem. I don't really understan if the problem is in mod_perl, in Apache, in Templat Toolkit, in my ultrasecure patched kernel, in CGI.pm, but the point is that Apache::Request seems not to loose any post data :-? Thank you all. Oscar Serrano.
Re: A really strange POST problem
At 10:47 19/02/2002 +0100, Tomas Eriksson wrote:
>
> Hi.
>
> I'm not sure if this a modperl problem but I'm using modperl (5.005), Apache
> (1.3) under
> Debian on my website.
>
> Using read(STDIN, $ENV{...}, $buffer) to retrieve the post data. At several
> places i'm using
> forms with radio buttons from -2 to 2, but from some of my visitors I got
> almost randomly
> numbers in the form data xxx=13 xxx=4 etc from the radio buttons. I can read
> these wrong
> values directly in the $buffer string. This happen often if they post many
> times but seems
> to be to other visitors also.
>
Ummm, not sure, but that seems to be the classical problem of not initialicing
the variables at the beggining of the script. Mod_perl mantains a copy of the
value and each time you submit you add the new value to the existing value.
You
are getting different values each time, depending of the httpd child that
serves the script.
Are you using strict (use strict) at the beggining of the script?
Oscar Serrano.
>
> I hope I'm not the only one in the world that has this problem...
>
> kind regards
> Tomas
RE: Yahoo is moving to PHP ??
At 11:39 30/10/2002 -0500, Jesse Erlbaum wrote: Hi John -- > Quasi-seriously, as someone who has had to maintain mountains of bad > perl code, I know TMTOWTDI can have a downside; but the openness of the > language is what has lead to its greatness ... This doesn't have to be as big a problem as it often is. Having coding standards makes a big difference no matter WHICH language you use. Have you ever seen bad Java code? Java has reached parity with Perl in that area, for sure! This is a problem in ANY language. You just can't "hire smart people" and send them out there without direction. I completely agree. Bad code is bad code in any languaje (well, perhaps with perl you can write the most encrypted code, but only if you are looking for it). I don't really know the ability of PHP to work with templates, but since I discovered Template Toolkit 2, I've never written (nor will I) more web applications without it. I cannot understand why don't want them to use HTML templates. I suspect, the propietary languaje the were using was similar in concept to PHP or ASP not allowing templates. Oscar Serrano. At my company we base all our work on CGI::Application and HTML::Template to solve exactly this problem. CGI-App and HTML-Tmpl (or Template Toolkit -- TT is compatible with C::A) "strongly suggest" a standard way of writing the uninteresting bits of a web application -- namely, state management and HTML separation. They go beyond what is provided by simply making a decision to use a particular API, such as CGI, mod_perl, PHP, Mason, etc. No software library will factor this problem out entirely. This is really a human problem -- not a software problem. However, choosing a specific tactic is a good start. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
