$r-path_info() getting confused
In my conf file, I have the following directives: Location /rms AuthType Apache::AuthCookieRMSDBI AuthName RMS PerlAuthenHandler Apache::AuthCookieRMSDBI-authenticate PerlAuthzHandler Apache::AuthCookieRMSDBI-authorize require valid-user /Location Location /rms/module SetHandler perl-script PerlHandler RMS::Control::Module-handler /Location When I call the URL /rms/module/foo, and in RMS::Control::Module-handler I examine $r-path_info, I get as a value '/module/foo' rather than the expected '/foo'. If apache recognized that /rms/module/foo was to go to RMS::Control::Module-handler then it knows that /rms/module is the script name and thus should know that path_info should be just /foo, right? Thanks, Fran
Re: Apache::Session HELP!
What does your config file look like? All pointing at the right tables
and fields and such?
-Fran
Rafiq Ismail (ADMIN) wrote:
Hi, I'm in major poop.
Got a presentation soon and my just implemented, implementation of
Apache::Session is not working as per the man page.
I've set commit to 1 and tied a session to a postgres database. I then
set a field and check the table it's not there.
When I later do a fetch on it, I get a scarey error:
[error] Object does not exist in the data store at
/usr/lib/perl5/site_perl/5.6.1/Apache/Session/Store/Postgres.pm line 81
Create and fetch methods, with table schema, below:
1)Create:
sub tieSession
{
my $self = shift;
my %session;
my $dsn = DBI:Pg:dbname=.$DBI_DB.;host=.$DBI_HOST;
print STDERR \n CREATING SESSION using dsn: $dsn \n;
tie %session, 'Apache::Session::Postgres', undef,
{
DataSource = $dsn,
UserName = $DBI_USER,
Password = $DBI_PWD,
Commit = 1
};
## store creation time
$session{CREATION_TIME}=time;
return \%session;
}
2) fetching the session:
sub fetchSession
{
my $self = shift;
my $sessionId = shift;
my $dsn = DBI:Pg:dbname=.$DBI_DB.;host=.$DBI_HOST;
my %session;
print STDERR \n getting session for $sessionId\n;
tie %session, 'Apache::Session::Postgres', $sessionId,
{ DataSource = $dsn,
UserName = $DBI_USER,
Password = $DBI_PWD,
Commit = 1
};
## store last access
$session{LAST_ACCESS} = time;
$ENV{GUEST_ID} = $session{GUEST_ID} || undef;
return \%session;
}
3) Table Schemata
CREATE TABLE sessions (
id char(32) not null primary key,
a_session text
);
help?
Cheers,
fiq
Re: Apache::Session HELP!
Wait, ignore that - I was getting my Apache::Session and my
Apache::AuthCookie signals crossed. Sorry.
-Fran
Fran Fabrizio wrote:
What does your config file look like? All pointing at the right
tables and fields and such?
-Fran
Rafiq Ismail (ADMIN) wrote:
Hi, I'm in major poop.
Got a presentation soon and my just implemented, implementation of
Apache::Session is not working as per the man page.
I've set commit to 1 and tied a session to a postgres database. I then
set a field and check the table it's not there.
When I later do a fetch on it, I get a scarey error:
[error] Object does not exist in the data store at
/usr/lib/perl5/site_perl/5.6.1/Apache/Session/Store/Postgres.pm line 81
Create and fetch methods, with table schema, below:
1)Create:
sub tieSession
{
my $self = shift;
my %session;
my $dsn = DBI:Pg:dbname=.$DBI_DB.;host=.$DBI_HOST;
print STDERR \n CREATING SESSION using dsn: $dsn \n;
tie %session, 'Apache::Session::Postgres', undef,
{
DataSource = $dsn,
UserName = $DBI_USER,
Password = $DBI_PWD,
Commit = 1
};
## store creation time
$session{CREATION_TIME}=time;
return \%session;
}
2) fetching the session:
sub fetchSession
{
my $self = shift;
my $sessionId = shift;
my $dsn = DBI:Pg:dbname=.$DBI_DB.;host=.$DBI_HOST;
my %session;
print STDERR \n getting session for $sessionId\n;
tie %session, 'Apache::Session::Postgres', $sessionId,
{ DataSource = $dsn,
UserName = $DBI_USER,
Password = $DBI_PWD,
Commit = 1
};
## store last access
$session{LAST_ACCESS} = time;
$ENV{GUEST_ID} = $session{GUEST_ID} || undef;
return \%session;
}
3) Table Schemata
CREATE TABLE sessions (
id char(32) not null primary key,
a_session text
);
help?
Cheers,
fiq
Re: Is mod_perl the right solution for my GUI dev?
Ron Savage wrote: On Tue, 25 Jun 2002 12:22:15 -0400, Fran Fabrizio wrote: Fran [snip] from first-hand experience, hell my current project has both of these things in a web interface, and neither were trivial. I crafted an expandable-tree menu (think Windows Explorer style menu) from HTML, CSS, JavaScript and HTML::Template. I have graphs dynamically generated Did you consider using my module CGI::Explorer? I wasn't aware of it's existence. I just now downloaded it and played with the demo. Unfortunately, it looks like it might not have helped in my case. It appears that it is doing a round trip to the server and back on every open/close of a node. That's exactly what I had to avoid. Our tree has 1000 elements (and growing) pulled dynamically out of a database. In a multi-user environment we don't want to be hitting the server that hard just for a navigational menu for every click of every user. We serve up the entire tree when the user logs in, and all of the state maintenance is handled client-side in terms of what's been opened, etc... we never go back to the server unless the user has requested a refresh of the tree. I could be wrong in how your module operates, that's just from a 3 minute session with the demo. It's good that you've made this available though, most people will have more reasonably sized and constructed trees than we do and should find that module useful. :-) -Fran PS - May want to take a look at it on Mozilla. There seemed to be slight table layout issues on my Mozilla 1.0 (yeah, I need to upgrade :-) that caused the graphics to slightly misalign.
Re: Is mod_perl the right solution for my GUI dev?
Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? No, not at all. The web is bound by HTTP and HTML. This comes with many ramifications. There are three main areas where I have and you will run into problems: - Real-time data updates. HTTP is stateless: it serves up the page then closes the connection. Any updating involves a round-trip back to the server. In traditional GUI, you just hold a db connection and repaint the areas that are updated. - State maintenance. Since it is stateless, you have to jump through a lot of hoops to realize that two requests are coming from the same person, since they could be handled by two different child processes or even two different servers. This has all sorts of ramifications on user login, user preferences, where the user was in the application, etc... you have to do a lot of work on the server side to realize that it's the same client that keeps talking to you. - Fancy interface widgets/layouts. HTML/CSS/JavaScript/DHTML can only get you so far. If you need fancy menu types, forms, layouts, etc... it quickly becomes tedious/impossible on the web. This is just the tip of the iceberg. -Fran
Re: Is mod_perl the right solution for my GUI dev?
Rob Nagler wrote: Solved with refresh? JavaScript and Java can also help here. Yes, solved with refresh. Of the entire page. Which may be quite complex and have some hefty SQL queries, etc...not to mention other issues such as network latency, the re-rendering of the page, etc...all distract from the user experience, which may or may not be an issue for the particular application. For example, I once coded an HTML-based game where you guessed movie quotes and if you got it right, you replaced it with one of your own. Two of the issues were 1. I wanted a list of who was currently playing but it quickly got out of date and to update it would mean to refresh the entire page, go to frames, or put the list in a separate window, all messy. 2. When one user correctly guessed a quote, I would have liked to have all the other users' screens update with that new info, but that's impossible without having something like a java applet embedded in the page checking for new data and forcing a refresh of the page. Yes it works, but it's messy once again. These are real issues, and issues which I have solved as best as possible on the web but that are easier in other systems. Cookies work fine. You oversimplify. Cookies do work fine. What creates, reads, modifies, validates the cookies? What ties the cookies to useful state information that is stored server-side? There's a lot of coding potentially involved. Yes, perl modules exist. Yes, they'll most likely need customization (in my case, I've customized AuthCookie, and tied it to Apache::Session. It wasn't the end of the world, but it wasn't trivia. A cookie by itself is of rather limited usefulness. Tedious is questionable. Impossible, I seriously doubt. Remember, you can always delegate part of your screen to a Java applet, although I strongly recommend you avoid this. Reinventing common widgets by coding up in HTML, CSS, JavaScript something that's a one-liner in a typical GUI environment is not tedious? I think you're oversimplifying again. As for a Java applet, a java applet ceases to be a web frontend. It's a GUI front end using the web as a communication/distribution layer. Once it's launched, you use stateful sockets to talk back to the server, etc... If you find yourself doing a majority of your interface via java applet (which is not something you want to try if cross-browser implementation is a desired feature, by the way), then you might as well make it a standalone java app, especially since you're apt to hit the applet security sandbox on any sort of robust app. There are a TON of positives to web frontends. I'm not arguing. I have made my living for the past 8 years building these things, I'm a friend of the web front end. =) You've captured the positives quite well, so I don't need to reiterate. But let's not fall into the trap of saying the web is the best tool for every front end usage imaginable. The user has said fancy menus and graphs are to be the mainstay of the app. I speak from first-hand experience, hell my current project has both of these things in a web interface, and neither were trivial. I crafted an expandable-tree menu (think Windows Explorer style menu) from HTML, CSS, JavaScript and HTML::Template. I have graphs dynamically generated using GD::Graph. Both took time, lots of trial and error, and lots of hair-pulling. Massaging the data for GD::Graph was just one chore I remember being harder than expected. These tools worked and are great tools that enable things on the web that aren't otherwise possible, but it was hard -because- it was a web app with all the inherent limitations - these things are much more native to traditional GUIs. In my case, we have a -need- to be a web app and so I'm willing to jump through hoops to make the interface richer where we need it to be, but if I was choosing between web and traditional, and I didn't -need- web, and I knew that graphs and fancy widgets were the mainstay of my app, I'd think twice before trying web. Fancy widgets especially are not that much fun to code on the web when a very robust library of them already exist for most GUI systems. Yes, it can be done (though there are still some things which I found impossible, some widgets which I don't think can be duplicated acceptably on the web. I like clicking on column headers and have them resort without doing a round-trip, for instance) but it's not much fun sometimes. That's my only point. -Fran
Re: Is mod_perl the right solution for my GUI dev?
Well it sounds like most of your design goals are pointing you towards the web interface. These same goals are what made me choose web even though I knew that I'd have to make some sacrifices on the interface. You'll be able to do it fine on the web, just be prepared to be flexible with the interface and learn to accept/work around the web's inherent limitations. Some thoughts: * GD generates graphs on the fly. I don't know which other softwares do the same. GD sits on top of C's gd library. I would like to continue in the same web front-end path for more interactive forms. May be I will have to fight with Javascript more. Yes, much more. But a book I found helpful was 'DHTML and CSS for the WWW'. It has helpful examples of various menus and widgets that can be accomplished on the web to make an interface richer. And with that, I think we've officially left the topicality of a mod_perl list. :-) Enjoy, Fran
RE: separating C from V in MVC
Ok so Collections was the missing piece in my puzzle. Very interesting (and intuitive now that you present it to me). Controller: --- my $Stale = Model::WatchCollection-new( status = 'stale' ); Controller: --- my $WC= Model::WatchCollection-new(); Out of these two, I would think that the first one is actually better. What if you have 300,000 watches and only 25 are stale, for example (numbers that are not all that far from the truth, in my case)? That'd be a lot of data I'd be slinging around in the 2nd example. Which is probably what you meant by might be better. :-) Thanks for the example code, it was very enlightening! I'll digest further at the office this morning. -Fran
Re: separating C from V in MVC
Shop demostrates how you can build a simple application with only a couple of custom SQL queries. The rest are simple joins and CRUD. If you need more complex queries, there are escapes. You still probably end up with a list of tuples for your reports. The key we have found is avoiding indirection by naming fields and models the same in SQL and Perl objects. This allows you to seamlessly switch between the two. How well does this approach work with 90 tables? How does it handle arbitrary queries that may join 1-6 tables, with conditionals and sorting of arbitrary complexity? I'd have to agree, most of the real-world scenarios I have run across do not consist of these neat 1-to-1 field to attribute type of mappings where the majority of the queries are simple inserts or selects from a single table or simple joins. Most of the apps I work on quickly evolve to the point of many (in my current case, 120+) tables and where most of the queries are gathering data for reports/views that bring data together from several tables. Joins of 5+ tables, unions, excepts, subselects, self-joins, complex sorting/grouping rules, etc are all commonplace and this is where I think overzealous attempts to abstract the queries away fall apart. I guess I'm more of the Perrin school of thought, where I prefer crafting all the SQL directly. I don't typically find apps that just mirror some subset of one of the db tables to be all that interesting. After all, it's the relationships between the data that make the data interesting, and by necessity this means your queries will be complex. And looking over the stuff outlined at poop.sourceforge.net, there's not too many models/frameworks out there that can accurately abstract ALL of SQL, and if it only does a subset, I feel like that's shooting myself in the foot. -Fran
Re: separating C from V in MVC
Ok, thanks to you all and this great discussion I want to try to make
our current project into an MVC-style app, so what now? This MVC
discussion could not have come at a better time - our little app is all
grown up now and needs a real architecture. I have read the MVC threads
in depth now, and I have questions.
WHERE WE ARE NOW
--
We have a multiuser application that has about oh, I dunno, 100
different screens to the interface. They can be roughly divided into
the following areas - status, admin, registration, reports, and graphs.
Most of the actions involve either retrieving data from a database or
processing a form and inserting into a database (in other words, it's a
very typical web application). This application started as a CGI
script. For performance reasons, we installed mod_perl and use
Apache::Registry to run it now. It's pretty much still a dumb CGI
script with a mod_perl wrapper, but I did develop a couple of modules to
do user authentication with AuthCookie-based solutions and tied that
into Apache::Session for state maintenance between requests. The CGI
script has grown to accomodate these ~ 100 actions and is now basically
a 4,000 line if statement. The script decides which request to do based
on a target= parameter passed in (in other words, target=summary or
target=doctoractivity, etc...). For sanity's sake, many months ago, we
switched to HTML::Template (our view) to define our screens, which has
worked well to date. On the back end we have PostgreSQL with a healthy
sized schema of around 150 tables or so that has ~ 350 megs of data and
on the order of 500,000 transactions a day (lots of data turnover, some
tables get UPDATEd so frequently as to have 100% data turnover within 15
minutes). Anyways, back to the perl part
Basic code structure:
[snip]
my $dbh = DBI-connect( $r-dir_config('RMSDBI_DSN') ,
$r-dir_config('RMSDBI_user') , $r-dir_config('RMSDBI_password') );
# giant if statement - closest thing I have to a controller, I suppose
if ($target = 'summary') {
my $tmpl = getTemplate('summary');
doSummary($dbh,$tmpl);
print header . $tmpl-output();
} elsif ($target = 'doctoractivity') {
my $tmpl = getTemplate('doctoractivity');
doDoctorActivity($dbh,$tmpl);
print header . $tmpl-output();
} elsif ...
[snip]
# lots of subs basically one per target, closest thing I have to a
model, I suppose
sub doSummary {
($dbh, $tmpl) = shift;
$sth = $dbh-prepare(SQL STATEMENT HARD-CODED HERE);
# process result set into hashes and arrays of hashes such as summary
that HTML::Template wants
[snip]
$tmpl-param(summary = summary);
}
sub doDoctorActivity {
($dbh, $tmpl) = shift;
$sth = $dbh-prepare(SQL STATEMENT HARD-CODED HERE);
# process result set into hashes and arrays of hashes such as summary
that HTML::Template wants
[snip]
$tmpl-param(summary = summary);
}
etc
This basic pattern repeated ad infinitum. It's grown way out of
control, is a pain to work with, and just feels wrong, very wrong. :-)
To be fair, it grew very fast and it was all we (by we I mean the two
of us that were this entire dept. back then) could do to keep up with
the feature requests, let alone worry about proper architecting of the
software. We're paying for it now, of course.
WHERE WE WANT TO BE
--
I would like to introduce some semblance of organisation, sanity,
maintainability, separation of logic, etc to this project. In other
words, MVC would be a good fit.
Some of the concrete, basic questions I have are:
1. Is there one Controller or many? Should I have one for each main
area of my site? /myapp/admin/ goes to an Admin Controller,
/myapp/reports to another controller, etc...
2. Does the first part of my code above even remotely resemble a
Controller? I mean, it takes the input, calls essentially a 'model'
object (but passing it the view object, nice, eh? =), but then seems to
break the model nicely by doing things like printing out the HTML from
the Controller, etc...
3. How do you prevent a Controller from just becoming another big if
statement, or is this their purpose in life?
4. In the case of a form, what perl structure is used to pass the data
into the model?
5. Do you create an actual class for each form?
6. Do you need to create objects at all? Is OO a prerequisite to MVC?
6.5. (thought of while proofreading :-) Is the statement there is one
set of controllers for each defined view correct? In other words, if
we someday want to output the reports section of the site as Excel
spreadsheets in addition to HTML, would we define a new set of
controllers or how would that work?
Now onto the model, I think I have a little better grasp of the model
compared to the controller, but I have questions...
7a. Is it insane to leave my SQL hard-coded in there? The queries
don't change all that much, and it's nice to have the query in
Re: RPM for apache/mod_perl/mod_ssl
In the spirit of the teach a man to fish proverb (sorry if that's a random reference), maybe I should really be asking what's involved in making such an rpm? Is it a case of just figuring out which files are installed by openssl/mod_ssl/mod_perl/apache and making a big ole spec file, or is there some configuration magic that needs to happen? If this is straying too far off-topic I'll take the discussion off-list, but I really should learn how to do this properly for myself. Thanks, Fran Christof Damian wrote: On Wed, 05 Jun 2002, fliptop wrote: i have an rpm for apache 1.3.22, mod_perl 1.26, and mod_ssl 2.8.5 that i run on redhat 6.2. i'd be glad to give you the .src (or the .rpm if you also run redhat 6.2) if you would like it. or, i could just give you the .spec if you'd like to build a new rpm with the latest versions. i got one for redhat 7.0, i am in the progress to update it to the current versions of apache/mod_perl/mod_ssl though. christof
RPM for apache/mod_perl/mod_ssl
We're currently struggling for an easy way to distribute our apache/mod_perl/mod_ssl-based application to our data center folks who are in a different state and whom we must presume know nothing about apache, mod_perl or mod_ssl and are capable of nothing more complicated than using RPM to install/update a package. As such, does there exist such a thing as an RPM that installs apache with mod_perl AND mod_ssl enabled? I presume this would also have to include openssl. I can only imagine what a pain it would be to create this beast, but if it's been done, I'd like to give it a try. I have used my limited experience with RPM to try to build this kind of thing, but so far the closest I've gotten is to have an RPM that includes the four tarballs with a shell script to compile them on the target machine. Of course this really isn't in the spirit of RPM and also, fails miserably when the target machine is a hardened machine with no compiler, for example. :-) Does such a thing exist, and what are some pros and cons of going this route? Personally, I would hate to have to rely on an RPM like this, not least because I'd have to learn how to modify it if it doesn't meet our needs, but we need to make the application install as easy as possible for the data center folks. Thoughts? Thanks, Fran
Re: RPM for apache/mod_perl/mod_ssl
Thanks Stas for that link, but none of those have mod_ssl and I'm not skilled enough with RPM to make that heavy of an adjustment, to be honest. I think I'll take a gander at fliptop's specs and see if they are close enough to do what I need. Thanks all! -Fran Stas Bekman wrote: Fran Fabrizio wrote: We're currently struggling for an easy way to distribute our apache/mod_perl/mod_ssl-based application to our data center folks who are in a different state and whom we must presume know nothing about apache, mod_perl or mod_ssl and are capable of nothing more complicated than using RPM to install/update a package. As such, does there exist such a thing as an RPM that installs apache with mod_perl AND mod_ssl enabled? I presume this would also have to include openssl. I can only imagine what a pain it would be to create this beast, but if it's been done, I'd like to give it a try. I have used my limited experience with RPM to try to build this kind of thing, but so far the closest I've gotten is to have an RPM that includes the four tarballs with a shell script to compile them on the target machine. Of course this really isn't in the spirit of RPM and also, fails miserably when the target machine is a hardened machine with no compiler, for example. :-) Does such a thing exist, and what are some pros and cons of going this route? Personally, I would hate to have to rely on an RPM like this, not least because I'd have to learn how to modify it if it doesn't meet our needs, but we need to make the application install as easy as possible for the data center folks. Thoughts? Take an existing src RPM (.spec) and adjust it the way you want. Here are some RPMs: http://perl.apache.org/release/download/binaries.html#RedHat_Linux __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: DBI Bug
And you are sure that the CGI module is installed on the machine, right? perl -e 'use CGI;' from the command-line will tell you. -Fran Udlei Nattis wrote: hi, sorry my english ;) when i add this line in httpd.conf PerlModule DBI or use DBI(); in startup.conf apache dont start, i receive this error: /usr/local/apache-2.0/bin/apachectl: line 192: 12547 Segmentation fault $HTTPD /usr/local/apache-2.0/bin/apachectl start: httpd could not be started i test it in Apache 2.0/Perl 5.8.0RC1/Modperl 1.99.02/03 Apache 2.0/Perl 5.7.3/Modperl 1.99.02/03 Apache 2.0/Perl 5.6.1/Modperl 1.99.02/03 Apache 2.0-cvs/All Perls/All Modperls :/
Re: login.pl not sending cookies via POST?
(I haven't re-tested Apache::AuthCookieDBI.) I have no idea why POST _doesn't_ work, mind you... For what it's worth, my setup with AuthCookieDBI works just fine with POST. -Fran
Re: problems setting up Apache::AuthCookieDBI (solved but no fullyunderstood)
Jacob Davies (author of Apache::AuthCookieDBI) confirmed the secret key file has to be set before the PerlModule directive, it is a bug in the documentation. Except it doesn't really, because it works fine for me. =) I compiled mod_perl static, I tend to avoid DSO if possible. -Fran
Re: problems setting up Apache::AuthCookieDBI (solved but no fullyunderstood)
I for sure), I don't understand why the order does not matter in your machine. Do we have the same version of the module (v1.18)? -- fxn Ah, no, I've got 1.10. Here is the relevant part of my config file # AuthCookieDBI config PerlModule Apache::AuthCookieDBI PerlSetVar RMSPath / PerlSetVar RMSLoginScript /rms/login PerlSetVar RMSDBI_SecretKeyFile /usr/local/apache/RMSsecretkeyfile PerlSetVar etc.. So much for backwards compatibility. ;-) -Fran
Re: problems setting up Apache::AuthCookieDBI (solved but no fullyunderstood)
Loading Apache::AuthCookieDBI after setting WhatEverDBI_SecretKeyFile has solved the problem. I am doing something wrong or the example in the manual page would need to be modified? That's odd, I load my module first before setting the secret key (or any of the other variables) and it works fine for me. -Fran
Re: problems setting up Apache::AuthCookieDBI (solved but no fullyunderstood)
Does the server load the module that way? It's beyond my expertise at this point but my experience would indicate that it does not work this way since I have PerlModule before the PerlSetVar and it works fine. -Fran
Re: Can mod_perl help me use ENV variables in httpd.conf?
What I was really looking for was $r-server_root_relative. =) Thanks
Geoff!
That's to all for your help.
-Fran
You'll also need to use a PerlPassEnv directive prior to your Perl
block.
For debug purposes, try adding the following inside your Perl block:
print join(\n, map { $_ = $ENV{$_} } (keys %ENV)), \n;
OR, my personal quick-debugging catch-all:
use Data::Dumper;
print Dumper \%ENV;
You'll be able to see what is available in %ENV when running under
mod_perl. See also Chapter 9, page 498 of the Eagle.
jason
Ken Williams wrote:
On Wednesday, May 1, 2002, at 05:04 AM, Fran Fabrizio wrote:
I spoke too soon.
I need:
Perl
push Alias, [ qw(/cgi-bin/chimpkit/ $ENV{SERVER_ROOT}/cgi-
bin/chimpkit/) ];
/Perl
This does not appear to be possible because there's no way to pass
in SERVER_ROOT to the apache startup.
I think the problem is your Perl syntax, not the value of the
variable. Scalars do not interpolate in qw() constructs. Try this
instead:
Perl
push Alias, '/cgi-bin/chimpkit/', $ENV{SERVER_ROOT}/cgi-
bin/chimpkit/;
/Perl
or even
Perl
push Alias, '/cgi-bin/chimpkit/',
$r-server_root_relative . '/cgi-bin/chimpkit/';
/Perl
-Ken
Re: problems setting up Apache::AuthCookieDBI
Do you have this in httpd.conf (or mod_perl.conf) PerlSetVar BuscaWAPDBI_SecretKeyFile /home/fxn/prj/bw/buscawap/etc/auth.key ? -Fran F.Xavier Noria wrote: I am having problems configuring Apache::AuthCookieDBI and am a bit lost, since it seems there is something wrong with the secret key file I cannot see, I attach below the configuration in case it can help. I have checked the permissions of the file (the server runs in by box as fxn): $ ls -la /home/fxn/prj/bw/buscawap/etc/auth.key -rw---1 fxn12 May 2 19:20 /home/fxn/prj/bw/buscawap/etc/auth.key If I request /docs these messages appear in error_log: [Thu May 2 20:07:19 2002] [error] access to /login failed for 127.0.0.1, reason: Apache::AuthCookieDBI: didn't have the secret key for auth realm Busc aWAP [Thu May 2 20:07:21 2002] [error] access to /docs failed for 127.0.0.1, reason: Apache::AuthCookieDBI: didn't the secret key from for auth realm Busca WAP Any hint on what could I be doing wrong? -- fxn PerlModule Apache::AuthCookieDBI PerlSetVar BuscaWAPPath / PerlSetVar BuscaWAPLoginScript /cgi/login.pl # These must be set PerlSetVar BuscaWAPDBI_DSN dbi:Oracle:BW_CATALOG PerlSetVar BuscaWAPDBI_SecretKeyFile /home/fxn/prj/bw/buscawap/etc/auth.key # These are optional, the module sets sensible defaults. PerlSetVar BuscaWAPDBI_Userwap PerlSetVar BuscaWAPDBI_PasswordX PerlSetVar BuscaWAPDBI_UsersTable view_active_users PerlSetVar BuscaWAPDBI_UserField login PerlSetVar BuscaWAPDBI_PasswordField password PerlSetVar BuscaWAPDBI_CryptType none PerlSetVar BuscaWAPDBI_GroupsTable view_active_users PerlSetVar BuscaWAPDBI_GroupField rol PerlSetVar BuscaWAPDBI_GroupUserField login PerlSetVar BuscaWAPDBI_EncryptionType none PerlSetVar BuscaWAPDBI_SessionLifetime 00-24-00-00 Location /login AuthTypeApache::AuthCookieDBI AuthNameBuscaWAP SetHandler perl-script PerlHandler Apache::AuthCookieDBI-login /Location Alias /cgi /home/fxn/prj/bw/buscawap/www/cgi/ PerlModule Apache::Registry Location /cgi SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI /Location Location /docs AuthType Apache::AuthCookieDBI AuthName BuscaWAP PerlAuthenHandler Apache::AuthCookieDBI-authenticate PerlAuthzHandler Apache::AuthCookieDBI-authorize require valid-user SetHandlerperl-script PerlHandler BuscaWAP::Apache::Docs /Location
all of a sudden Too Many Arguments error is appearing
Hello, I had an odd thing happen today with a script I've been running successfully under Apache::Registry for weeks now. It's been going fine and then today the error_log started to fill with messages such as: Too many arguments for Apache::ROOT::cgi_2dbin::chimpkit::chimpworks_2epl::getStaleWatches at /usr/local/apachessl/cgi-bin/chimpkit/chimpworks.pl line 88, near $tmpl) These are coming from all over my code at all different subroutines. They appear to be sporadic/random, not happening every time through. I've double-confirmed that my subroutines are not declared with prototypes. Is this a common problem? What would have triggered it all of a sudden. Most/all of my subs use the DBI/Apache::DBI interface to get data from a Pg database, populate an HTML::Template, and display it. Thoughts? -Fran
Can mod_perl help me use ENV variables in httpd.conf?
I am trying to make a portable mod_perl.conf. I have things like:
Alias /cgi-bin/chimpkit/ /usr/local/apache/cgi-bin/chimpkit/
Location /cgi-bin/chimpkit/
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
/Location
which really needs to become something like:
Alias /cgi-bin/chimpkit/ $SERVER_ROOT/cgi-bin/chimpkit/
etc...
I don't think I can do this directly with Apache but I found a random
newsgroup thread that suggested something like the following might work:
Perl
push PerlConfig, EOF
Alias /cgi-bin/chimpkit/ $ENV{'SERVER_ROOT'}/cgi-bin/chimpkit/
Location /cgi-bin/chimpkit/
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
/Location
EOF
/Perl
Is this a good way to solve this problem, is there an easier way, and
does this even work? :-)
Thanks,
Fran
Re: Can mod_perl help me use ENV variables in httpd.conf?
Yikes, I just found an example of the exact thing I needed in the cookbook (recipe 2.16). Sorry, and thanks! -Fran
Re: Can mod_perl help me use ENV variables in httpd.conf?
I spoke too soon.
I need:
Perl
push Alias, [ qw(/cgi-bin/chimpkit/ $ENV{SERVER_ROOT}/cgi-bin/chimpkit/) ];
/Perl
This does not appear to be possible because there's no way to pass in SERVER_ROOT to
the apache startup. I have SERVER_ROOT
getting set in root's .bashrc, but when I execute ./apachectl start it appears to not
pass in any ENV at all, and the server seems
to set only a fewGATEWAY_INTERFACE, MOD_PERL and PATH. I can't use PerlSetEnv of
course because I'm trying to make a portable
mod_perl.conf in the first place. I can't use SetEnv in the httpd.conf because that
doesn't get set until the fixup phase. Is
there any way?
-Fran
Fran Fabrizio wrote:
Yikes, I just found an example of the exact thing I needed in the
cookbook (recipe 2.16). Sorry, and thanks!
-Fran
Re: different type of login with Apache::AuthCookie?
Have that proactive signin area forward to a page behind Apache::AuthCookie protection and then have that page forward them right back to where they were? If you don't have frames that would be pretty easy. -Fran Ken Miller wrote: We currently use Apache::AuthCookie for authentication/authorization, and it works great. However, we want to make a change to how the login works. In addition to having Apache::AuthCookie intercept requests for URL's that require auth/authz, we would like to provide a signon area on the main page where the user can proactively sign in. Would this be as simple as setting the same cookie (using the same format, obviously) as Apache::Authcookie is looking for when signon occurs on the front page? Or, better still, is there a way using A:A itself to do this? Thanks! -klm.
Re: AuthCookieDBI not getting secret keys in BEGIN block
Well, let's start with the basics...
In httpd.conf (or mod_perl.conf or wherever) you have...
PerlSetVar AFS_AdminDBI_SecretKeyFile /path/to/your/keyfile
right? From the error you describe it sounds like you don't have this
variable declared correctly.
-Fran
my keyfile_vars = grep {
$_ =~ /DBI_SecretKeyFile$/
} keys %{ Apache-server-dir_config() };
I inserted a debug statement right after this to see what was being placed
into this list. Nothing.
Re: XML::RPC
I think you'll find RPC::XML to be a solidly engineered module. I've used it as a client and as a server to good effect. It includes stand-alone, CGI, and mod_perl based servers and a very nice client. I will second the vote for RPC::XML. We use this module with great success under mod_perl. It's very easy to understand for the most part. There are a few little oddities, but I'm sure myself or Paul can get you around any obstacles you hit. -Fran
Re: framesets/AuthCookie question
Followup from last week:
I'm using AuthCookie and as some of you know, if it determines your
session to be invalid it redirects to a login page instead by way of a
FORBIDDEN response coupled with a custom_response error page.
[snip]
...I then thought it'd be neat to include on the login page handler output
a message to tell them how they got there (Your session has expired,
Your account has logged on from another location, Invalid
username/password combination, whatever...).
At first I thought I could accomplish this by simply doing
$r-notes('LOGINFAILMSG' = 'Your session has expired') if AuthCookie
detected it to be thus, and then in my handler I could retrieve it and
display it.
New observations
It seems that even if AuthCookie returns a FORBIDDEN with a custom_error
page set, the $r-notes() don't propagate. Does apache consider the
display of the custom_response page to be a completely new request?
-Fran
framesets/AuthCookie question
I'm using AuthCookie and as some of you know, if it determines your
session to be invalid it redirects to a login page instead by way of a
FORBIDDEN response coupled with a custom error page.
My app has a frameset (navigation on the left, and two data frames on
the right). I know the evils of framesets, but in our case, it's the
best way to present our particular data.
What ends up happening is that if the session expires, AuthCookie
displays the login page inside whatever frameset you were clicking in,
while the other two remain on whatever they were on previously.
I made a quick solution...I told AuthCookie that my login page was
login.html. login.html had javascript which called /real/login (a
mod_perl handler) and targeted it to the top frame. All is well and now
the entire browser window gets cleared and replaced with the login page.
However...I then thought it'd be neat to include on the /real/login page
a message to tell them how they got there (Your session has expired,
Your account has logged on from another location, Invalid
username/password combination, whatever...).
At first I thought I could accomplish this by simply doing
$r-notes('LOGINFAILMSG' = 'Your session has expired') if AuthCookie
detected it to be thus, and then in my handler I could retrieve it and
display it.
However, it's failing of course because I added the extra redirection of
the login.html w/ the javascript, which makes a round trip to the client
and back, so it looks like a brand new request to mod_perl, thus, no
notes() any more. Is there a solution to breaking out of the frameset
AND propagating the reason for the logout to the /real/login page?
I'd appreciate and and all ideas. Thanks!
-Fran
Re: Enforcing user logged in from only 1 browser?
Peter Bi wrote: If you touch SessionDBI for every request, why don't go directly to the Basic Authentication ? 1. You can't use a custom log in page 2. You can't log out unless you close your browser 3. It's for use by our employees only. They are told to enable cookies. =) -Fran
Re: Enforcing user logged in from only 1 browser?
Peter, 2) that depends. First, for some reasons, Internet is designed without Logout. Many seldom logout from those services such as Yahoo mail, and me too. For the specific question you posted (one login only for an account), while it can be in principle designed and implemented, in practice, it may not work that smoothly, because many users still don't run Logout. Trust me :-). So BA or cookie doesn't matter. Second, you can make a link to close the window using javascript, just like a Logout button. Well that's kind of why I'm here in the first place...looking for a real solution to users who don't log out. I'd rather force logout their old sessions rather than just resign to the fact that user's habits make logouts unpredictable. It's not acceptable for our application's purposes to just leave active sessions open if it's at all possible to avoid. 3) will be very interesting to hear about your successful implementation! I would have been done yesterday had I not made a bonehead mistake and deleted a very important database table. I'm still recovering from that mistake. :-( Hopefully, I'll be able to tell you all about the successful implementation early next week. (BTW, if only the existence status of an account is needed to double check, please consider a lock file (e.g. -e) under Apache::File that may be much faster than to call SessionDBI) I'm not too worried about performance...only about 100 users will ever have an account on this system, a fraction of them actively using the app at any one time. But I'm not using the DBI for this part anyhow. I'm using Apache::Session::File, more or less (really using Flex but only overridding the Generate method). The only time I hit the database is to check that the user/password are valid and get user preferences when they submit the login form. The lock file actually isn't a workable solution, now that I think about it. Just knowing a user has logged in and not logged out does me no good, I need to know if they have other valid session keys still in existence so I can expire them. A lock file could lead to false positives - if the key expired but they haven't visited again or explicitly logged out since, it'll be there but the user really doesn't have any active sessions. I still think Jeff's post yesterday suggesting I store the AuthCookie key in the Apache::Session data is the answer. Thanks for the dialog, I'll post the final results. -Fran
Re: Enforcing user logged in from only 1 browser?
[EMAIL PROTECTED] wrote: How are you handling your sessions? I use Apache::Session::Postgres. I'm using AuthCookie. A customization of AuthCookieDBI to be specific. However, I also use Apache::Session. Basically, I authenticate with AuthCookie, then I pass the authenticated username over to Apache::Session::File (for now, probably soon to become A:S:Postgres) and use the user id as the session key. In that session I store user preferences, etc... In my scenario, if I needed to do this, I would check the list of valid sessions I have for one that exists for the user. ie, if 'gphat' tries to login, I check to see if any of the sessions the db are for user gphat. If so, eliminate it and create a new one. I can also detect if the user had an existing session already (I store the AuthCookie key in the db for each user). However, the question is just because there's an existing AuthCookie key, it doesn't mean they have another active session. It could just be an expired one. So, it seems the logic would go something like: 1. User logs in 2. Check for another session key for this user 3. If found, check to see if it's expired. 4. If not expired, alert user and ask if user wants to expire older session 5. Expire older session It's #5 that's troublesome. I wasn't sure how I could expire the older session (since the session key that matters is sitting client side). I guess I could keep a table of invalidated session keys, and check against that every time in along with all the other checks going on in authen_ses_key(). I was just mainly asking if there was an existing solution out there. The main requirement that we're trying to solve is that a user cannot be signed on from more than one location at once. Mainly because this probably means that they walked away from a computer with an active session on it, which isn't good. I suppose an inactivity timer might be helpful, too. Thanks, Fran
Re: Enforcing user logged in from only 1 browser?
I'm not sure I follow your session id problem. When I check a session, I ask the client for it's ID, then look the session up by ID. To 'expire' the session, I simply delete it from the session store (File or Postgres). The confusion is you aren't using sessions in the authentication sense of the word. You say you look up the session by ID...but how do you know the ID? Because they previously authenticated. I'm using sessions at the authentication step, via AuthCookie. Unfortunately, there's some terminology muddling...AuthCookie calls it a session when it establishes that a user is a valid user and sets a cookie on their browser. Apache::Session considers a session a series of page hits from the same user. It assumes you've already done whatever you need to do to assure that the user is valid. So to expire a session in the sense of AuthCookie, you have to explicitly tell AuthCookie that a particular key is no longer valid, because otherwise everything about the AuthCookie cookie looks valid, and you'll have 'gphat' logged in validly from two different browsers. That's completely separate from the Apache::Session session, which has nothing on the client side (other than some method for obtaining the session id, which could be a cookie, a hidden form field, a munged URL, or in my case, the userid obtained from AuthCookie authentication). -Fran
Re: Enforcing user logged in from only 1 browser?
You would have to do the auth part yourself, as well as the actual cookie handling, or else hack AuthCookie to cooperate with Apache::Session. This is exactly what I've done. I've modified AuthCookieDBI to create an Apache::Session session as soon as it knows it has a valid user. Then if the user is conscientious and logs out or the AuthCookie key is expired, AuthCookie will take care of deleting the Apache::Session session. That part is working. The only thing is AuthCookie needs some foolproof way to check to see if that same user already has a valid session from somewhere else that is still active. It's easy enough to just delete/reset/blow on top of any older Apache::Session objects for this user. It's not so apparent (to me) how to tell AuthCookie to no longer accept the older key for this user. What would otherwise happen is that the user would have two perfectly valid sessions from two different browsers, potentially blowing over his Apache::Session object back and forth. Not to mention someone else could hop onto the old browser and see/do stuff they are not authorized to see/do. Yes, I realize that a certain amount of this depends simply on not having idiots for users. =) But I like to help them out as much as possible. We don't consider the 2 simulataneous logins to be super crucial to avoid, as our expire times are kept fairly short anyhow, but we do think it makes for a more robust interface. A whimsical example of what could happen is that user #1 leaves a browser session open and goes to a different station and logs on. User #2 wants to play joke on user #1. User #2 goes to user #1's old session and changes his style preferences. User #1 is at other workstation, and the entire look of the site changes instantly before his eyes. Of course, more serious things can happen if user #1 happens to be an administrator or user with some advanced privileges to our system and user #2 happens to be an arse looking to get fired. Anyways, just talking through the problem repeatedly here has given me some idea so I am off to try those. =) -Fran
Re: Enforcing user logged in from only 1 browser?
Jeff wrote: Forgive a mod_perl newbie for non mod_perl thinking, but this is (a simplified overview) of how I would approach this: request for any protected page - if no existing session data [so not authenticated] create new session remember target page in session redirect to login page otherwise allow access to page Yes, this is exactly how AuthCookie works. login page POST with user id / password. - if ( valid user / password ) add user info to session AuthCookie sessions don't also carry user info, but that's why I create an Apache::Session to do it. expire previous session [id was saved in db] Right-o. How to expire an otherwise valid AuthCookie session is the question. [snip] If someone now tries to come back with an old session id, there is no data in the session, so they will be considered un-authenticated, and will get redirected to login page. If someone comes in with an old active session (assuming it's not expired) AuthCookie examines the MD5 hash and says everything matches up, you may proceed. I need to add a step here to say if newer session for user exists, kill this one. But you've just given me a great idea! When the old session comes in, there will still be data in the session (because the new session is using it - sessions are keyed by user id, not session id). So I can't rely on an empty session data to be the clue. BUT - I can store the session key that generated this session data in with the session data, and try to match those up. I like it. This will work, I think. Thank you. =) Why do I use the user id instead of the session id for the session key? Because it makes the code easier for other developers (a user will always have a session with the key $r-connection-user) and that gets passed around automatically rather than me having to expose the developers to the AuthCookieDBI cookie directly. I just find it easier to rely on $r-connection-user to always be the session key. [snip] I can see two issues with this approach: 1) login ping-pong. Two users using the same id/password will be logging each other out as they log in (but this seems to be what you want?) Yes, or at least a page saying you're logged in elsewhere, do you want to ax that one and continue, or abort this login. Even a forced logout of the older one without the user knowing is fine. 2) it does not prevent the user from having the same pages open multiple times within the same browser instance (eg when the user presses Ctrl-N after having logged in) This is ok, because we're more concerned with an unmanned, logged-in station. If they want 5 browser windows, they can go nuts. Thanks for the dialog, Jeff! I think that clue you gave me above is what I need. The confusion is again because AuthCookie and Apache::Session both call themselves sessions. AuthCookie does the authentication, Apache::Session holds the user data. So I need to write the piece that coordinates the cleanup of old sessions between the two. -Fran
Enforcing user logged in from only 1 browser?
Hello all, I'm looking for a straightforward approach to extend our AuthCookie sessioning to enforce that a user is only logged in from one browser at a time. For us, it would suffice that if the user tries to log in from a 2nd browser, the first session would just be expired. I was thinking that upon login I could save the AuthCookie key in that user's db entry as current_session_key and I could blank it out when they explicitly log out. Then during login, I would be able to see if there's another key still out there for them. The tricky part for me is figuring out if that key is still an -active- session as opposed to having just left their browser open last night or something. And also, if I do determine that it is another active one, how would I expire it? Anyone done this type of thing previously? Thanks, Fran
Re: Ordering in %INC for PerlRestart
Thanx for the reply (I hardly get replies for subjects with restart :-( I guess I'm the only one using PerlFreshRestart (sic !). Hopefully you are the only one! Pardon my newbie-ness, but can someone explain the perils of PerlFreshRestart in a bit more depth? I hadn't heard of it being dangerous until now. Thanks, Fran
AuthCookie login ?
Is there a hook in AuthCookie to allow me to run some code only right after successful login? The model doesn't seem to allow for this. The way it seems to work is you attempt to log in, if it doesn't find a valid cookie, it displays the login form again. You submit that and it sets the cookie without authenticating the login, then issues a redirect to the page the user was originally trying to go to. When the browser comes back via the redirect, the cookie is already present, and only then does AuthCookie attempt to authenticate the cookie. Since the authentication happens on every trip into the server, and I don't want to run my code (to set up an Apache::Session for the user's session data) until I'm sure I have a valid user on my hands, I can't see a way to do the session setup only the first time after a sucessful login. It would seem wasteful to check for the presence of the Apache::Session object every trip to the server just to determine if this is the first request or not. Is there a hook or a flag with that same functionality? Thanks, Fran
Re: mod_perl Cook Book
The cookbook is fabulous. In my opinion it's much clearer than the Eagle book. Of course it has the benefit of having been written when mod_perl had a few more years of maturity under it's belt. =) The Cookbook is wonderful and I would also like to publicly thank Geoffrey Young, one of the authors, for the generous amounts of help he has provided me via email. Buy it, you'll like it! -Fran Rasoul Hajikhani wrote: Hello folks, Has anyone purchased the mod_perl cook book from this list? If so, what do you think of it? Is it a good buy? Appreciate feed back. Thanks in advance -r
Session management
Hello all, I'm having something of a disconnect in my brain because I've absorbed a lot of mod_perl info in a very short period of time, so bear with me. =) Last week, I figured out how to use Apache::Session::File and got it working nicely. This week, I've figured out how to use Apache::AuthCookieDBI and also got it working nicely. Now to figure out how to make them play nicely together. :-) I think I'm getting confused because there's two different concepts of 'session' at work here. The AuthCookie concept of a session is tracking multiple page hits from an authenticated user - sessions as a security device. The Apache::Session concept of sessions is to pass data from request to request - state maintenance. (Correct me if I'm wrong) It would seem that I would want to use the key generated / returned-via-cookie in the AuthCookie processing to be used as the key to create/access the Apache::Session session. I imagine this is a pretty common task. My question is this: how do I make this connection? Do I store the key away in the Authen/Authz phases with pnotes() and then get it in the content generation phase when I'm getting/setting data into the Apache::Session object? Do I subclass further from AuthCookieDBI and provide hooks in the authorize() method to create an Apache::Session object at that time using the AuthCookie key? I'm just a tad confused, being a first-timer. =) The big picture is simple: I want to know what user is logged in and make sure his session is valid, and I want to store user preferences in his session so that I know how to customize his interface. You know, maybe we have a user_preferences table in the database, and upon successful login, I want to set up an Apache::Session object to figure out things like what color scheme this user wants and what region of the country he's in so I can present region-specific data. How do I approach this task? Thanks, Fran
Re: PROBLEMS WITH MODPERL
Jose Ortiz wrote: Apache has installed the mod_perl rpm and when I starts the daemon don't recognize the command PerlRequire. HELP!!! And the daemon you are starting includes mod_perl? ./httpd -l on your httpd daemon will tell you. -Fran -- Jose R. Ortiz Ubarri Cs. Student Programmer
Re: Apache+Modperl Website Statistics
But, I need to find someway to do this without the extra redirect. would be something along the lines of: have a javascript enabled page that gets the height and width of the client (as you've shown), that then redirects the client to a location that can read the height and width from the query string and set a session cookie, which can then be read and acted upon for every subsequent request by a PerlTransHandler or RewriteRule. Does that sound reasonable? Can you not just set a cookie from the javascript itself, rather than having it redirect to a location which then has to read it from the query string and set the cookie. Saves you one step, if it's possible to set the cookie directly from the javascript (which it seems like should be possible, but I don't know for sure). -Fran
Re: Poll for my site
I wanna make poll for some datas that we obtain from the users. For this, i know howto insert the datas to my sql database, make an average or something specific but how can i show the results as visual which has become very popular in web sites? This is not really on-topic for this list, but it sounds like you want something like GD::Graph from CPAN. -Fran
Re: Site Host Providers that Support mod_perl?
I thought I had posted to this thread yesterday but looking back I don't see that it showed up, so I'll try again. :) I'm also looking for good mod_perl-supporting ISPs. Recently I went through the list on the web site, and either the links were broken, or the sites made no mention of supporting mod_perl. The best I've managed to find on my own is an ISP that starts supporting it at the $250/month level! Yikes. =) The inaccuracy of the list doesn't surprise me since the ISP world has experienced so much turnover and turmoil in the last couple of years. I'd be willing to compile a list of ISPs that you all know about and/or use, and forward that on to the web site maintainer. I know one option is to run your own mod-perl enabled apache but I imagine that a lot of ISPs would get pretty upset about you running servers (especially ones that love memory) on non-privileged ports, if they even allow connections to those ports in the first place. My ideal setup would be to be able to colocate one of my servers and just use the ISP's bandwidth, but those plans are all pretty pricey. So, I'd really like to have a good ISP that supports mod_perl that I can afford because I'd enjoy being able to play around and create sites that use mod_perl outside of work. Of course, I can do it at home, but it's not the best place to host a web app, it'd have an audience of one. =) Thanks, Fran David Simcik wrote: Alright, I'm a total mod_perl newbie and would like to find a host for my personal site that allows me to develop mod_perl scripts. First off, I'm assuming that there is no way to install mod_perl on my current provider due to (obvious) access privilige restrictions to Apache? Secondly, the obvious question here, whom would you folks recommend for hosting services, assuming the afforementioned? Thanks! David
Re: PerlFreshRestart, mod_perl DSO, and Apache::StatINC
upgrades for applications that maintain state - since a user might have a session created using a new-code box, then hit an old-code box on the next page view. it takes us many minutes to work through restarting the entire array. were you ever concerned about something like that? I only learned this yesterday by reading Perrin's eToys article, but their concept of sticky load balancing was interesting. They had a proxy server in front of the app servers. The proxy assigned session keys, and made sure that if you came back in on the same session you got assigned to the same app server. I thought that was a neat idea and would solve this particular problem. -Fran
Re: Site Host Providers that Support mod_perl?
If you had something like Speakeasy DSL or a similar provider that allows you to run your own servers, you can run a server out of your house and use mod_perl and have fun. -- Brett I actually have BellSouth dsl. I've never perused their acceptable use policy, but I never thought it was a good idea to host a site at home because of a lot of thingsI have to open port 80 and then I'd have to worry even more about security, it's dynamic IP and my IP refreshes fairly regularly and the dyndns service that I use sometimes lags by as much as 15 minutes in its updates. I live in a thunderstorm-rich area, our power is constantly going out, etc... then again, what I'd like to host isn't mission critical so maybe I'll rethink that...I've gotten some good feedback so far, thanks to everyone! I still would like to find either an ISP or a colo, because the other half of it is that I do a good deal of freelance work on sites, and having the option to resell a hosting agreement that supports mod_perl and then having mod_perl at my disposal for app development is attractive. I certainly would not want to host that kind of thing at home. -Fran
Re: RegistryLoader Segmentation fault
Fran Fabrizio wrote: Hello, I'm trying to follow the script in section 214 of the book mod_perl Developer's Cookbook in order to pre-load my Apache::registry scripts using Apache::RegistryLoader I'm getting a seg fault when I attempt to start apache This was the problem I was having last Friday Just wanted to post the results - the upgrade to Perl 561 solved the problem PERL_DEBUG=1 on mod_perl compilation was also very helpful Thanks to everyone for their help! -Fran
RegistryLoader Segmentation fault
Hello,
I'm trying to follow the script in section 214 of the book mod_perl
Developer's Cookbook in order to pre-load my Apache::registry scripts
using Apache::RegistryLoader I'm getting a seg fault when I attempt to
start apache
My startuppl is as follows:
#!/usr/local/bin/perl
use lib qw(/usr/local/apache/lib/perl);
use Apache::DBI;
use Apache::Registry;
use Apache::RegistryLoader;
use DBI;
use DBD::Pg;
use strict;
use CGI qw(-compile :all);
use DirHandle;
my $rl = Apache::RegistryLoader-new;
my $dh = DirHandle-new(/usr/local/apache/cgi-bin/chimpkit/) or die $!;
foreach my $file ($dh-read) {
next unless $file =~ m/\pl$/;
print STDOUT Pre-loading $file\n;
$rl-handler(/cgi-bin/chimpkit/$file,/usr/local/apache/cgi-bin/chimpkit/$file);
}
1;
When I attempt to start apache, I get the following messages on STDOUT:
[root@castle bin]# /apachectl start
Pre-loading chimpworkspl
Apache::Debug: [level 1]
Compiled package Apache::ROOT::cgi_2dbin::chimpkit::chimpworks_2epl
for process 27233 at
/usr/lib/perl5/site_perl/560/i386-linux/Apache/RegistryLoaderpm line 76
/apachectl: line 171: 27233 Segmentation fault (core dumped) $HTTPD
/apachectl start: httpd could not be started
[root@castle bin]#
Nothing has been written to the error log The format of my
$rl-handler() call seems ok to me I perused the archives for a while
and tried a couple of things that fixed other people's RegistryLoader
problems, to no avail Everything works fine if I comment out the call
to handler() except of course now each child has a copy of the compiled
code Any thoughts?
Thanks,
Fran
Re: RegistryLoader Segmentation fault
Ged, using Apache::RegistryLoader I'm getting a seg fault when I attempt to start apache Read mod_perl/SUPPORT Ok I've looked through it I've tried some of the quicker suggestions gdb -core core and gdb httpd core tell me: Core was generated by `/usr/local/apache/bin/httpd' Program terminated with signal 11, Segmentation fault #0 0x80ca6b6 in Perl_gv_init () I'll try some of the more involved stuff here in a moment Did you compile your own Perl, mod_perl and Apache? Yes Perl 560, mod_perl 125, apache 1319 You might be better off with Perl version 561 instead I will upgrade and see what happens Are you using DSO? No Thanks for the pointers thus far! -Fran
Re: RegistryLoader Segmentation fault
see Recipe 919 for a general introduction into using gbd and getting a backtrace, as well as the SUPPORT document in the mod_perl sources Here is the backtrace for now I'm going to try Perl 561 and then try to see what the backtrace looks like with a PERL_DEBUG=1 enabled mod_perl Thanks for the help thus far -Fran (gdb) bt #0 0x80ca6b6 in Perl_gv_init () #1 0x80cb9d5 in Perl_gv_fetchpv () #2 0x80810dd in perl_section_hash_init () #3 0x8081403 in perl_section () #4 0x809aa40 in ap_clear_module_list () #5 0x809b598 in ap_handle_command () #6 0x809b635 in ap_srm_command_loop () #7 0x809ef2a in ap_limit_section () #8 0x809aa40 in ap_clear_module_list () #9 0x809b598 in ap_handle_command () #10 0x809b635 in ap_srm_command_loop () #11 0x809bd52 in ap_process_resource_config () #12 0x80a0cc7 in ap_exists_config_define () #13 0x809aadc in ap_clear_module_list () #14 0x809b598 in ap_handle_command () #15 0x809b635 in ap_srm_command_loop () #16 0x809bd52 in ap_process_resource_config () #17 0x809c695 in ap_read_config () #18 0x80a6e9f in main () #19 0x400a1b65 in __libc_start_main (main=0x80a6bb8 main, argc=1, ubp_av=0xbaf4, init=0x80621d4 _init, fini=0x814a26c _fini, rtld_fini=0x4000df24 _dl_fini, stack_end=0xbaec) at /sysdeps/generic/libc-startc:111
Can't solve the CGI/pm Can't call register_cleanup problem
Hello,
I've just installed a mod_perl enabled Apache and I am trying to configure
it. I ran into the can't call register_cleanup on an undefined value
while I was trying out the sample startup.pl file in the Writing Apache
Modules in Perl and C book. I did see the note about this in the
troubleshooting, but the fix didn't solve my problem.
Here's my httpd.conf:
...
Alias /perl/ /usr/local/apachemp/cgi-bin/
PerlPostReadRequestHandler 'sub { Apache-request(shift) }'
PerlModule Apache::Registry
PerlFreshRestart On
PerlRequire conf/startup.pl
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
PerlSendHeader on
/Location
Location /hello/world
SetHandler perl-script
PerlHandler Apache::Hello
/Location
And here is conf/startup.pl...
#!/usr/local/bin/perl
BEGIN {
use Apache ();
use lib Apache-server_root_relative('lib/perl');
}
use Apache::Registry();
use Apache::Constants();
use CGI::Carp ();
use CGI qw(-compile :all);
1;
It dies on the use CGI qw(-compile :all); line, with the message:
[root@dungeon apachemp]# ./bin/apachectl configtest
[Tue Jul 31 00:54:54 2001] [error] [Tue Jul 31 00:54:54 2001] startup.pl:
[Tue Jul 31 00:54:54 2001] startup.pl: [Tue Jul 31 00:54:54 2001] CGI.pm:
Can't call method register_cleanup on an undefined value at
/usr/lib/perl5/5.6.0/CGI/Object.pm line 225.
[Tue Jul 31 00:54:54 2001] startup.pl: [Tue Jul 31 00:54:54 2001]
startup.pl: BEGIN failed--compilation aborted at conf/startup.pl line 14.
[Tue Jul 31 00:54:54 2001] startup.pl: Compilation failed in require.
Syntax error on line 995 of /usr/local/apache/conf/httpd.conf:
[Tue Jul 31 00:54:54 2001] startup.pl: [Tue Jul 31 00:54:54 2001]
startup.pl: [Tue Jul 31 00:54:54 2001] CGI.pm: Can't call method
register_cleanup on an undefined value at
/usr/lib/perl5/5.6.0/CGI/Object.pm line 225.
[Tue Jul 31 00:54:54 2001] startup.pl: [Tue Jul 31 00:54:54 2001]
startup.pl: BEGIN failed--compilation aborted at conf/startup.pl line 14.
[Tue Jul 31 00:54:54 2001] startup.pl: Compilation failed in require.
[root@dungeon apachemp]#
I'm running the following versions of the software:
Apache 1.3.20
mod_perl 1.26
CGI.pm 3.02
I saw the note about it in the faq/troubleshooting section of the docs on
perl.apache.org, but as you can see I made the suggested change (the
PerlPostReadRequestHandler line in httpd) and I still get the error.
Any ideas? I'm not doing anything fancy, these are all default installs of
everything, just following the docs for installation and the book for the
startup.pl. The server starts and runs fine if I remove the use CGI
qw(-compile :all); line.
Thanks,
Fran
