Re: How to build apache/mod_perl/mod_ssl

2001-09-14 Thread Blair Zajac

If you're on RedHat 7.1, the easiest way is to go to

ftp://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/

and just download and install the packages.  They don't have a
current version of mod_perl though.

You may have the also update your glibc to 2.2.4.

Blair

[EMAIL PROTECTED] wrote:
 
 Hi,
 
 I have the sources of:
 
 apache 1.3.20
 openssl-0.9.6b
 openssl-engine-0.9.6b
 mod_ssl-2.8.4-1.3.20
 mod_perl-1.26
 
 How do I build them? I have tried ./configure --help in all but it seems
 they are all inter-reliant on each other and it seems impossible to build
 apache and enable mod_perl and mod_ssl, or I have no idea how to do it.
 
 I'm using Red Hat Linux 7.1 on an Intel x86 (Celeron).
 
 Thanks heaps.
 James



Pre-announce Apache::ConfigParser

2001-09-12 Thread Blair Zajac

Hello,

This is a preannounce of Apache::ConfigParser.  I wrote this to
allow programs separate from Apache to completely understand,
parse and manipulate Apache configuration files.

The interface is not simple, but it allows for more complicated
understanding of log files, such as finding the associated ServerName
for log files.

There are two separate modules described here.  The first manages
a single directive and the second assembles these into an object
that represents a complete configuration file.

Comments welcome, including the name of the module.

It's available now at

http://www.orcaware.com/perl/Apache-ConfigParser-0.01.tar.gz

and will be up on CPAN if there are no serious comments.

Regards,
Blair




NAME
 Apache::ConfigParser::Directive - An Apache directive or start
context


SYNOPSIS
 use Apache::ConfigParser::Directive;

 # Create a new emtpy directive.
 my $d = Apache::ConfigParser::Directive-new;

 # Make it a ServerRoot directive.
 # ServerRoot /etc/httpd
 $d-name('ServerRoot');
 $d-value('/etc/httpd');

 # A more complicated directive.  Value automatically splits the
 # argument into separate elements.  It treats elements in 's
as a
 # single ement.
 # LogFormat %h %l %u %t \%r\ %s %b common
 $d-name('LogFormat');
 $d-value('%h %l %u %t \%r\ %s %b common');

 # Get a string form of the name.
 # Prints `logformat'.
 print $d-name, \n;

 # Get a string form of the value.
 # Prints `%h %l %u %t \%r\ %s %b common'.
 print $d-value, \n;

 # Get the values separated into individual elements. 
Whitespace
 # separated elements that are enclosed in 's are treated as a
 # single element.  Protected quotes, \, are honored to not
begin or
 # end a value element.  In this form protected 's, \, are no
 # longer protected.
 my @value = $d-get_value_array;
 scalar @value == 2;   # There are two elements in this
array.
 $value[0] eq '%h %l %u %t \%r\ %s %b';
 $value[1] eq 'common';

 # The array form can also be set.  Change style of LogFormat
from a
 # common to a referer style log.
 $d-set_value_array('%{Referer}i - %U', 'referer');

 # This is equivalent.
 $d-value('%{Referer}i - %U referer');

 # There are also an equivalent pair of values that are called
 # `original' that can be accessed via orig_value,
 # get_orig_value_array and set_orig_value_array.
 $d-orig_value('%{User-agent}i agent');
 $d-set_orig_value_array('%{User-agent}i', 'agent');
 @value = $d-get_orig_value_array;
 scalar @value == 2;   # There are two elements in this
array.
 $value[0] eq '%{User-agent}i';
 $value[1] eq 'agent';

 # You can set undef values for the strings.
 $d-value(undef);


DESCRIPTION
   The Apache::ConfigParser::Directive module is a subclass
   of Tree::DAG_Node, which provides methods to represents
   nodes in a tree.  Each node is a single Apache configura­
   tion directive or root node for a context, such as Direc­
   tory or VirtualHost.  All of the methods in that module
   are available here.  This module adds some additional
   methods that make it easier to represent Apache directives
   and contexts.

   This module holds a directive or context:

 name
 value in string form
 value in array form
 a separate value termed `original' in string form
 a separate value termed `original' in array form
 the filename where the directive was set
 the line number in the filename where the directive was set

   The `original' value is separate from the non-`original'
   value and the methods to operate on the two sets of values
   have distinct names.  The `original' value can be used to
   store the original value of a directive while the
   non-`directive' value can be a modified form, such as
   changing the CustomLog filename to make it absolute.  The
   actual use of these two distinct values is up to the
   caller as this module does not link the two in any way.

METHODS
   The following methods are available:

   $d = Apache::ConfigParser::Directive-new;
   This creates a brand new Apache::ConfigParser::Direc­
   tive object.

   It is not recommended to pass any arguments to new
   to set the internal state and instead use the follow­
   ing methods.

   There actually is no new method in the Apache::Con­
   figParser::Directive module.  Instead, due to
   Apache::ConfigParser::Directive being a subclass of
   Tree::DAG_Node, Tree::DAG_Node::new will be used.

   $d-name
   $d-name($name)
   In the first form get 

Re: Pre-announce Apache::ConfigParser

2001-09-12 Thread Blair Zajac

I missed the Apache-Admin-Config module in my search for Apache config
file parsers, otherwise I would have not written a new one :)  The
other parser was just announced after I finished this one is named
Apache::ConfigFile.

All three modules appear to treat the directives and contexts the
same, in that you can descend into the contexts to get directive's
specified there.

They could definitely be merged into a single module that does what
everybody needs.  I don't have the time to do this myself, but would
could help out.

A common API would have to be designed so that it would have all of the
features people needed.  Here's a quick review of the pluses and minuses
of the tree modules (obviously pro Apache::ConfigParser because it has
the features I need).

Apache::Admin::Config
Pros

Cons
Lack of documentation
Test suite with 2 tests

Apache::ConfigFile
Pros
Clear interface
Good documentation
Handles mod_perl Perl config directives
Overloaded method names to get config values
Automatic boolean conversion
Been around for a while
Cons
Test suite with one test

Apache::ConfigParser
Pro
Good documentation
Build tree structure of config allowing complicated
searches
Parses config file exactly as Apache does
Knows which directives can take relative path names
and makes them absolute automatically
Correctly parses directive values with 's and \'s
Allows searches on directives regardless of context
Allows searches up through context levels
Extensive test suite
Keeps track of where directives were set

Cons
Doesn't write out config files
No autoloaded calls
Not easily used interface

Is it possible to remove CPAN modules when a common interface is built?

Blair

Geoffrey Young wrote:
 
 
 
 -Original Message-
 From: Blair Zajac
 To: [EMAIL PROTECTED]
 Sent: 9/12/01 5:41 PM
 Subject: Pre-announce Apache::ConfigParser
 
 Hello,
 
 This is a preannounce of Apache::ConfigParser.  I wrote this to
 allow programs separate from Apache to completely understand,
 parse and manipulate Apache configuration files.
 
 BTW, I appreciate you posting an RFC, mainly because I feel as though the
 Apache module list has grown rapidly of late (which is not necessarily a bad
 thing) but grown without that many RFCs, feedback, or attempts to build on
 what others have already done.
 
 that said, is this all that different from
 CPAN/modules/by-module/Apache/Apache-Admin-Config-0.05.tar.gz
 ?
 
 I swore there was yet a third candidate in this realm, but I didn't see it
 on brief inspection.
 
 at any rate, can the two somehow be integrated into some mutually acceptable
 module?
 
 --Geoff