Re: CGI.pm and friends port to mp2
On Fri, Mar 14, 2003 at 10:31:25AM +1100, Carl Brewer wrote: > > > Stas Bekman wrote: > >Lincoln Stein wrote: > > > > >You want to move to MP2, if one of the following reasons apply: > > > >- you are stuck with Apache2 > >- you want to use i/o filters > >- you want to write your own protocol handlers > >- you want to use a threaded mod_perl > >- you are stuck with win32 (mp1 is unusable on win32, serialization) > > And you use IPv6 :) Or use Red Hat, due to the new forced upgrade cycle. In October (when they stop making upgrades for 7.x), a significant chunk of the Linux world is going to: 1) Stop using Red Hat 2) Compile their own upgrades 3) Start using Red Hat 8 Colin
Re: [mp1.2x] Intermittent code execution errors
On Wed, Aug 21, 2002 at 10:55:35AM -0700, Colin Kuskie wrote: > [This is an update from my earlier posting which was entitled > "mod_perl has Alzheimers?". Since then I've read through the > mod_perl guide, searched the mailing list archives, and done a > more thorough job of analyzing the debug output.] I forgot to attach the perl code. Colin Kuskie Apache-NavGraphics-1.2.tar.gz Description: application/tar-gz
[mp1.2x] Intermittent code execution errors
OR\n";
}
return OK;
}
##The template object caching subroutine
##Note the warn statements and their order
sub load_plate {
my ($r) = @_;
my $conf_file = $r->server_root_relative($r->dir_config('MyTemplate'));
my $mod_time;
if (-e $conf_file) {
$mod_time = (stat _)[9];
}
else {
$conf_file = '';
$mod_time = 0;
}
warn "NavGraphics($$): conf_file = >$conf_file<\n";
warn "NavGraphics($$) time=$mod_time\n";
warn join '', "NavGraphics($$): exists ", exists $TB{$conf_file}, "\n";
return $TB{$conf_file}->template()
if exists($TB{$conf_file})
&& ($TB{$conf_file}->modified() >= $mod_time)
&& (ref($TB{$conf_file}->template()) eq 'Text::Template');
warn "NavGraphics($$): plate not cached\n";
warn "NavGraphics($$): plate $TB{$conf_file}\n";
warn "NavGraphics($$): before new $TB{$conf_file}\n";
$TB{$conf_file} = Apache::NavGraphics::NavTemplate->new($conf_file);
warn "NavGraphics($$): after new $TB{$conf_file}\n";
warn join '', "NavGraphics plate($$): ", ref($TB{$conf_file}->template()), "\n";
return $TB{$conf_file}->template();
}
##The new method for Apache::NavGraphics::NavTemplate
package Apache::NavGraphics::NavTemplate;
sub new {
my ($class, $templateFile) = @_;
warn "NavPlate($$): new <$templateFile>\n";
unless ($templateFile) {
warn "NavPlate($$) Empty templateFile sent\n";
return bless { 'template' => '',
'modified' => 0 }, $class;
}
my $fh = Apache::File->new($templateFile) || return;
warn "NavPlate($$): after fh\n";
my $template = Text::Template->new(
TYPE => 'FILEHANDLE',
SOURCE => $fh,
DELIMITERS => ['{{', '}}']
)
or warn "($$)Problem with template: $Text::Template::ERROR\n";
warn join '', "NavPlate($$) ref: ", ref($template), "\n";
return bless({ 'template' => $template,
'modified' => (stat $templateFile)[9] }, $class);
}
The spawning of a bad child appears completely random and load
independent, which probably means that it isn't a memory problem.
However, I had the memory of the machine scanned and I've been able to
duplicate the problem on a completely different machine.
I've tested and seen the problem on:
RH6.2, with updated mod_perl and apache rpms (I forget the exact versions)
RH7.2
mod_perl-1.26-2 (from rpm)
apache-1.3.22-6 (from rpm)
mod_perl-1.27 (compiled from source)
apache_1.3.26 (compiled from source)
RH7.3
apache_1.3.26 (from rpm)
mod_perl-1.27 (from rpm)
At this point, I don't understand why the output from warn in the "new"
method aren't going to the log file, or why Text::Template is returning
the template code instead of an object. The debugging examples
from the website are pretty daunting, I could generate 100 Mb's of
log files with no errors, only to find that when I restart the server
that a "bad" child is started right away (which happened the night
before last. I put about 240K hits on the server with no errors.
Then I made a few modifications to httpd.conf, restarted the server
and got an error right away. Changing the config back to the original,
however, didn't make the problem go away).
Has anyone seen behavior like this, or have suggestions on how to
make the debugging a little easier? Should I just wade in and see
what happens? Is there some other combination of software that I
should try, like a different version of Perl itself?
Thanks for your help,
Colin Kuskie
httpd.conf snippet:
NameVirtualHost 199.108.225.3
PerlModule Apache::OutputChain
PerlModule Apache::NavGraphics
PerlModule Apache::SendFile
##Main site, www
ServerName www.sunsetpres.org
DocumentRoot /home/httpd/html
SetHandler perl-script
PerlHandler Apache::OutputChain Apache::NavGraphics Apache::SendFile
PerlSetVar MyTemplate etc/Sunset6.template
PerlSetVar NavGraphicsDir /navgraphics
perl -V:
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.17-0.13smp, archname=i386-linux
uname='linux daffy.perf.redhat.com 2.4.17-0.13smp #1 smp fri feb 1 10:30:48 est
2002 i686 unknown '
config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcf_by=Red Hat,
Inc. -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux
-Uusethreads -Uuseithreads -Uuselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm
-Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Dlocincpt
mod_perl/Apache has Alzheimers?
I recently got a new server for our website, and installed RH7.2 on
it and shipped it off to the colo. Since then, I've been getting
lots of 404 server errors, so I added debugging code to the stacked
content handler (a modified version of Apache::NavBar). What
showed up in the error_log is unbelieveable.
- variables randomly get corrupted
- statements either fail, or are skipped
(hence the Alzheimers reference)
I've tried both the apache and mod_perl that come with RH7.2 as well
as on the latest versions of both that I compiled by hand, and there's
no change in behavior between them.
Here's the relevant sections of code from the module (I can also send a
copy of the module if people think having the whole thing would help).
##The PRINT method for the Apache::OutputChain handler
sub PRINT {
my $self = shift;
my $r = $self->[0];
my $bar = load_nav($r);
my $plate = load_plate($r);
local $_ = join '', @_;
my ($header, $content);
($header,$content) = m#(.+).*(.+)#si;
my $thash = {
'left_nav_java'=> $bar->java,
'header' => $header,
'navigation_table' => $bar->table,
'content' => $content
};
warn join ':', $$, $r->filename, ref($plate), "\n";
if (ref($plate) ne 'Text::Template') {
warn join '', "NavGraphics($$) PRINT: >", $plate, "<\n";
}
my $result = $plate->fill_in(HASH => $thash);
if (defined $result) {
$self->Apache::OutputChain::PRINT($result);
}
else {
warn "ERROR: $Text::Template::ERROR\n";
}
return OK;
}
##The template object caching subroutine
##Note the warn statements and their order
sub load_plate {
my ($r) = @_;
my $conf_file = $r->server_root_relative($r->dir_config('MyTemplate'));
my $mod_time;
if (-e $conf_file) {
$mod_time = (stat _)[9];
}
else {
$conf_file = '';
$mod_time = 0;
}
warn "NavGraphics($$): conf_file = >$conf_file<\n";
warn "NavGraphics($$) time=$mod_time\n";
warn join '', "NavGraphics($$): exists ", exists $TB{$conf_file}, "\n";
return $TB{$conf_file}->template()
if exists($TB{$conf_file})
&& ($TB{$conf_file}->modified() >= $mod_time)
&& (ref($TB{$conf_file}->template()) eq 'Text::Template');
warn "NavGraphics($$): plate not cached\n";
warn "NavGraphics($$): plate $TB{$conf_file}\n";
warn "NavGraphics($$): before new $TB{$conf_file}\n";
$TB{$conf_file} = Apache::NavGraphics::NavTemplate->new($conf_file);
warn "NavGraphics($$): after new $TB{$conf_file}\n";
warn join '', "NavGraphics plate($$): ", ref($TB{$conf_file}->template()), "\n";
return $TB{$conf_file}->template();
}
##The new method for Apache::NavGraphics::NavTemplate
package Apache::NavGraphics::NavTemplate;
sub new {
my ($class, $templateFile) = @_;
warn "NavPlate($$): new <$templateFile>\n";
unless ($templateFile) {
warn "NavPlate($$) Empty templateFile sent\n";
return bless { 'template' => '',
'modified' => 0 }, $class;
}
my $fh = Apache::File->new($templateFile) || return;
warn "NavPlate($$): after fh\n";
my $template = Text::Template->new(
TYPE => 'FILEHANDLE',
SOURCE => $fh,
DELIMITERS => ['{{', '}}']
)
or warn "($$)Problem with template: $Text::Template::ERROR\n";
warn join '', "NavPlate($$) ref: ", ref($template), "\n";
return bless({ 'template' => $template,
'modified' => (stat $templateFile)[9] }, $class);
}
And here's some error_log output:
NavGraphics(30166): conf_file = >/etc/httpd/etc/Sunset6.template<
NavGraphics(30166) time=1025358762
NavGraphics(30166): exists 1
NavGraphics(30166): plate not cached
NavGraphics(30166): plate Apache::NavGraphics::NavTemplate=HASH(0x8268adc)
NavGraphics(30166): before new Apache::NavGraphics::NavTemplate=HASH(0x8268adc)
NavGraphics(30166): after new Apache::NavGraphics::NavTemplate=HASH(0x82688a8)
NavGraphics plate(30166):
30166:/home/httpd/html/Web/WebPolicy.html::
Please note the flow. This page has been accessed several times, but
now the caching code says that it isn't cached, which means that the
cached Text::Template object isn't there anymore, even though the hash
entry exists. Without worrying why that happens, look at the rest of
this section. There should be additional debugging output between
these lines:
NavGraphics(30166): before new Apache::NavGraphics::NavTemplate=HASH(0x8268adc)
NavGraphics(30166): after new Apache::NavGraphics::NavTemplate=HASH(0x82688a8)
from this call to create a new object:
$TB{$conf_file} = Apache::NavGraphics::NavTemplate->new($conf_file);
There isn't, but the hash has changed, as shown by the change in
address! What's more, the last two lines show that whatever is
returned by load_plate isn't an object. It turns out that it's the
template itself (the file).
Sometimes, the debugging code will look like this:
Graphics(30166): conf_file = >/etc/httpd/etc/
Re: Content management systems
On Tue, Apr 09, 2002 at 04:42:31PM +0200, Maarten Stolte wrote: > > > >Anybody know of something in mod_perl with this out of the box > > >functionality in addition to content management? > > > > Metadot bills itself as a portal product. I've even installed it briefly in > > the past, and it seemed relatively easy to setup & customize. > > http://www.metadot.com/ The developer site is at http://www.metadot.net/. > > > wow...this looks great, anybody actually use it? It's nice, but it lacks the massive power of Bricolage for it's news channels. But Metadot is extensible so it should be possible to weld the two together and make the best of both worlds. Best of all would be to marry them both with AxKit. Colin
Problems migrating from Apache::OutputChain to Apache::Filter
ml The ASP was set up to guarantee a consistent look and feel to all pages and to ease the generation of navigation bars. It consistently looked at one configuration file for its navigation information. It was decided to migrate the server to a Linux server running Apache to increase uptime (the SBS had to be rebooted weekly) and decrease cost (Red Hat Linux (free) versus Microsoft SBS (several hundred dollars)). However, we needed to duplicate the functionality of the ASP script. Luckily I had access to a module written by Lincoln Stein in one of his many Perl Journal articles, B. B was originally designed to automate the generation of navigation bars on a directory by directory basis. Configuration was handled via variables set in the Apache httpd.conf file with one variable per directory. If a given directory didn't have a variable set then it was either blank or inherited the value of its parent directory (if any). All it really needed to meet our needs was the ability to do templating and a little more freedom in configuration. There are two classic ways of coding templates. The first, which Apache can support natively, is wrapping a header and footer around an HTML file fragment. Usually the header and footer contain the HTML start and end tags and the HEAD tags so the physical page cannot be read or verified by itself. It also cannot have a customized TITLE or META tags. However, this is usually the fastest and most light weight way to add templates. The other way is to have code embedded in the HTML pages that is parsed and executed by the server as the page is served. This is extremely powerful and is the most common way of generating templates. However, it is also very memory and processor intensive and generally complex. We needed something in between. Something powerful, yet simple and friendly enough that coders of any skill level could use it and light weight so it didn't bog down our server. With only slight changes to the original B I was able to meet all of those needs as well as giving volunteers the ability to affect the navigation in their areas. This has many benefits (no one person is saddled with maintaining the navigation) and downsides (it's a significant amount of responsibility to be placed in the hands of volunteers and a concern in enforcing consistent page styles and appearances). The original B worked by wrapping all the HTML code between the starting and ending tags in a where the first row contained table cells with navigation links. I modified this so that it not only wrapped that HTML code but overwrote the tag to guarantee a uniform appearance. Additionally, it uses a sophisticated set of tables to create a header, vertical left navigation bar and footer with contact information. Note that this set of tables was the same as that created by the original ASP. Instead of the static table used by the original ASP and the per-directory configuration variables used by the original B used for navigation links, the new B looks in the same directory as the requested page for a file named navConf.txt (the format for this file will be described below) with a series of links for navigation. It translates those links into a table cell to be used in the vertical navigation bar. All style information for this is hard coded in the module in the B subroutine. If no file is found then no nav is made. Next it loads two template files, one for the header (or top) and one for the footer (or bottom) and pastes them below and above the starting and ending tags, respectively. The page's tag is overwritten by the template tag. This template tag and exact pasting locations are hardcoded into the module and are described by a series of regular expressions in the B subroutine. The tag is parsed and its contents is added to the top of the page after the templatized HTML header as a header. The style for this is hard coded into the module in the B subroutine. =head1 CONFIGURATION After reading the above, you're probably wondering what's left to be configurable and how to do it. The header, footer and links in the navigation area are all configurable via files. This causes some difficulty as style and content information is spread in several places (four to be exact, two files for the header and footer, one file for the navigation and the contents of the module itself) but I haven't yet figured out a way around it. As you might guess, most of the development has been driven by immediate need and inspired by God. Very little, if any, of the hardcoded style is set in stone and can be modified to suit the needs of the site. =head2 Header and Footer The header and footer for each page is configurable on a per-directory basis (if need be) by configuration variables in the Apache httpd.conf file. The variable is B and is set with the following syntax: PerlSetVar TBTemplate F/F F is relative to the server root and B expects
