Re: [announce] mod_perl-1.99_01

[Stas Bekman]

John Siracusa wrote:
> You might want to reconsider the use of VT escape codes in the build
> process.  The red error message was cute, but there's a big potential
> downside (see attached screenshot).
> 
> In the words of the W3C's CSS validator: "You have no background-color with
> your color" :)

sigh :(

the idea was to make certain messages more outstanding, so people
will pay attention to warnings and errors. In your examples warnings
are not really seen on certain terminals, which is worse than using the 
default fg color.
I've tried using on_white for bg and the results are bad.

Currently we use:

%colors = (
 emerg   => 'bold white on_blue',
 alert   => 'bold blue on_yellow',
 crit=> 'reverse',
 error   => 'bold red',
 warning => 'yellow',
 notice  => 'green',
 info=> 'cyan',
 debug   => 'magenta',
 reset   => 'reset',
 todo=> 'underline',
 );

I've changed my gnome-terminal prefs to use black as bg and white as fg, 
and it was pretty much OK with the current colours, darker colours being 
less visible.

I guess what's important is to have at least 2 additional to the default 
colors for warnings and errors. It seems that 'bold red' will be 
perfectly seen on pretty much any background (but red :). Apparently 
yellow is not a good choice. Any better suggestions for cross background 
fg color? refer to the Term::ANSIColor manpage for more options.

Please play with
Apache-Test/lib/Apache/TestTrace.pm and see if you can come up with a 
better solution.

I've searched google, but didn't find any info regarding Term::ANSIColor 
and suggesting good cross-platform, cross-terminal colors.

Thanks.

__
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

Disabling Perl*Handlers in .htaccess?

[karnurme]

Hello!

How to enable only PerlSetVar/PerlAddVar directives in .htaccess files?

More specific:

We are building an multiuser environment with mod_perl to our
campus. Mod_perl handlers contain especially PerlHandlers configured in
httpd.conf. The .htaccess files are used for authorization (require
user/group) and some tailoring (PerlSetVar/PerlAddVar) allowed for all
users at their home directories.

However, the security risks are quite obvious when .htaccess contains
directives like PerlHandler:

PerlHandler "sub {`touch /tmp/xxx`}"


How to enable only PerlSetVar/PerlAddVar directives in .htaccess files?

-- 

Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547

Re: Leak error

[John Kolvereid]

Hi Nicolai,
   I had installed mod_perl w/ apache earlier. 
Problems arose whe I then tried to add php and/or ssl.
At this point I am not sure what DSO is.  I do know
that when I compile Apache, the 1st thing it says is
that DSO is installed.  But then I don't know how to
specifically install any of the modules as DSO.  Any
advice?  Thanks.

--- Nicolai Schlenzig <[EMAIL PROTECTED]> wrote:
> Maybe - but not likely...
> 
> If you think it's mod_perl causing problems - why
> don't you drop ssl and php
> for now (as suggested earlier)? Well - maybe even a
> just basic Apache to
> start with. If that works - move on and get mod_perl
> installed. When you are
> satisfied with that you can start looking into ssl
> and php.
> 
> My current install is with mod_perl, mod_php, and
> mod_ssl, it all as DSO -
> and I am very unhappy with mod_perl being a DSO. I
> had many problems
> installing ssl together with mod_perl, so for the
> being I choose to make it
> DSO just to have something running. When I get some
> time again I will built
> in mod_perl in my httpd and maybe even ssl. PHP will
> stay as DSO I think...
> maybe I will try compile it into my httpd as well.
> 
> The bottom line is: don't take your mouth ful...
> 
> Start with basics... then slowly move on... you have
> to crawl before you
> walk - and so on ;)
> 
> Best of luck again
> 
> // Nicolai
> 
> - Original Message -
> From: "John Kolvereid" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, April 06, 2002 7:08 PM
> Subject: Leak error
> 
> 
> > Hello again,
> >I have noticed that when I try to build
> mod_perl I
> > get a bunch of parse errors when the 'make' is in
> the
> > /Leak directory.  Could this be the reason that I
> am
> > unable to build mod_perl and ssl and php
> > simultaneously.  Please advise.  Thanks.
> >
> > John Kolvereid
> >
> > __
> > Do You Yahoo!?
> > Yahoo! Tax Center - online filing with TurboTax
> > http://taxes.yahoo.com/
> >
> 


__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

mod_perl-2 Win32 ppm package

[Randy Kobes]

