Re: load balancing on apache
On Fri, 14 Dec 2001, Perrin Harkins wrote: > > I _really_ hate so-called dedicated boxes. They're closed, nasty, > > inflexible and often don't work in _your_ situation. Doing smart > > session-based redirection can be hard with these boxes. > > You can make it work with homegrown solutions, but I've found the dedicated > load-balancing tools (at least Big/IP) to be effective and fairly easy to > work with, even with large loads, failover requirements, and more exotic > stuff like sticky sessions. This is one area where the problem seems to be > well enough defined for most people to use an off-the-shelf solution. > They're often more expensive than they should be, but if you don't have > someone on hand who knows the ipchains or LVS stuff it can save you some > time and trouble. I couldn't agree more. In terms of managability and scalability, the various software solutions simply add complexity to something that is already so. I've got some experience with Alteon AceDirectors and even though they seem little flakey at times, you do end up with true load balacing. (We have Cisco's solution deployed and they periodically have issues too.) DNS round-robin should be avoided at all costs. It's half-assed at best. In the case of a failure those clients that have that IP cached are SOL. On some of the systems that I've deployed we have a frontend proxy on the same box as the mod_perl with the mod_perl server listening on 127.0.0.1. This is behind an Alteon (or 2). You can put the proxy on a separate box as well but (I've seen some odd problems with TCP connections not working in this situation which I never fully understood but may have had to do with the Alteon being flakey.) Anyway, my advice is to go with a hardware load balancer/intelligent IP switch. In the long term, it will pay for itself in the time recovered from *not* being spent on troubleshooting complex problems. --Jeff -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, Historical Review of Pennsylvania, 1759.
Re: DBI connections build up..
On Thu, 13 Sep 2001, DJ (David J Radunz) wrote:
> use strict;
> use vars ($dbh);
You don't need this with Apache::DBI. Globals in general should be
avoided/used with extreme caution.
> use mod_perl;
Don't need this either.
> 1;
> END {
> $dbh->disconnect;
> }
Put this before the '1;' or just don't use it.
Read the guide front to back: http://perl.apache.org/guide/
HTH.
Jeff
--
Jeff Beard
___
Web:www.cyberxape.com
Email: jeff at cyberxape dot com
Earth: Boulder, CO, USA
Re: Children dying
I've got the same configuration and it's working fine. No seg faults unless I cause'em. If nothing else is giving you adequate information, you can always remove code until it works. Not very elegant but it works consistently. --Jeff On Tue, 14 Aug 2001, darren chamberlain wrote: > Aleksandr Vladimirskiy <[EMAIL PROTECTED]> said something to this effect on >08/14/2001: > >I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. > >I get the following error in my logs: > > perl 5.6.0 has DynaLoader bug that minifests itself under > mod_perl. Upgrade to 5.6.1, downgrade to 5.00503, or wait for > 5.8.0 to fix the bug. > > (darren) > > -- Jeff Beard ___ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Re: Unexpected PATHINFO behavior under SSL
On Wed, 21 Feb 2001, Ask Bjoern Hansen wrote: > is this under Apache::Registry? Nope. It's a content handler. > Does it happen on with SSL connections or with both SSL connections > and normal connections when Raven SSL is loaded/compiled in? If the > latter then I would suspect that Raven SSL is patching something > funny into Apache. (I've never tried Raven SSL. I use mod_ssl for > SSL in Apache). Both. I prefer to use mod_ssl too but I have other folks that manage certificates and such at work. > In any case, you might have more luck with Covalent's support. Yep. Thanks, Jeff -- Jeff Beard ___ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Unexpected PATHINFO behavior under SSL
Hi there, This may be offtopic-ish but I'm hoping for some forbearance. This has ruined a perfectly good day. :) I have an application that gets it state information from PATHINFO. Runs fine without SSL but I setup a test env using Raven SSL then PATHINFO, and SCRIPT_NAME, start returning different data. For instance the program handler would be called /foo and I'll add /bar to the path to trigger a behavior. Under SSL, the SCRIPT_NAME is set to /foo/bar and PATHINFO is empty. Without SSL, SCRIPT_NAME is /foo and PATHINFO is bar. This is Apache 1.3.12, mod_perl 1.24, Raven 1.5.3 on RH Linux 6.2. mod_perl was built with EVERYTHING=1. All modules were statically built. Perl 5.00503. Ideas? TIA, Jeff -- Jeff Beard ___ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Re: Help with configuration - Linux/Mandrake 7.2
Maybe: ... I think there's some documentation on this issue as well. --Jeff On Sun, 18 Feb 2001, Rich Feather wrote: > I'm trying to get my Apache Web Server to read *.pl files using mod_perl > (standard Linux-Mandrake 7.2). Under perl, it works fine and, indeed, in > httpd-perl.conf, it shows > > Alias perl /var/www/perl > > SetHandler perl-script > PerlHandler Apache::Registry > PerlSendHeader On > Options ExecCGI -Indexes > > > Also, I've tried up the following > > > SetHandler perl-script > PerlHandler Apache::Registry > PerlSendHeader On > Options ExecCGI -Indexes > > > and/or > > > SetHandler perl-script > PerlHandler Apache::Registry > Options ExecCGI > > > Restarted after each change > /etc/rc.d/init.d/httpd restart > > ...but I cannot get the server to parse *.pl files using mod_perl. > > Any ideas? > > Thanks. > -- Jeff Beard ___ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Re: Apache::Registry, mod_perl interface, and post data
On Fri, 16 Feb 2001, Andrew Ho wrote: > Hello, > > JB>I added a button and push it. It works. ;) > > Urgh, I had a button on my actual test page; it just magically disappeared > when I retyped it in the e-mail. > I don't think the problem is with what you posted. I tried your snippets on two different systems and they worked as expects. What's your config look like? Do you get the 'Post = ()' output from the Registry script? Are you running any other software that might interfere? --Jeff -- Jeff Beard ___ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Re: Apache::Registry, mod_perl interface, and post data
On Fri, 16 Feb 2001, Andrew Ho wrote: > > > > I added a button and push it. It works. ;) --Jeff -- Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Re: Send a cookie, AND a redirect ?
Read the POD docs for Apache under the heading 'Setting up the response';
--Jeff
On Thu, 8 Feb 2001, Harrison wrote:
> Dear All.
>
> I can set a cooke fine using:
>
> $r->content_type('text/html');
> $r->header_out('Set-Cookie' =>$cookie);
> $r->send_http_header;
>
> And i can also send a redirect fine using:
>
> $r->content_type('text/html');
> $r->header_out('Location'=>$the_url);
> return REDIRECT;
>
> BUT!
>
> how do i do both? if i use my redirect code, and add an extra header_out , the
>cookie is not sent (because i have not called send_http_header ? ).
>
> If i add send_http_header, i see the full sent http_header in my browser.
>
> My idea was to have something like
>
> $r->content_type('text/html');
> $r->header_out('Location'=>$the_url);
> $r->header_out('Set-Cookie' =>$cookie);
> $r->send_http_header;
> return REDIRECT;
>
>
> Which does not work.
>
> Thinking about it whilst typing this email, does header_out have a field where i can
>set the REDIRECT status?
>
> Thanks in advance,
>
> Richard Harrison.
>
--
Jeff Beard
_
Web:www.cyberxape.com
Email: jeff at cyberxape dot com
Earth: Boulder, CO, USA
Re: mod-perl on Solaris 2.6
Check out the mailing list archive for something I posted a while back. It boiled down to not using GNU binutils for anything. Including GCC. --Jeff -- Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA On Mon, 8 Jan 2001, Siddhartha Jain wrote: > Hi, > > I have been trying to compile mod-perl (various 1.21 to 1.24_01 ) on Solaris > 2.6 with apache (various 1.3.11 to 1.3.14) with perl-5.005003 and also > perl-5.6. If i compile it statically, i get a core dump on running apache > and if i compile it via apxs, i get a "Symbol not found main, in libperl.so" > error. I had compiled perl-5.6 using Solaris's malloc and later i compiled > perl-5.005 with perl's malloc but nothing helped. I am mostly at my wits > ends having tried all sorts of combinations. Could someone help me? > > Siddhartha Jain >
Re: persistent database problem
Are using Apache::DBI and establishing a connection in
your startup.pl?
On Mon, 23 Oct 2000, Differentiated Software Solutions Pvt. Ltd wrote:
> Hi,
> I have started with one httpd; and executed the following mod-perl program from
>the browser. We've configured apache to have persistent DBI
> The idea is first time the database handle will be inactive and it will print
>'INSIDE'. From the second time onwards the database handle will be active and it
>will print 'OUTSIDE'. This is working.
> But, sometimes the 'OUTSIDE' comes from the third or fourth time only. (that is
>it takes more than one attempt to become persistent) Why it is happening like this?
> Thanks
> Muthu S Ganesh
>
> mod-perl code is here:
>
> $rc = $dbh_pg->{Active};
> print "$$: $rc\n";
> if($rc eq '')
> {
> print "INSIDE\n";
> $dbh_pg =
>DBI->connect("dbi:Pg:dbname=adcept_smg_ctrl","postgres","postgres",{RaiseError => 1})
>|| die $DBI::errstr;
> }
> else
> {
> print "OUTSIDE\n";
> }
>
>
> Differentiated Software Solutions Pvt. Ltd.
> 176, Ground Floor, 6th Main,
> 2nd Block, RT Nagar
> Bangalore - 560032
> Phone : 91 80 3431470
> www.diffs-india.com
>
--
Jeff Beard
___
Web:www.cyberxape.com
Location: Boulder, CO, USA
Re: Apache trouble reading in large cookie contents
There are techniques in the Eagle book for storing data in a cookie. (Check out the discussion on maintaining state) However, in my experience, you'll do better in the long run using something like Apache::Session. It'll be a scalable solution. --Jeff On Fri, 20 Oct 2000, Biggs, Jody wrote: > I'm having trouble when a browser sends a fair sized amount of data to > Apache as cookies - say around 8k. > > I know that most clients will not allow cookies greater than 4k per cookie > (and often no more than 20 per hostname), and as such have broken the cookie > being sent out to be sent in smaller chunks, with names such as 'Cookie0', > 'Cookie1', 'Cookie2', etc., which I would later concatenate back together to > obtain the full data that I had originally sent out. > > However, when the browser sends data back to Apache, it sends all the > cookies on the same header line (Cookie: Cookie0=...; Cookie1=...; > Cookie2=...) and so on. Apache then complains (and fails the request) with > a message of the sort: > [date] [error] [client 1.2.3.4] request failed: error reading the headers > > and spits out an error screen to the user with essentially the same message, > but including the "Cookie:" line > > I assume this is due to a compile time directive to Apache specifying the > maximum size of a header line. > > Has anyone else run into this problem, and if so, could you point me in the > right direction? > > Sorry if this seems to be a bit more of an Apache question than mod_perl. > > Thanks - > Jody Biggs >
Re: Apache 1.3.14 and Mod_Perl
Here's what I would do: Remove the rpm version of apache: # rpm -e If you want to use the start up files that are part of that package just copy them some where since they'll be removed. Build the source version following the directions in the mod_perl document called INSTALL.apaci under the heading "The flexible way". Unless you have a specific reason for it, I wouldn't bother with building it as a DSO. It's usually not a problem on Linux but it adds a level of complexity. I used mod_perl 1.24_01 with Apache 1.3.14 last time and had no problems with the build. --Jeff On Mon, 16 Oct 2000, Annette wrote: > I am new to Apache and Mod_Perl and I have a question. > > I am running Red Hat 6.0 on an Intel machine. > I loaded the Server setup. > Apache 1.3.6 is loaded and runs fine. I was able to load and run Mod_Perl RMS >package from Red Hat as DSO. > > I want to upgrade to Apache 1.3.14 and latest version of Mod_Perl. > Here are the steps I took to load Apache 1.3.14. > > /etc/rc.d/init.d/httpd stop > I downloaded Apache_1.3.14.tar.gz to the /usr/src directory > tar zvxf apache_1.3.14.tar.gz > ./configure --prefix=/usr/local/apache > make > make install > /usr/local/apache/bin/apachectl start > > I verified that Apache 1.3.14 is now running. > > How do I install the latest version of Mod_Perl? Every time I try to install it I >receive a message stating I need Apache 1.3.0 and then it aborts. > I tried Mod_Perl version 1.19, 1.21, and 1.24 and I receive the same error. > > Any input would be appreciated and I hope this is the right address to send my >question. > > Ann. >
Re: can't build with 1.3.14 apache?
FWIW, I compiled it on Linux with mod_perl 1.24_01 with no problems. I use the method descibed in INSTALL.apaci under the heading "The flexible way". --Jeff On Sat, 14 Oct 2000, Jeremy Hansen wrote: > > For some reason mod_perl-1.24 is failing to configure with apache 1.3.14: > > srv2:/usr/webservers/src/mod_perl-1.24# perl Makefile.PL > APACHE_SRC=../apache_1.3.14/src EVERYTHING=1 DO_HTTPD=0 > Enter `q' to stop search > Please tell me where I can find your apache src > [../apache_1.3.14/src] > Configure mod_perl with ../apache_1.3.14/src ? [y] > Shall I build httpd in ../apache_1.3.14/src for you? [y] > Appending mod_perl to src/Configuration > Using config file: /usr/webservers/src/mod_perl-1.24/src/Configuration > Creating Makefile > + configured for Linux platform > + setting C compiler to gcc > + setting C pre-processor to gcc -E > + checking for system header files > + adding selected modules > + checking sizeof various data types > + doing sanity check on compiler and options > Creating Makefile in support > Creating Makefile in regex > Creating Makefile in os/unix > Creating Makefile in ap > Creating Makefile in main > Creating Makefile in lib/expat-lite > Creating Makefile in modules/standard > EXTRA_CFLAGS: -DLINUX=2 -DUSE_HSREGEX -DUSE_EXPAT > -I$(SRCDIR)/lib/expat-lite -DNO_DL_NEEDED > * WARNING * > > Apache Version 1.3.0 required, aborting... > > * WARNING * > > > Any hints on how to fix this? > > Thanks > -jeremy > -- > mummy, n.: > An Egyptian who was pressed for time. > >
Re: Migrating from CGI.pm to (...?), was Re: CGI.pm problem
Ah, so there is. I grep'd an older version which didn't since I'd never heard of it before. You use Apache::Request to get query parameters the same way you do with CGI.pm's param() method. perldoc Apache::Request. Did you could try just importing the CGI.pm HTML functions? Personally, I prefer Template Toolkit for HTML generation. There are other templating systems too. Search the archives for discussions on the subject. Or as Stas suggested, check out the version 3 beta. I've been using it on my personal web server for a few months with no problems, though I don't use any of the HTML generation features. --Jeff At 10:32 AM 8/30/00 +0400, Alexei V. Barantsev wrote: >Jeff Beard <[EMAIL PROTECTED]> writes: > > > There isn't a Vars() function in CGI.pm. If you're looking for the query > > string try param(). Or if you want to make it a mod_perl program (which is > > what you would normally discuss on this list) Apache::Request::param(). > > > > --Jeff > >There is such a function, Jeff! > >Well, could you advice, how to migrate from CGI.pm to Apache or >Apache::Request. The matter is that I have used CGI.pm for HTML >generation primarily and ready to use something another to analyze >request parameters. But I cannot use CGI and e.g Apache::Request >simultaneousely - server hangs. Is there some CGI.pm replacement >intended only for HTML generation in the same manner (which does >nothing with request, especially POST request)? > >-- >ab >ICQ: 3959207 Jeff Beard __ Web:www.cyberxape.com Email: jeff at cyberxape dot com Location: Boulder, Colorado, USA
Re: CGI.pm problem
There isn't a Vars() function in CGI.pm. If you're looking for the query string try param(). Or if you want to make it a mod_perl program (which is what you would normally discuss on this list) Apache::Request::param(). --Jeff At 04:11 PM 8/29/00 +0400, Alexei V. Barantsev wrote: > Dear mod_perl'ers! > >I have found strange difference between object and func modes of CGI >library. More precisely - I have a problem with Vars function. > >Let me show an example: > >#!/usr/bin/perl -w > >use Data::Dumper; > >use CGI; >my $q = new CGI; >my $args = $q->Vars; >#use CGI qw(:standard :cgi-lib); >#my $args = Vars; > >print > header, > start_html, > p( Dumper( $args ) ), > start_form( -method => "POST", -action => "/~barancev/cgi-perl/test.pl" ), > textfield( -name => "name", -size => 50 ), > submit( -name => "submit", -value => "Submit" ), submit( -name => > "cancel", -value => "Cancel" ), > end_form, > end_html; > >All works ok, when I click button I see what button was pressed and >what string was entered. > >But if I try functional way instead (commented in example) I see that >$args is empty! In single-process mode (httpd -X) both examples work >right. Why? > >(BTW, both examples was tried on clean, just started Apache) > >-- >ab >ICQ: 3959207 Jeff Beard __ Web:www.cyberxape.com Email: jeff at cyberxape dot com Location: Boulder, Colorado, USA
Re: Getting data from external URL
I just wrote a function yesterday that uses IO::Socket to interact with an
outside CGI program. It appears to work the way I want but this is my first
foray into writing TCP client code.
It's basically this:
sub tcp_client {
my ( $rhost, $rport, $query_string ) = @_;
my $socket = IO::Socket::INET->new( PerrAddr => $rhost,
PeerPort => $rport,
Proto=> "tcp",
Type => SOCK_STREAM)
or die "Couldn't connect to $rhost:$rport : $!\n";
print $socket "GET /programname?$query_string\n";
my $response;
while ( <$socket> ) { $response .= $_ }
close($socket);
return \$answer;
}
--Jeff
At 06:58 AM 8/28/00 -0400, Steve Reppucci wrote:
>Just a word of warning: LWP::Simple doesn't follow redirects (at least,
>the last I checked, not sure if it's been changed in the 3 or 4
>months since I've last used it...), so you need to be certain that you're
>using it in a context where you're fetching something that won't return a
>redirect.
>
>HTH...
>
>On Sat, 26 Aug 2000, Stas Bekman wrote:
>
> > On Sat, 26 Aug 2000, Rodney Broom wrote:
> >
> > > OK, lots of banter...
> > >
> > > Hey V, if you are on a *NIX system, then this is a fast way:
> > >
> > > open U, "lynx -source www.some.url.dom |";
> > > $data = join '', ;
> > >
> > > There, you're finished. Admittedly, this isn't terribly efficiant,
> but it works
> > > just fine and has short devel time.
> >
> > This one is much more efficient and requires even less coding:
> >
> > use LWP::Simple;
> > $content = get("http://www.sn.no/")
> >
> > And it doesn't require you to be on any particular OS, as far as I know.
> >
> > see perldoc LWP::Simple and as advised by many others LWP::UserAgent for
> > more advanced uses.
>
>
>=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
>Steve Reppucci [EMAIL PROTECTED] |
>Logical Choice Software http://logsoft.com/ |
>508/958-0183 Be Open |
Jeff Beard
__
Web:www.cyberxape.com
Email: jeff at cyberxape dot com
Location: Boulder, Colorado, USA
Re: Caching data from db
Thanks gentlemen. I thought I was correct about the behavior of my code. However, Informix uses system authentication routines and we won't allow root (the user running httpd at that point) to login remotely. Time for an expedient hack I guess. Regards, Jeff On 28 Jul 2000, David Hodgkinson wrote: > > Perrin Harkins <[EMAIL PROTECTED]> writes: > > > On Thu, 27 Jul 2000, Jeff Beard wrote: > > > I have a couple of package globals that I'd like to populate with > > > information from a database when I fire up the web server > > [...] > > > I thought it might be as simple a declaring the variables and > > > populating them the first run of the program but that's no good. > > > > That should work, but you have to do it before the fork (i.e. in > > startup.pl or something called from it) and you have to make the variables > > globals not lexicals. > > And make sure you don't try to re-use the database handle in the > daughter Apache processes... > > -- > Dave Hodgkinson, http://www.hodgkinson.org > Editor-in-chief, The Highway Star http://www.deep-purple.com > Apache, mod_perl, MySQL, Sybase hired gun for, well, hire > - >
Caching data from db
Hi there, I have a couple of package globals that I'd like to populate with information from a database when I fire up the web server in order to take advantage of memory sharing (they'll be used every time the program runs and I don't want to run a db query every time). I thought it might be as simple a declaring the variables and populating them the first run of the program but that's no good. I also thought that I could just run a separate query against the db from startup.pl but that fails because the user the connection is defaulting to is root even though I've specified username and password. Anybody have some advice or techniques? FYI: RH Linux 6.2 Apache 1.3.12 mod_perl 1.24 DBD::Informix 1.00 Informix 9.20 TIA, Jeff
RE: Help needed for using Apache::DBI
Perhaps sending your startup.pl might help.
Then only time I had problems with Apache::DBI, I loaded Apache.pm in a
BEGIN{} block then everything else after and outside the block in my
startup.pl. That was to deal with an error when Apache::DBI was loaded.
--Jeff
At 10:28 AM 7/18/00 +0530, PHANI MADHAVI wrote:
>Hi,
>All the guidelines given in the guide have been followed.
>Specifically, there is a section which goes by the title ' my apache does
>not work '
>
>{
>
>Make sure you have it installed.
>
>Make sure you configured mod_perl with EVERYTHING=1.
>
>Use the example script eg/startup.pl (in the mod_perl distribution). Remove
>the comment from the line.
>
> # use Apache::DebugDBI;
>
>
>
>and adapt the connect string. Do not change anything in your scripts for use
>with Apache::DBI.
>}
>
>we have gone through all the guidelines
>But it is not working. It is still trying to search the 'module' in
>Apache.pm which obviously is not defined.
>
>Madhavi
>
>
>-Original Message-
>From: darren chamberlain [mailto:[EMAIL PROTECTED]]
>Sent: Monday, July 17, 2000 5:52 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Help needed for using Apache::DBI
>
>
>PHANI MADHAVI ([EMAIL PROTECTED]) said something to this effect:
> > IF AT ALL ANYBODY KNOWS HOW TO MAKE APACHE::DBI WORK,PLEASE HELP
>
>The guide is quite clear on how to use and set up Apache::DBI:
>
>http://perl.apache.org/guide/databases.html#Apache_DBI_Initiate_a_persist
>http://search.cpan.org/doc/MERGL/ApacheDBI-0.87/DBI.pm
>
Jeff Beard
__
Web:www.cyberxape.com
Email: jeff at cyberxape dot com
Location: Boulder, Colorado, USA
Re: Header Sending Bug?
I don't see a problem with this but maybe I'm missing your point. :) If PerlSendHeader is set to "On", you don't have to send a header in your program. If you want to retain control of when the header is sent, set PerlSendHeader to "Off" and do it yourself. --Jeff At 12:53 AM 5/14/00, David E. Weekly wrote: >Hello all. I've looked in various mod_perl FAQs but haven't seen the >answer to what seems to be a (minor) bug in Apache::Registry. > >It seems that when PerlSendHeader is On if I haven't yet done a >print "Content-type: text/html\n\n" > >but I want to print a comment into the weblog by doing a >print STDERR "I got value $value.\n" > >It seem Apache::Registry will go ahead and print out the default >headers, causing my "Content-type: text/html" to show up ad verbatim >on the rendered page: not the desired effect! > >While I understand that it would make sense for Apache::Registry >to print out the headers if I start spewing out text to STDOUT, >it is, IMHO, not a good behavior for it to do the same when I write >to STDERR. > >Has this been reported like a kajillion times (in which case someone >will politely reach their virtual hand out and smack me upside the >head) or is this a sufficiently out-of-the-way sort of error that >people haven't reported it yet? At any rate, I'd just be tickled >pink if someone fixed it. > > Yours, > David Weekly Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: Apache::DBI->connect_on_init in BEGIN?
I guess I don't know enough about your specific case. :)
On the systems I work on, I use "PerlRequire startup.pl" prior to loading
anything else so that I can use the connection in subsequent code. Seems to
work out fine for what I'm doing.
--Jeff
At 05:30 PM 5/14/00, svante sörmark wrote:
>yeah, i know about startup.pl, and i have been using it until now,
>but the goal here was to avoid having to put the same configuration
>in two different files :).
>
>Jeff Beard wrote:
> >
> > Checkout the sample startup.pl that comes with Apache::DBI.
> >
> > --Jeff
> >
> > At 05:08 PM 5/14/00, svante sörmark wrote:
> > >hi all,
> > >
> > >what i'd like to do is "pre-initialize" my DBI connections from whithin
> > >my PerlHandler's BEGIN block.
> > >
> > >something like this:
> > >BEGIN {
> > > if ( Apache->dir_config('CONNECT_ON_INIT') {
> > >
> Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
> > > }
> > >}
> > >
> > >but of course the Apache* stuff isn't available at this stage...
> > >
> > >does anyone have a clever solution to this? i've resorted to `grep`ing
> > >httpd.conf for the DBI_INFO string, but that is sooo ugly.
> > >
> > >thanks.
> > >--
> > >
> > >Svante Sörmark | Chalmers University IT systems & services | 031-7728665
> > >
> >
> > Jeff Beard
> > _
> > Web:www.cyberxape.com
> > Email: jeff at cyberxape.com
> > Location: Boulder, CO, USA
>
>--
>
>Svante Sörmark | Chalmers University IT systems & services | 031-7728665
>
Jeff Beard
_
Web:www.cyberxape.com
Email: jeff at cyberxape.com
Location: Boulder, CO, USA
Re: Apache::DBI->connect_on_init in BEGIN?
Checkout the sample startup.pl that comes with Apache::DBI.
--Jeff
At 05:08 PM 5/14/00, svante sörmark wrote:
>hi all,
>
>what i'd like to do is "pre-initialize" my DBI connections from whithin
>my PerlHandler's BEGIN block.
>
>something like this:
>BEGIN {
> if ( Apache->dir_config('CONNECT_ON_INIT') {
> Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
> }
>}
>
>but of course the Apache* stuff isn't available at this stage...
>
>does anyone have a clever solution to this? i've resorted to `grep`ing
>httpd.conf for the DBI_INFO string, but that is sooo ugly.
>
>thanks.
>--
>
>Svante Sörmark | Chalmers University IT systems & services | 031-7728665
>
Jeff Beard
_
Web:www.cyberxape.com
Email: jeff at cyberxape.com
Location: Boulder, CO, USA
Re: Best approach for loading several modules
Checkout Apache::RegistryLoader. --Jeff At 02:23 PM 5/11/00, Martin Wood wrote: >Hi there, > >Our Apache::Registry CGIs need access to a dozen or so core modules - is >there an elegant solution to loading these without seeing a dozen or so use >statements at the head of the script? (We have over 100 different CGIs that >share a common structure - it would be a nightmare maintaining a >modification to one of our standard modules if every CGI kept a list of its >own set). > >Currently we place all the use directives in one file and have a 'do >"startup.pl"' statement which is obviously very silly - but we run into >undefined subroutine / Exporter problems when using 'require "startup.pl"' > >We realise we could use the PerlRequire directive in the server >configuration to pre-load modules, yet whilst this could be ideal we don't >want to lose the flexibility in debugging our scripts from the command line >(we are still in the tentative mod_perl should we commit / shouldn't we >commit experimental stage). > >Is PerlRequire really the only solution? > >Thanks for any ideas, > >Martin > > > Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: growing processes
At 11:04 AM 5/9/00, Wim Kerkhoff wrote:
>Snip [...]
Hmmm. Well, some things to look at:
globals aren't too good (i.e. use vars qw(...) ). Best to "localize" with my();
What's the SQL statement look like?
$sth->fetchrow returns an array but I don't know off the top of my head if
it automagically becomes an array ref if assigned to a scalar.
Are you checking your return values?
Are getting any funny looking result sets? i.e., data from the last query?
That's usually the big red light indicating a big leak. There's docs on
that in the guide.
I hope you are also doing some error checking that you left out for the
example, i.e. :
$dbh->connect() or die "There was an error:",
$DBI::errstr, "\n";
You might also undef whatever variable is holding the result set when you
are done working it.
Just remember that you can use Apache::DBI to fire up a connection to the
dB when Apache starts. Any time you make a DBI->connect() call, Apache::DBI
will intercede and use it's cached handle.
Beyond these points what's here seems reasonable.
HTH.
--Jeff
>#!/usr/bin/perl -w
>
># some sample code
>use strict;
>use MyStuff;
>use vars qw ($dbh $foo $bar $sql $sth $rc);
>
>$dbh = dbConnect;
>
>sub something {
> $foo = "somevvar";
> $sth = $dbh->prepare("some sql code");
> $sth->execute();
> $bar = $sth->fetchrow();
> $sth->finish;
>}
>
>--
>
>package MyStuff;
>
>use strict;
>use DBI;
>
># export dbConnect, etc
>
>sub dbConnect {
> my $dbh = DBI->connect(args,to,dbi);
> return $dbh;
>}
>1;
># end of MyStuff;
>---
Jeff Beard
_
Web:www.cyberxape.com
Email: jeff at cyberxape.com
Location: Boulder, CO, USA
Re: growing processes
Not strange, a memory leak. You've got some bad code. If you have a program that you've been twiddling with recently, that would be the place to start looking. --Jeff At 09:34 AM 5/8/00, Wim Kerkhoff wrote: >I'm running into something kind of strange... > >On a fresh restart of apache, my processes are about 20 ~ 25 MB each, which is >about normal for mod_perl (as far as I know). However, within a few hours >(with little use except by our development team), the size is up to 40MB, and >by the end of the day up to 60, 70, even 90MB each. > >I highly doubt this is normal... Where do I start to track down the cause >of it? > >I'm using Apache::DBI and HTML::Embperl. > >Server: Apache/1.3.9 (Unix) Debian/GNU mod_perl/1.21_03-dev mod_ssl/2.4.10 >OpenSSL/0.9.4 > >Linux dev 2.2.12 #2 Thu Aug 26 11:46:26 PDT 1999 i686 unknown > >Thanks, > >Wim Kerkhoff, Software Engineer >NetMaster Networking Solutions >[EMAIL PROTECTED] Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: perl.conf file
If you'll forgive a stupid question, did you include the perl.conf in the httpd.conf: Include perl.conf I've also done this: Include perl.conf --Jeff At 06:39 PM 5/5/00, James Xie wrote: >I was trying the "Hello World" sample provided by Lincoln & Doug's book. >It says I can put location directive in the "perl.conf" file but I don't >have this file on my system. I created one according to the book but it >didn't work, the server cannot find the hello world program when I try to >access it through browser. If I put everything in the httpd.conf then the >program works fine. Is perl.conf part of Apache? > >James >[EMAIL PROTECTED] Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: Apache 1.3.12+mod_perl + mod_ssl + FP extensions
The last time I included fp extensions (a while ago) I believe I applied that patch last. Not sure that it actually matters, though. --Jeff At 06:52 PM 5/5/00, Rafael Caceres wrote: >Hi, > >I'm getting ready to setup the following combination of packages for our >webserver: >Perl 5.005 >Apache 1.3.12 >mod_perl 1.23 >mod_ssl (for Apache 1.3.12) >FP extensions (latest RTR software version, 'compatible' with Apache 1.3.12) > >Is there any particular 'appropriate' order to do patching/setup? Both >mod_ssl and the FP extensions will try to patch Apache, and I'm not sure >what's the proper order of installation. Any and all help is greatly >appreciated. > >Regards, >Rafael Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: Apache.pm failed to LOAD!
Did it pass 'make test'? And, not meaning to insult, did you run 'make install' in the mod_perl directory? --Jeff At 07:01 PM 5/3/00, Wang, Pin-Chieh wrote: >Hi, >I build the apache1.3.12 using mod_perl 1.23 on Solaris 2.6 machine, >everything looks fine and installed successfully (at least the installation >program told me so...) >But when I start httpd using apachectl start, httpd did not start within >error_log there is a message "Apache.pm failed to LOAD!" >Any one have any ideal? Thanks in advance >P C Wang Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: Can't use Apache::exit() in command-line scripts
You should post the code in question. Your message isn't very clear but if I was to guess, you're trying to run a regular ol' command line Perl script under Apache::Registry which has more than a few caveats. --Jeff At 04:00 PM 5/3/00, Franco Finstad wrote: >I have a large modperl site with modperl (CGI) scripts and command-line perl >scripts. > >My command line scripts load modules (.pm files) that use Apache::exit(). >This is giving me the following errors: > >** >Bareword "Apache::exit" not allowed while "strict subs" in use at >as/mod/Util.pm > line 546 >** > >So, how can I get the command-line scripts to run under Apache::Registry? >Adding 'use Apache;' to my command-line scripts obviously doesn't help. > >Any help is greatly appreciated. > >Here's my set up. >modperl 1.21 >Apache 1.36 >Solaris 2.7 Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: where to find info on the Apache request object
Or read chapter 9 in the Eagle book. --Jeff At 10:43 AM 4/30/00, Tobias Hoellrich wrote: >At 01:34 PM 4/30/00 -0400, Sam Carleton wrote: > >I am learning perl/mod_perl right now and have some questions. I would > >like to see all the functions that I can call on the Apache request > >object. Can anyone point me to some documentation? I didn't see a > >listing in "Writing Apache Modules in Perl and C". > > > >Sam > >try 'perldoc Apache' > >Tobias Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: Install probs.
Try this when you configure Apache: --activate-module=src/modules/perl/libperl.a But before that, read the mod_perl install doc INSTALL.apaci. --Jeff At 10:02 AM 4/28/00, Dominic Blythe wrote: >please reply to [EMAIL PROTECTED] as i'm not on the list... > >on Corel Linux (which is Debian slink)... > >I'm compiling mod_perl into apache 1.3.xx (19 i think) and all the mod_perl >make, make install goes ok. APACI ./configure is fine too, but when i make >apache, I get about a page of complaints about mod_perl, mostly of the >format "Undefined reference to mod_perl_some_function_name in mod_perl.c" >and it won't make. > >make and make test on mod_perl both complained about libwww missing, but all >the install notes said this isn't absolutely required. > >without the activate-module=src/modules/perl/mod_perl.c apache completed >make install with no probs (well it runs anyway) > >any ideas? Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: newbie help installation problems modperl/apache
At 11:07 PM 4/25/00, [EMAIL PROTECTED] wrote: > On the various lists to which I tried to get help, the silence >was deafening. Probably 'cause I was the only one that didn't see that your work supports pornographers. Oh well. --Jeff Jeff Beard ___ Web:www.cyberxape.com Phone: 303.443.9339 Location: Boulder, CO, USA
Re: adding HTTP Headers
http://www.w3.org/TR/html4/struct/global.html#edef-META Checkout the subheading on META and HTTP headers. --Jeff At 05:18 PM 4/24/00, Jaime Teng wrote: >Hi, > >As I am developing WEB Applications with Apache and modperl, >it came to my attention that there are some pages that I can >'ALLOW' the browser to cache the pages; I was able to do just >that with modperl by sending out this HTTP Header from within >the perl scripts: > >print "Cache-Control: max-age=21600\cM\cJ"; >print "Content-Type: text/html\cM\cJ\cM\cJ"; > >But how do I add something similar to static HTML pages? >On IIS4/5, there is a "CUSTOM HTTP Header" and "Content Expiration" >settings. > >Is there a similar setting with Apache? > >Jaime Jeff Beard ___ Web:www.cyberxape.com Phone: 303.443.9339 Location: Boulder, CO, USA
Re: Implementing security in CGI
At 05:36 PM 4/20/00, Differentiated Software Solutions Pvt. Ltd. wrote: >a) [...] then do we have a >security hole? Is not the user assuming that by killing the browser we are >exiting the system !! Yes there is a security risk. HTTP is an insecure protocol. You can use the ideas that have been thrown out here to do your part in making it more secure but the other part is the user's responsibility. All you can do is inform them of the risks and eschew responsibility for how they use the system. >b) Does all this mean that functionally, Apache::Session is a random number >generator with ability to store data and retrieve data associated with these >random numbers. Is this all that it does ?? Basically. >c) Most importantly for our application, We've written all the programs in >perl/CGI (not mod_perl). I've now realised my folly in not starting off with >mod_perl but the deed is done. Can I use Apache::Session or any of these >modules under plain vanilla CGI. Will this work ?? You could remove the session management from the CGI and put it in a handler. You can also use Apache::Registry to run your CGIs. From a performance standpoint, this would be preferable. You just have to be more disciplined in the way you code. And yes, Apache::Session works under regular CGI. --Jeff Jeff Beard ___ Web:www.cyberxape.com Phone: 303.443.9339 Location: Boulder, CO, USA
Re: Implementing security in CGI
At 04:27 PM 4/20/00, Gunther Birznieks wrote: >Yeah it works on all the clients, but it's a pain in the ass to do >relative URLs when manipulating PATH_INFO. So it's not necessarily >trivial to program and maintain unless you pass everything through a >monolithic CGI. > >Of course, on Apache it may be easier by using mod_rewrite to manipulate >the URL itself in cool ways. And then there's this cool technology called mod_perl that one could use to see if a cookie can be set and if not, then start twiddling PATH_INFO. :) --Jeff Jeff Beard ___ Web:www.cyberxape.com Phone: 303.443.9339 Location: Boulder, CO, USA
Re: Implementing security in CGI
This is a question for comp.infosystems.www.authoring.cgi. But since I'm here... I would check for the cookie every time a request is made. If you use Apache::Session there will be a separate session data store from the user data. Which is probably what you really want. Apache::Session will allow you to associate whatever data you like with the session id within it's own schema. If the browser is closed, the cookie will remain. You can have a logout feature but there will always be a significant percentage of users that won't bother. So limit the life of the cookie with the time value and periodically cull stale sessions on the server. --Jeff At 05:21 PM 4/19/00, Differentiated Software Solutions Pvt. Ltd. wrote: >Hi, > >My question is much more basic than that. I wanted to validate my design >ideas on a programmatic security. >I would like somebody to go through the following and tell me that I'm on >the right track. > >The idea I had was, at the time of login, I generate the session id which I >write to the cookie. >I have also tied to this session_id the user's login profile. >Every other screen checks for the cookie's existence and reads back the >session_id and gets the user's profile. I hope I'm right till then. >When the user signs out then we can delete the tied file. >Now any person who has access to the same browser will still have to login >to get to the inner pages. > >If the browser is killed without sign-out from the system, even then there's >no problem. >Next person who gets access to the browser and tries to access any inner >page will not be able to, because the cookie with the session-id does not >exist. > >Am I right ??? Please help. > >Thanks, > >Murali > >-Original Message- >From: Gunther Birznieks <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> >Date: 19 April 2000 18:44 >Subject: Re: Implementing security in CGI > > > >Apache::Session could be useful. But the session key that is generated is > >arguable not necessarily the most secure that it could be. But it is pretty > >good. > > > >I'm probably opening up a can of worms by saying this. > > > >The MD5 hash itself is relatively secure as hashes go (although SHA hash > >space could be better). But you are relying on underlying system variables > >to determine what is put into MD5 hashing in the first place -- and this > >data is not necessarily the most random-- process ID, time, memory address > >of the created hash, etc... Are a bit deterministic. rand() might be good > >if it is on a system that plugs natively into a good entropy generator on > >that machine. > > > >To get a better key, you probably end up spending more time pulling > >relatively random data sources together so key generation itself would be > >slow-- a computational tradeoff. Depends on how "secure" you really want to > >be. For most situations, Apache::Session's key generator will work fine. > > > >It also depends how long you intend the sessions to be active. Will they > >become a "token" that is used in lieu of authentication once the user has > >entered a username and password or issued a digital client certificate to > >your web site? Or will it be used after the user registers for a month+ to > >allow them to get back into your site without remember a password. > > > >-- Gunther > > > >At 01:34 PM 4/19/00 +0530, Differentiated Software Solutions Pvt. Ltd. >wrote: > >>Hi, > >> > >>We are having a site which is programmed with perl/CGI. > >>To enter the site we have a login and password. > >>After which some reports are displayed. > >> > >>I know that using cookies it is possible to secure the site. > >>Can somebody guide me on how to design and implement a cookie based > >>security. Sites and books on same will be greatly appreciated. > >> > >>Would Apache::Session be useful for this ?? > >> > >>Thanks for the help, > >> > >>Murali > >> > >>Differentiated Software Solutions Pvt. Ltd., > >>176, Gr. Floor, 6th Main > >>2nd Block RT Nagar > >>Bangalore - 560 032 > >>India > >>Ph: 91 80 3431470 > >>email : diffs+AEA-vsnl.com > >>http://www.diffs-india.com > >> > >>Differentiated Software Solutions Pvt. Ltd., > >>176, Gr. Floor, 6th Main > >>2nd Block RT Nagar > >>Bangalore - 560 032 > >>India > >>Ph: 91 80 3431470 > >>email : diffs+AEA-vsnl.com > >>http://www.diffs-india.com > > > >__ > >Gunther Birznieks ([EMAIL PROTECTED]) > >Extropia - The Web Technology Company > >http://www.extropia.com/ Jeff Beard ___ Web:www.cyberxape.com Phone: 303.443.9339 Location: Boulder, CO, USA
Re: Apache::Session beginner
Besides the pod docs there's another usage description in the guide: http://perl.apache.org/guide/modules.html#Apache_Session_Maintain_session If you're looking to use Apache::Session::DBI, then you'll need to run down the docs for you're database of choice. Cheers, Jeff At 07:43 PM 4/16/00, Tom Peer wrote: >Does anyone know any good resources for learning about Apache::Session ? > >Thanks, > >Tom Jeff Beard ___ Web:www.cyberxape.com Phone: 303.443.9339 Location: Boulder, CO, USA
Re: [RFC] Exceptions addition for the guide.
Also, checkout Graham Barr's Error.pm for an OO styled "try, throw, catch" model. Really nice for a complete OO Perl design, IMHO. --Jeff The one I use is a customized version but it's basically the OO "try, throw, catch" model that I've seen in other languages. On Sat, 8 Apr 2000, Autarch wrote: > N; charset=US-ASCII > X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > Status: U > > On Sat, 8 Apr 2000, Matt Sergeant wrote: > > > I've written a short document on exception handling for the guide, even > > though it's not particularly mod_perl specific, Stas thinks it would be a > > good addition. Take a look at it, and let me know if there is anything you > > would change before it's added: > > > > http://modperl.sergeant.org/guide/exceptions.html > > This is a good tutorial. You might want to take a look at some exception > code I wrote (ftp://ftp.urth.org/pub/, grab the Exception and StackTrace > tar balls) that lets you declare all your exception types via 'use' > statements. I think its a bit cleaner than the AUTOLOAD method you > propose as it can catch typos later on. Plus it lets you create actual > class hierarchies for your exceptions, which could be nice if you want to > create exception classes that do more stuff and then inherit from them. > > > -dave 0
Re: dumb beginner question
http://perl.apache.org/guide/performance.html#Persistent_DB_Connections
The answers to most beginner questions are in the guide as well.
--Jeff
At 05:28 PM 4/4/00, Adam Gotheridge wrote:
>I have been using zope for a while and while it is cool, I really like the
>speed/power/ease-of-use of perl so I would like to mimick some of the more
>important functions I saw in zope and I can't figure it out.
>
>One of the cool zope things was that you made one db connection object and
>then
>all database interaction referenced that connection object. If you had to
>change
>the connection string, it was in one place.
>
>How can I do something like that in modperl? I am thinking I should be able to
>just create a one-line connection string in a a file at the base of a
>site, and
>then include that file in all perl pages. That takes care of the one place to
>change it problem, but I am not getting it.
>
>Something like
>con.txt
>my $dbh ||= DBI->connect("dbi:Oracle:host=red.home.com;sid=RED", 'scott',
>'tiger') || die "Can't connect to : DBI->errstr";
>
>and then in the cgi file say somthing like:
>include(con.txt)
>
>There must be an easy way to do this!
>
>Thanks
Jeff Beard
___
Web:www.cyberxape.com
Phone: 303.443.9339
Location: Boulder, CO, USA
Re: Installation
./httpd -l will list all the mods built in. --Jeff At 08:00 PM 3/30/00, Annette wrote: >Thanks for such a quick response. I have been in the mod_perl guide before >asking the question. I learned from other mailing lists to always look in >as many documents to solve your problem before posting a question. Some >people get irritated quickly when you ask before looking. I have followed >the steps listed below and it seemed like I was not successful. How can >you tell that mod_perl was loaded successfully? I am going to re-load >RedHat linux 6 again but not load the server software. I will try the >steps below to load apache and mod_perl. Thanks for the input. > >Ann. > > % cd /usr/src > % lwp-download > ><http://www.apache.org/dist/apache_x.x.x.tar.gz>http://www.apache.org/dist/apache_x.x.x.tar.gz > % lwp-download > ><http://perl.apache.org/dist/mod_perl-x.xx.tar.gz>http://perl.apache.org/dist/mod_perl-x.xx.tar.gz > % tar xzvf apache_x.x.x.tar.gz > % tar xzvf mod_perl-x.xx.tar.gz > % cd mod_perl-x.xx > % perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \ > DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 > % make && make test && make install > % cd ../apache_x.x.x > % make install Jeff Beard ___ Web:www.cyberxape.com Phone: 303.443.9339 Location: Boulder, CO, USA
Re: www.modperl.com
The book is a for profit enterprise, where mod_perl isn't. Besides I see nothing wrong with going to different sites to get information. Have to do it anyway. Also, I think what's up there is pretty good unless the book guys want to open source the rest of the book. That'd be the best. :) Cheers, Jeff At 09:15 PM 1/30/00 +, Gunther Birznieks wrote: >The problem with requests such as these is ... well... why isn't this stuff >going into the main mod_perl guide? It seems to me that if www.modperl.com is >focused around the book, then let it be. But I personally hate going through >different sites to find the info I want. > >Another question is why www.modperl.com at all? Why not store the material as >part of the main mod_perl site? Or off of the apache site? > >I guess I am just not sure why the site which seems to be centered around the >book is its own site anyway? > >Anyway, assuming that you are interested in maintaining a separate site: why >not have an errata area so that people can quickly check and see if something >is amiss without going through the headache of troubleshooting the book. That >is, if there are any errata? > >"David M. Davisson" wrote: > > > Lincoln, > > > > You should add some examples showing safe file uploads. > > > > > > David M. Davisson > > [EMAIL PROTECTED] > > > > - Original Message - > > From: Lincoln Stein <[EMAIL PROTECTED]> > > To: Modperl list <[EMAIL PROTECTED]> > > Sent: Sunday, January 30, 2000 12:28 PM > > Subject: www.modperl.com > > > > > Hi, > > > > > > This site, which contains the examples for the "Programming Apache > > > Modules in Perl and C" book, will be going down for a couple of days > > > while I move it to a new ISP. When it comes back up I would like to > > > add a few more online examples to the site and spruce it up a bit in > > > general. Any votes on which examples you'd like to see put online? > > > > > > Lincoln > > > > > > -- > > > ==== > > > Lincoln D. Stein Cold Spring Harbor Laboratory > > > [EMAIL PROTECTED] Cold Spring Harbor, NY > > > > > > Jeff Beard ___ Web:www.cyberxape.com Phone: 303.443.9339 Location: Boulder, CO, USA
Re: APACI_ARGS=' ... '
If you're trying for a static build, I use the method described in
INSTALL.apaci under the heading "The flexible way". Just do "perldoc
INSTALL.apaci"
Cheers,
Jeff
At 02:44 PM 1/30/00 -0500, Bill Jones wrote:
>Help!
>
>I tried many variations on:
>
>perl Makefile.PL EVERYTHING=1 USE_APACI=1 APACI_ARGS='--enable-m
>odule=all'
>
>
>But, I can't get away from:
>
>===> src/modules/perl
>gcc -O -fno-strict-aliasing -I/usr/local/include -DUSE_LONG_LONG
>-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>-I/usr/local/lib/perl5/5.00563/sun4-solaris/CORE
>-DMOD_PERL_VERSION=\"1.21\" -DMOD_PERL_STRING_VERSION=\"mod_perl/1.21\"
>-I../.. -I/usr/local/lib/perl5/5.00563/sun4-solaris/CORE -I../../os/unix
>-I../../include -DSOLARIS2=260 -DMOD_PERL -DUSE_PERL_SSI
>-fno-strict-aliasing -I/usr/local/include -DUSE_LONG_LONG
>-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_EXPAT
>-I../../lib/expat-lite `../../apaci` -c mod_perl.c
>mod_perl.c: In function `perl_restart':
>mod_perl.c:333: warning: assignment makes pointer from integer without a
>cast
>mod_perl.c: In function `mod_perl_set_cwd':
>mod_perl.c:374: warning: passing arg 2 of `Perl_sv_setsv' makes pointer from
>integer without a cast
>mod_perl.c: In function `perl_handler':
>mod_perl.c:783: `PL_siggv' undeclared (first use in this function)
>mod_perl.c:783: (Each undeclared identifier is reported only once
>mod_perl.c:783: for each function it appears in.)
>mod_perl.c: In function `perl_call_handler':
>mod_perl.c:1359: warning: assignment makes pointer from integer without a
>cast
>mod_perl.c:1384: warning: initialization makes pointer from integer without
>a cast
>*** Error code 1
>make: Fatal error: Command failed for target `mod_perl.o'
>Current working directory
>/export/sneex/home/Apache/apache_1.3.9/src/modules/perl
>*** Error code 1
>make: Fatal error: Command failed for target `all'
>Current working directory /export/sneex/home/Apache/apache_1.3.9/src/modules
>*** Error code 1
>make: Fatal error: Command failed for target `subdirs'
>Current working directory /export/sneex/home/Apache/apache_1.3.9/src
>*** Error code 1
>make: Fatal error: Command failed for target `build-std'
>Current working directory /export/sneex/home/Apache/apache_1.3.9
>*** Error code 1
>make: Fatal error: Command failed for target `build'
>Current working directory /export/sneex/home/Apache/apache_1.3.9
>*** Error code 1
>make: Fatal error: Command failed for target `apaci_httpd'
>
>
>I have only been able to configure Apache with DSO support so far.
>Also, do I try to configure Apache itself from/using mod_perl?
>
>platform stuff:
>SunOS sneex 5.6 Generic_105181-15 sun4u sparc SUNW,Ultra-5_10
>GCC 2.9x
>Apache 1.3.9
>mod_perl 1.21
>
>??? Any ideas ???
>____
>Bill Jones * Systems Programmer * http://www.fccj.org/cgi/mail?sneex
>
>('> Running -
>//\ Perl, Apache, MySQL, PHP3,
>v_/_ Ultra 10, LinuxPPC, BeOS...
Jeff Beard
___
Web:www.cyberxape.com
Phone: 303.443.9339
Location: Boulder, CO, USA
Re: make test fails
First, thanks for the help. It's appreciated. The problem was my bad. I built the compiler with GNU binutils, which on Solaris is a no-no, but built Perl with the Sun tools. Once I rebuilt the compiler using the Sun tools, then rebuilt everything from scratch it worked fine. I'm posting this to the list so it's get archived in case others miss this detail as well. Thanks again. --Jeff At 09:07 AM 1/28/00 +, G.W. Haywood wrote: >Hi there, > >On Thu, 27 Jan 2000, Jeff Beard wrote: > > > running make test fails and produces the errors listed at the end of > > this message. I searched the list archives and found a posting that > > suggested rebuilding Perl with the same compiler and tools that I > > use for apache and mod_perl. So I did but it didn't fix the > > problem. I did in fact build Perl the first time with gcc 2.8.1, > > then built gcc 2.95.2 from source. But I rebuilt Perl with the new > > compiler and get the same results. > >I think the bit about using the same compiler means don't use gcc and >ztcpp, you ought to get away with 2.8 and 2.95, but it's good advice. > >You're obviously comfortable with compiling your tools, so you could >try a few more recompilations. My first try would be a static build. >It seems dynamic linking is responsible for all kinds of problems. I >built mySQL for a customer yesterday and the Perl interface wouldn't >run with dynamic linking of Msql-Mysql-modules, no matter what I did. >No problems at all with --static. > >If that fails I'd try with a minimum set of modules (just mod_perl to >start with, leave out php/mod_ssl) and work up from there to see what >(if anything) triggers it. There have been questions about Apache >1.3.11 with mod_perl. Try Apache 1.3.9? > >There are several other possibilities. Where is apache_1.3.11? I >found I had to put both the mod_perl and Apache directories in >/usr/local, i.e. /usr/local/apache_1.3.9 and /usr/local/mod_perl-1.21. >Did you delete everything before recompiling? You should. Have you >tried `make distclean'? > >Let me know how you get on. > >73, >Ged. > > > > The environment, etc. is: > > > > Solaris 2.6 on an Ultra 1 > > gcc 2.95.2 > > Sun's build tools (ld, nm, ar, etc.) > > Perl 5.005_03 > > apache 1.3.11 > > mod_perl 1.21 > > > > Other "3rd party" mods I'm including: > > php 4.0b3 > > mod_ssl 2.5.0-1.3.11 > > Jeff Beard ___ Web:www.cyberxape.com Phone: 303.443.9339 Location: Boulder, CO, USA
Re: question, blessing objects, modifying them
Check out "perldoc perltoot" under Class interface.
Cheers,
Jeff
At 01:43 PM 1/27/00 -0800, Etienne Pelaprat wrote:
>hi all,
>
>i'm starting out doing some Object Oriented programming with mod_perl
>and I define one object like this:
>
>sub new {
> my $self = shift;
> my $type = ref($self) || $self;
>
> ## bless our object into the class and return it
> return bless {
> first_name => '',
> last_name => '',
> email_address => '',
> @_
> }, $type;
>}
>
>sub AUTOLOAD {
> my $self = shift; ## grab the object we're being called on
> my $type = $self || ref($self); ## get the object type
>
>return if $AUTOLOAD =~ /^DESTROY$/;
>
> my $name = $AUTOLOAD;
>
> $name =~ s/^.*://;
>
> unless( exists $self->{$name} ) {
> croak "Error: Can't access field '$name' in object of class
>$type";
> }
>
> if (@_) {
> return $self->{$name} = shift;
> } else {
> return $self->{$name};
> }
>}
>
>## more functions ##
>
>Let's say this object is called SomePerson, and I create this object in
>one of my cgi scripts, like so (image SomePerson is part of package
>People):
>
>$some_person = People::SomePerson->new;
>
>how do I change the first_name, last_name, email_address variables?
>Would it be like this, if I'm doing it from inside the SomePerson
>object:
>
>$self->{first_name} = "Etienne";
>
>and like this from a regular cgi script:
>
>$some_person->first_name = "Etienne";
>
>or how?
>
>Thanks in advance,
>
>Etienne
Jeff Beard
___
Web:www.cyberxape.com
Phone: 303.443.9339
Location: Boulder, CO, USA
make test fails
Hi there, running make test fails and produces the errors listed at the end of this message. I searched the list archives and found a posting that suggested rebuilding Perl with the same compiler and tools that I use for apache and mod_perl. So I did but it didn't fix the problem. I did in fact build Perl the first time with gcc 2.8.1, then built gcc 2.95.2 from source. But I rebuilt Perl with the new compiler and get the same results. Any ideas, pointers, etc. in troubleshooting are appreciated. The environment, etc. is: Solaris 2.6 on an Ultra 1 gcc 2.95.2 Sun's build tools (ld, nm, ar, etc.) Perl 5.005_03 apache 1.3.11 mod_perl 1.21 Other "3rd party" mods I'm including: php 4.0b3 mod_ssl 2.5.0-1.3.11 Appended are perl -V output and the errors from make test Thanks for your help. --Jeff Perl Version: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris uname='sunos wiggy 5.6 generic sun4u sparc sunw,ultra-1 ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='gcc -B/usr/ccs/bin/ -B/usr/ccs/bin/', optimize='-O', gccversion=2.95.2 19991024 (release) cppflags='-I/usr/local/include' ccflags ='-I/usr/local/include' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='gcc -B/usr/ccs/bin/ -B/usr/ccs/bin/', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Built under solaris Compiled at Jan 23 2000 14:15:33 @INC: /usr/local/lib/perl5/5.00503/sun4-solaris /usr/local/lib/perl5/5.00503 /usr/local/lib/perl5/site_perl/5.005/sun4-solaris /usr/local/lib/perl5/site_perl/5.005 make test errors: [Thu Jan 27 13:51:41 2000] [error] Can't load '/usr/local/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so' for module IO: ld.so.1: ../apache_1.3.11/src/httpd: fatal: relocation error: file /usr/local/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so: symbol main: referenced symbol not found at /usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. Jeff Beard ___ Web:www.cyberxape.com Phone: 303.443.9339 Location: Boulder, CO, USA
Re: Intercepting CGI.pm Header
Do you have 'PerlSendHeader On' in your httpd.conf?
--Jeff
At 02:21 PM 12/6/99 +0100, Martin Holz wrote:
>I am trying to catch the output of a CGI
>script and put the body of the generated
>HTML page in a template.
>
>Works fine unless the CGI script calls CGI::header.
>If the scripts calls CGI::header, two headers
>are sent, the first by Apache::Registry/CGI.pm,
>the second by my own content handler.
>
>Aparently CGI::header does not send its output
>to STDOUT, if it runs under Apache::Registry.
>
>How can I intercept the first header?
>
>Thanks
> Martin Holz
>
>
>
>===
>
>if ($r->filename =~ /\.perl$/ ) { # Registry-Skript
>tie *SH,'IO::Scalar', \$PAGE;
>my $stdout = select SH;
>Apache::Registry::handler($r);
>select $stdout;
>} else {
> ... Static page
>}
>
>Extract body from $page and put it a template
Jeff Beard
Web Systems Engineer
World Wide Web Associates
Web: http://wwwa.com
Phone: 303.545.2399
Re: DBI/Sessions/Embperl
How 'bout this:
http://perl.apache.org/guide/performance.html#Persistent_DB_Connections
--Jeff
At 04:39 PM 11/27/99 -0500, Aaron Johnson wrote:
>I am using HTML::Embperl in conjunction with Apache::Session to control
>session information and create pages. I have started to create a module
>that will trim the amount of code and keep a connection with MySQL
>engine alive. Below is a section of my module.
> My problem is that when I connect again with a different computer my
>connect all my previous connects are changed to the last one.
>
>So in short:
>
>Can I assign each session a seperate "permanent" connection?
>
>Aaron Johnson
>
># I pass this -> $dbh = db_connect( { database => "$udat{location}",
>change => 1, } );
># for those of you who haven't used HTML::Embperl $udat{location} is
>session data
>
>sub db_connect {
> my $pd = shift;
> if ($pd->{change}) { &db_disconnect };
> if ($pd->{change} || !$dbh) {
>
> $dbh=DBI->connect(
> "dbi:mysql:$pd->{database}", 'user', 'password', {
> PrintError => 1,
> RaiseError => 1,
> }
> ) || die $DBI::errstr;
>
> return($dbh)
> }
>
> else {
> # warn "No need to change!\n";
> return($dbh)
> }
>
>}
Jeff Beard
Web Systems Engineer
World Wide Web Associates
Web: http://wwwa.com
Phone: 303.545.2399
RE: syntax error parsing httpd.conf
At the risk of irritating you by pressing the issue, I have to agree with Doug, and I've had the same problem with the exact same errors. My null device worked fine for me but the permissions were changed on it so that certain other processes couldn't use it (i.e. apache). Until I cornered the process that was changing the perms on it, I had to remove it and mknod it again. --Jeff Jeff Beard Web Systems Engineer World Wide Web Associates Web: http://wwwa.com Phone: 303.545.2399 :-Original Message- :From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On :Behalf Of Dmitry Beransky :Sent: Monday, October 04, 1999 3:48 PM :To: [EMAIL PROTECTED] :Subject: Re: syntax error parsing httpd.conf : : :Nay, my null device works just fine, but I still keep occasionally getting :these errors for most of mod_perl config directives. One additional piece :of information: it seems that every time this problem shows up, I can get :rid of it simply by rerunning apache's autoconf. : :I can't see any physical connection between the two, but then again, I :don't know much about autoconf. I would appreciate if anyone could point :out what the connection is. : :Regards :Dmitry : : :At 11:55 AM 9/21/99 , Doug MacEachern wrote: :>no, but I've seen it before, your /dev/null device is broken. :>try: :> :>% sudo echo > /dev/null :> :>On Wed, 15 Sep 1999, Dmitry Beransky wrote: :> :> > Hi, :> > :> > My apache/mod_perl combo had been running just fine until :yesterday when :> > all of a sudden (I can't recall making any changes to the setup) all :> > configuration lines containing commands Perl*Handler and PerlModule :> started :> > giving me the following error message: :> > :> > root# apachectl configtest :> > syntax error at /dev/null line 1, near "line arguments:" :> > Execution of /dev/null aborted due to compilation errors. :> > parse: Undefined error: 0 :> > :> > Any ideas what might have caused this?