I placed a Win32 ppm package of mod_perl-2, compiled against
httpd-2.0.35 with ActivePerl 631, in our ppm repository.
Installing it as
ppm install \
http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl-2.ppd
should also run a post-install script to install mod_perl.so in
your Apache2 modules/ directory. If this doesn't work, you can
download mod_perl-2.tar.gz from
http://theoryx5.uwinnipeg.ca/ppmpackages/x86/
and extract mod_perl.so from there. This package was built so
that the Apache Perl modules will be installed under an Apache2/
subdirectory; to use, you should place a 'PerlModule Apache2' in
httpd.conf, or else 'use Apache2 ()' in a startup script. Some
html docs on mod_perl-2 are included in the package which should
be placed in your Perl html tree.

best regards,
randy kobes

Re: mod_perl 1.99 and Apache::compat

[Doug MacEachern]

On Sun, 7 Apr 2002, Dave Rolsky wrote:

> On Sun, 7 Apr 2002, Dave Rolsky wrote:
> 
> > I also found a few tiny bugs in Apache::compat.
> >
> > - The read() call in send_fd_length needs to be CORE::read.
> >
> > - In the last elsif in size_string, the size variable is missing its
> > dollar sign ($).
> 
> Here's a patch:

thanks, applied.  figures the 1 file we didn't have 'use strict' in.  
that's in there now too, which caught another bug in send_fd_length.

Re: [ANNOUNCE] Cache::Cache 1.0

[DeWitt Clinton]

On Sun, Apr 07, 2002 at 08:52:59PM +0300, Issac Goldstand wrote:

> So how exactly is the auto_purge meant to be used - the
> documentation is very hazy on that point (sure I can patch it - but
> you have to explain it to me first :)), and I just got lost when
> looknig at the module source.

The auto_purge functionality is designed to enable a cache to delete
expired cache entries periodically.  While user code could call the
purge( ) method every time they access the cache, it would be rather
inefficient and often completely unnecessary.  Thus the auto_purge
code automatically calls purge( ) after a user specified interval of
time has elapsed.

You set the amount of time between auto_purges by setting the
'auto_purge_interval' option when instantiating the cache.

After setting the 'auto_purge_interval' the purge method will be
called when a cache instance is created (via 'new') and the time
interval has elapsed.

Also, by setting 'auto_purge_on_set' to true, the cache will
automatically call purge when the 'set' method is called and the time
interval has elapsed.

Respectively, by setting 'auto_purge_on_get' to true, the cache will
automatically call purge when the 'get' method is called and the time
interval has elapsed.

If you tend to instantiate caches relatively frequently (such as
during the initialization of a modperl process), you can probably get
away with simply setting the 'auto_purge_interval'.  However, if you
processes run for a long time and you'd like to automatically call
purge( ) more frequently, you can could consider using the
'auto_purge_on_set' option.  I'd be surprised if people were using the
'auto_purge_on_get' functionality, as it would most likely be
overkill. 

Also, keep in mind that if you hit the same keys over and over again,
then it may be sufficient to rely on 'get' to delete expired entries
when they are requested.

Hope this helps clarify things!  Cheers,

-DeWitt

Re: mod_perl 1.99 and Apache::compat

[Dave Rolsky]

On Sun, 7 Apr 2002, Dave Rolsky wrote:

> I also found a few tiny bugs in Apache::compat.
>
> - The read() call in send_fd_length needs to be CORE::read.
>
> - In the last elsif in size_string, the size variable is missing its
> dollar sign ($).

Here's a patch:

--- compat.pm.~1.35.~   Sat Mar 23 20:38:01 2002
+++ compat.pm   Sun Apr  7 14:19:46 2002
@@ -259,7 +259,7 @@
 $len = IOBUFSIZE;
 }

-while (read($fh, $buff, $len)) {
+while (CORE::read($fh, $buff, $len)) {
 $total_bytes_sent += $r->puts($buff);
 }

@@ -369,7 +369,7 @@
 elsif ($size < 1048576) {
 $size = sprintf "%4dk", ($size + 512) / 1024;
 }
-elsif (size < 103809024) {
+elsif ($size < 103809024) {
 $size = sprintf "%4.1fM", $size / 1048576.0;
 }
 else {

mod_perl 1.99 and Apache::compat

[Dave Rolsky]

Well, here be a bug report

I compiled Apache 2.0.35 with mod_perl 1.99 as a DSO.  The server will
start just fine with that.

I'm running on GNU/Linux with Perl 5.6.1.

If I add this:

 PerlModule Apache2
 PerlModule Apache::compat

The server simply will not start.

If I comment out all the 'use' statements, except for mod_perl and Symbol,
from Apache/compat.pm, then the server starts.

If I load all the modules I just commented out via PerlModule in the
config file and I _don't_ load Apache::compat, the server starts.

If I load all the modules I commented out and try to load Apache::compat
(with those use statements still commented out), the server will not
start.

I also found a few tiny bugs in Apache::compat.

- The read() call in send_fd_length needs to be CORE::read.

- In the last elsif in size_string, the size variable is missing its
dollar sign ($).



-dave

/*==
www.urth.org
we await the New Sun
==*/

Re: [ANNOUNCE] Cache::Cache 1.0

[Issac Goldstand]

DeWitt Clinton wrote:
[snip]
I've actually meanty to ask this for a while:  I'm curious as to the 
auto_purge functionality of Cache::Cache - especially under mod_perl... 
 I tend to use it a lot, but from time to time, which is basically EVERY 
time I look at /tmp, I notice bunches of stale entries from 
Cache::FileCaches - and that's on the development server.  So how 
exactly is the auto_purge meant to be used - the documentation is very 
hazy on that point (sure I can patch it - but you have to explain it to 
me first :)), and I just got lost when looknig at the module source.
So:
 1)What is it meat to do
 2) How should it be used
 3) What about constistancy issues between processes - when will perl 
forget what's in the cache and not clean it up?

Thanks,
  Issac

Re: Ordering in %INC for PerlRestart

[Ged Haywood]

Hi there,

On Tue, 2 Apr 2002, [iso-8859-1] Sreeji K Das wrote:

> I use PerlFreshRestart on to reload my modules.
[snip]
> However, here my modules are getting loaded before the
> PerlRequire'd is loaded (since %INC is a hash).
> 
> First, can some1 suggest a solution for this ?

I always stop (with SIGTERM) and start my servers rather than using
restart (SIGUSR1) as I find that there are fewer surprises.  I think
that Perrin will agree.  There are very few systems that can't cope
with a few seconds of downtime.

73,
Ged.

Re: PDF generation

[Thomas Eibner]

On Sun, Apr 07, 2002 at 02:11:39AM +0200, Patrick wrote:
> On Wed, Apr 03, 2002 at 03:43:39PM -0500, Bill McCabe took time to write:
> > I have a large number of mod_perl modules that connect to various databases and
> > generate workflow performance reports for my organization. I give the users 3
> > output options: HTML, Excel (Spreadsheet::WriteExcel), and PDF. For PDF output
> > I've been using PDF::Create, which has been at version .01 since 1999. It has
> > worked flawlessly for my purposes for a couple of years, but is very limited. In
> > fine form-follows-function fashion, the end users would now like the PDF output
> > gussied up with graphics, etc. Does anyone have any strong (positive or
> > negative) recommendations for which module(s) I should migrate to?
> 
> I do not use Perl modules to do that, but LaTeX.
> As ugly as it may sound it enables to output very complex PDF files,
> exactly the way you want.
> 
> More precisely I have LaTeX templates, I use CGI::FastTemplate to
> fill them in with dynamic data, run pdflatex, and then have a nice
> PDF file.

Sounds like an interesting solution, but how long does it take to
generate the pdf files? I need something that will insert data into
PDF's at certain positions (they may change) and I was looking wheter
it would be possible doing something like CGI::FastTemplate just for
PDF's. The "only" requirement would be that you could use _any_ program
that generates PDF's to generate these templates. So I built part of a
PDF parser that would extract the text portions of a PDF, but then I
found that a PDF generated by Adobe Distiller (just as an example)
generates text sections that look something like:
[(Kv)25.1(ar r)9.9(adioj mangxas la fla)20(v)24.8(a)]
for the "simple" text of "Kvar radioj mangxas la flava". 
Doesn't that just look hopeless to parse? I'm about to give up on this
solution, any comments?

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

[ANNOUNCE] Cache::Cache 1.0

[DeWitt Clinton]

Hi,

The following is an announcement of Cache::Cache 1.0.  Please read the
summary below for more details.

I want to ask a special favor of the modperl community (who tend to
get a lot of mileage out of this code) -- I'm concerned with the use
of Digest::MD5, particularly version 2.16, which is used by the code
to generate unique filenames in the file-based cache.  I've been
seeing some pretty ugly bugs with the the MD5 code, and this has been
confirmed on a few mailing lists and CPAN bug reports.  Please let me
know if you notice any weird behavior with your system after upgrading
to version 1.0.  (All unit test pass consistently, but under certain
conditions, such as when XML::DOM is loaded, I think that Digest::MD5
may always return the same hash, no matter what the key.)

Note that you can simply run Digest::MD5 2.12 and not 2.16 if you have
any issues in production.  So don't worry about upgrading to version
1.0 of Cache::Cache.

I'm thinking of switching to Digest::SHA1 in version 1.01 to avoid
this until a new version of Digest::MD5 is released.  Does anyone know
of a reason to avoid that?  (SHA1 is slightly slower, but very little
time in spent generating keys anyway, so it may not be a big deal.)

For more information on the MD5 issue, please see:

  http://rt.cpan.org/NoAuth/Bug.html?id=362.

Thanks to everyone for your help.  Cheers,

-DeWitt


Summary:

The Cache modules are designed to assist a developer in persisting
data for a specified period of time. Often these modules are used
in web applications to store data locally to save repeated and
redundant expensive calls to remote machines or databases. People
have also been known to use Cache::Cache for its straightforward
interface in sharing data between runs of an application or
invocations of a CGI-style script or simply as an easy to use
abstraction of the filesystem or shared memory.

Release Notes:

  Release of Cache::Cache version 1.0.  This version fixes outstanding
  issues on Win32 platforms and other minor bug fixes.
 
Project Homepage:

  http://perl-cache.sourceforge.net/

Tar/GZ:

  http://prdownloads.sourceforge.net/perl-cache/Cache-Cache-1.0.tar.gz
  http://www.cpan.org/authors/id/D/DC/DCLINTON/Cache-Cache-1.0.tar.gz
  
Changelog:

  http://sourceforge.net/project/shownotes.php?release_id=83292

CVS tree (viewcvs):

  http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/perl-cache/

The following is the Cache-Cache-1.0 README file:

Copyright (C) 2001 DeWitt Clinton  All Rights Reserved

   You may distribute under the terms of either the GNU General Public
   License or the Artistic License, as specified in the Perl README file.


NAME

  Cache::Cache


DESCRIPTION

  The Cache modules are designed to assist a developer in persisting
  data for a specified period of time.  Often these modules are used
  in web applications to store data locally to save repeated and
  redundant expensive calls to remote machines or databases.  People
  have also been known to use Cache::Cache for its straightforward
  interface in sharing data between runs of an application or
  invocations of a CGI-style script or simply as an easy to use
  abstraction of the filesystem or shared memory.

  The Cache package provides Cache::Cache, a generic interface
  for creating persistent data stores.  This interface is implemented
  by the Cache::MemoryCache, Cache::SharedMemoryCache, Cache::FileCache, 
  Cache::SizeAwareFileCache, Cache::SizeAwareMemoryCache, and 
  Cache::SizeAwareSharedMemoryCache classes. 

  This work aggregates and extends the obsolete File::Cache and
  IPC::Cache projects.


REQUIREMENTS

  Digest::MD5
  Error
  File::Spec
  File::Path
  IPC::ShareLite
  Storable


INSTALLATION

  perl Makefile.PL
  make
  make test
  make install


USAGE

  First, choose the best type of cache implementation for your needs.
  The simplest cache is the MemoryCache, which is suitable for
  applications that are serving multiple sequential requests, and
  wish to avoid making redundant expensive queries, such as an
  Apache/mod_perl application talking to a database.  If you wish to
  share that data between processes, then perhaps the
  SharedMemoryCache is appropriate, although its behavior is tightly
  bound to the underlying IPC mechanism, which varies from system to
  system, and is unsuitable for large objects or large numbers of
  objects.  When the SharedMemoryCache is not acceptable, then
  FileCache offers all of the same functionality with similar
  performance metrics, and it is not limited in terms of the number of
  objects or their size.  If you wish to maintain a strict limit on
  the size of a file system based cache, then the SizeAwareFileCache
  is the way to go.  Similarly, the SizeAwareMemoryCache and the
  SizeAwareSharedMemoryCache add size management functionality
  to the MemoryCache and SharedMemoryCache classes respectively.

  Using a cache is simple.  Here is some sample code for instantiating
  and using a file system bas

Re: [announce] mod_perl-1.99_01

[John Siracusa]

You might want to reconsider the use of VT escape codes in the build
process.  The red error message was cute, but there's a big potential
downside (see attached screenshot).

In the words of the W3C's CSS validator: "You have no background-color with
your color" :)

-John




not-so-clever.gif
Description: GIF image

Re: sun4-solaris polluted installation

[Ged Haywood]

Hi there,

On Sat, 6 Apr 2002, Slava Bizyayev wrote:

> a lot of mess in common perl libraries. What of that could affect the
> installation?

All sorts of things, but I'm still puzzled.  To my mind you do not
yet have enough evidence to point to a particular part of the system.

If your production system were not using Perl in any way I would
suggest that you delete the entire Perl installation and rebuild it
from scratch with 5.6.1.  (Actually I prefer 5.7.2 but I hesitate to
suggest it for production use even though it seems fine to me. :)  If
it were my machine that is what I would do, production or not, because
you really need to be able to rely on your Perl installation and at
the moment evidently you cannot.  Of course there is a risk that
something would break, so you might prefer to rename the old Perl
installation rather than delete it.  You should of course make sure
that the same compiler which built Perl also built mod_perl, for
preference also using the same C libraries.

Have you tried to run Perl's own 'make test' suite?

73,
Ged.