Apache::Session::DB_File cleanup issue

2012-04-03 Thread James B. Muir
Hi All,

I'm using Apache::Session::DB_File to manage some sessions via a mod_perl2 
handler and Apache2. I'm running into difficulties trying to read stored data 
in the sessions db while writing a  cleanup cron job to remove old sessions. 
The following code snippet illustrates the problem:

use strict;
use warnings;
use Fcntl;

use MLDBM qw(DB_File Storable);

use Data::Dumper;

tie my %sessions, MLDBM, './sessions.db', O_RDWR|O_CREAT, 0666 or die $!;

(tied %sessions)-DumpMeth('portable'); # use Storable::nfreeze

my @keys = map { print $_\n; $_; } (keys %sessions);

print Dumper( \%sessions);

untie %sessions;

I am unable to read the stored data when I run the above code. I get the 
following output -- two session keys (OK) and mysterious error message when I 
try to dump out a session:

perl cleanup.pl
e7324413d95fe51f1ac7e74a89b17b47
f72ec1ed349c7140e9f37087e04cd703
Not a SCALAR reference at 
/usr/local/lib/perl5/site_perl/5.8.8/MLDBM/Serializer/Storable.pm line 28.

I inspected both MLDBM and Apache::Session::DB_File and it looks to me like 
they both use Storable::thaw to unserialize the data. Any ideas why I am 
getting this message?

-James



IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


FW: Cannot retrieve empty keys from request using Apache2::Request.param

2012-01-03 Thread James B. Muir
How about a little perl string manipulation?

#my $a = 'key1=value1key2=key3=value3';
my $a = 'key1=value1key2key3=value3';

my $b = join , map { my $c = ($_ =~ m/(\S+)=(\S*)?/o) ? $_ : $_=; $c; } 
split , $a;

print a= $a\nb= $b\n;

-James

-Original Message-
From: Randolf Richardson [mailto:rand...@modperl.pl]
Sent: Tuesday, January 03, 2012 1:13 PM
To: mod_perl list
Subject: Re: Cannot retrieve empty keys from request using 
Apache2::Request.param

 Tommaso Torti wrote:
  Hi all,
 
  i'm using mod_perl in order to retrieve all keys from a POST request with:
 
  my $request = Apache2::Request-new($r);
  my $data = $request-param();
 
  When i receive something like
  key1=value1key2=key3=value3
  $data contains all 3 keys
 
  but with
  key1=value1key2key3=value3
  $data contains only 2 keys: key1 and key2key3
 
  Is there a way to retrieve all the 3 keys like the first case? Any 
  suggestions?
  Thank you,

 As far as I know, there isn't a way, because the browser will not send any 
 data for an
 input field that is empty in the form.

 If you want to do that, then you would need some javascript inside the form, 
 which fills
 the empty fields with some dummy sequence (like --empty--), before 
 posting the form.
 Then your module/script would need to catch such fields, and consider them as 
 empty.

Interesting.  I suppose one could use the GET method to verify
whether $request-param() shoots blanks or undefs.

Filling in fields seems like a lot of work though, and using
JavaScript to fill in those fields with dummy data won't be
compatible with anything.  A better approach would be to just include
a hidden input element with the same name at some point after the
user's input field:

input type=hidden name=key2 value=--empty--

But, I'd rather use this approach instead, if possible:

input type=hidden name=key2 value=

The beauty of this solution is that calling $request-param() in
scalar context returns the first value, but if the POST method really
isn't passing along blanks then the hidden input element's value will
be in first place instead.

However, I strongly suspect that this really is not the right
solution.

Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer  Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/



IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law.  If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited.  If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


RE: mod_perl output filter and mod_proxy, mod_cache

2011-07-14 Thread James B. Muir
I had to bolt on an input servlet filter to tomcat once. To do this I had to 
write the servlet filter code and then add filter and filter-mapping tags 
to the application WEB-INF/web.xml file.
-James


-Original Message-
From: Tim Watts [mailto:t...@dionic.net]
Sent: Thursday, July 14, 2011 8:12 AM
To: mod_perl list
Subject: Re: mod_perl output filter and mod_proxy, mod_cache

On 14/07/11 12:43, André Warnier wrote:
 Hi.

 I have to apologise.
 I misunderstood your first post, and I wanted to verify on the Tomcat
 list, so I quoted the following passage of your first post in my message
 there :

 Sadly, the tomcat dev's forgot to set any caching headers in the HTTP
 response (either Expires, Last-Modified or Cache-control) so the sites
 are largely uncacheable by browsers and the various tomcats are becoming
 overloaded.

 Unfortunately, the Tomcat Dev's there took it rather seriously, and as a
 consequence now you name is shit on the Tomcat list.


 .. just kidding, I did not quote your name.

LoL - I hate tomcat anyway (for it's fatness) so I don't mind if they
hate me ;-

I should have clarified as my Department's dev team (ie the ones who
use tomcat here) rather than the Tomcat Developers themselves...

I have no doubts that jsp can be told to emit certain headers but for
some reason a lot of web developers IME often miss the finer points of
HTTP. This of course would be the correct place to do it as they can
choose different max-age times to suit the content.

I plan to run a 20 minute seminar on this specific point for my lot (and
more such seminars for other issues like security and SQL efficiency)
but that still leaves loads of old black-boxes to manage for a few years.

 Anyway, apart from a few huffed responses to my misquote (since then
 rectified), someone provided a suggestion that may not be the simplest,
 but might be helpful anyway in some cases :

 Have a look at : http://www.tuckey.org/urlrewrite/

 This is a Java Servlet Filter, which can be added transparently
 around any Tomcat web application (by adding the required section in
 the web.xml config file of that web application).
 Java Servlet Filters are such that the Tomcat web application is not
 even aware that it is there, and continues to work as before. Much like
 Apache input and output filters in fact, except that a Java Servlet
 Filter is both at the same time (it wraps the webapp on both sides).

That could be interesting too - as long as it's something I can bolt in
without having to recompile the webapp code, I'm game. As a linux
sysadmin, I draw a clear line between the systems (my problem) and the
apps (dev team) - and not knowing java (much) I'm not qualified to mess
with their stuff... I'm happy to go as far as messing with server.xml
and web.xml though :)

 Anyway, this filter can do such things as conditionally or not adding
 response headers to anything the webapp produces. And it can do much
 more, as with time it has evolved into some kind of mish-mash of
 mod_rewrite, mod_headers and mod_proxy.

 It is more one-by-one work than doing something at the Apache front-end
 level or via a proxy, but it also provides better fine-tuning
 possibilities.
 So, if you can for instance easily identify the worst offenders, it
 might be an option.

 And it is certainly a good tool to have in one's toolcase.

I agree - I'll have a look at that after I play with Alex's suggestion
of Varnish :)

Thanks very much for your time :)

all the best,

Tim

--
Tim Watts
Personal Blog: http://www.dionic.net/tim/

IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law.  If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited.  If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


RE: Changing browser URL based on condition

2011-07-11 Thread James B. Muir
I think you need to do a redirect. From within your mod_perl handler try 
something like this:

$r-content_type(text/plain);

$r-headers_out-set(Location=$url);

return Apache2::Const::HTTP_TEMPORARY_REDIRECT;


From: Jerry Pereira [mailto:online.je...@gmail.com]
Sent: Monday, July 11, 2011 2:48 PM
To: modperl@perl.apache.org
Subject: Changing browser URL based on condition


Hi All,

I would like to know if there is a way to change the URL displayed on
browser without using Redirect option. The URL visible on client browser
must be based on some condition that is evaluated in my mod_perl handler.

For example -

1. User types the URL - www.example.comhttp://www.example.com/, this will 
display the login page.
2. Once the user enters the credentials and hits submit, the request is
posted to www.example.com/loginhttp://www.example.com/login action.
3. If the credentials entered by the user is valid then i would like to show
the home page..uri
4. I am able to show the homw page, but the URL does not change to
www.example.com/homehttp://www.example.com/home, instead it remains the same 
(i.e.
www.example.com/loginhttp://www.example.com/login). I am using Template 
toolkit to render my pages. I
tried $req-url('/home'), but that does not change the browser URI.

Any help will be appreciated.

Thanks,
Jerry

IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


RE: Best approach to store Application Configuration

2011-07-11 Thread James B. Muir
This page describes pretty well how to set up custom configuration directives; 
perhaps helpful?

http://perl.apache.org/docs/2.0/user/config/custom.html

-James

From: Jerry Pereira [mailto:online.je...@gmail.com]
Sent: Monday, July 11, 2011 5:08 PM
To: modperl@perl.apache.org
Subject: Best approach to store Application Configuration

Hi All,

I am new to mod_perl (a java developer). I would like to know the best approach 
to store and retrieve Applicaiton configurations that is accessible to all 
packages in my mod_perl application.

My application configuration includes - Database details, Template mapping, 
LDAP configuration details etc. I would like my to load all these 
configuratoins when my application starts and then on, i should be able to 
access these configuration from anywhere.

For Example:
my $dbDetails = ConfigUtil-getDBDetails(); //returns reference to hash
my dbUser = dbDetails-user;

I belive PerlSetVar only allows strings variables. I would like to get some 
suggestions on how configuration management in mod_perl applications.

Thanks,
Jerry

IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


RE: Best approach to store Application Configuration

2011-07-11 Thread James B. Muir
The PerlSetVar overhead occurs on every request, whereas the overhead 
associated with using the custom configuration occurs once when Apache is 
started.
-James


-Original Message-
From: Fred Moyer [mailto:f...@redhotpenguin.com]
Sent: Monday, July 11, 2011 5:35 PM
To: Michael Peters
Cc: James B. Muir; Jerry Pereira; modperl@perl.apache.org
Subject: Re: Best approach to store Application Configuration

On Mon, Jul 11, 2011 at 2:23 PM, Michael Peters mpet...@plusthree.com wrote:
 On 07/11/2011 05:16 PM, James B. Muir wrote:

 This page describes pretty well how to set up custom configuration
 directives; perhaps helpful?

 http://perl.apache.org/docs/2.0/user/config/custom.html

 I would almost always avoid this kind of configuration and go with an
 external configuration file. Every project of any decent size will have some
 scripts or processes that don't run under mod_perl and thus can't use this
 apache-only configuration.

This kind of configuration has the advantage of avoiding the overhead
associated with PerlSetVar if I recall correctly.  The downside is
that the custom config directives can be a bit tricky to setup
correctly.

 As for configuration in Perl if I were starting a new project, I'd probably
 go with something like Config::Any and then pick a backend format.

+1

IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law.  If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited.  If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


RE: apache2 or mod_perl2 oddball error

2011-06-21 Thread James B. Muir
Getting back to basics... Are you sure that your build of Apache and perl went 
well? Have you scrutinized the logs you created when you built perl and apache 
for any surprising error messages?
-James


-Original Message-
From: William Bulley [mailto:w...@umich.edu]
Sent: Tuesday, June 21, 2011 12:51 PM
To: Andr? Warnier
Cc: mod_perl list
Subject: Re: apache2 or mod_perl2 oddball error

According to Andr? Warnier a...@ice-sa.com on Tue, 06/21/11 at 12:05:

 Right, but what that page is showing, is the syntax of the perl use
 some::module; directive, as used /inside of a perl program/.
 Here we are talking about the PerlModule directive, as used in a
 httpd.conf file (or another file included in it).

I got that.

 Although the effect of each of these instructions is quite similar, the
 allowable syntax in each case may be different.

 Referring again to the page
 http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlModule_

 One sees there an example of a PerlModule directive with several parameters
 after the PerlModule directive itself.  But these additional parameters
 are, all and each of them, names of perl modules (aka libraries) to be
 loaded.  They are /not/ additional parameters to the first named module.
 Damn, this is probably obscure for a non-perl practitioner.  Let me try
 again :

 in a line like
 use Apache2::Const -compile = ':common';
 (which you would use in a perl script, not in an Apache configuration file)
 - the use Apache2::Const part means : load the module Apache2::Const
 - and the -compile = ':common' part means : /in addition/ to loading the
 Apache2::Const module itself, also prepare a set of symbols from that
 module, so as to make them easier to use in the program which executes the
 use directive. (*)

I think the person who wrote these lines:

PerlModule Apache2::Const -compile = ':common'
PerlModule APR::Const -compile = ':common'

was trying to say: I'm only interested in those symbols associated with
the ':common' tag, so please load only those (in addition to the module).

But this is neither here nor there, since when I reduce those two lines to:

PerlModule Apache2::Const
PerlModule APR::Const

and re-run # apachectl -t the syntax is clean, but the server fails to
start (which was my original complaint):

Syntax OK
Attempt to free unreferenced scalar: SV 0x28be1014 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda578 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda7d0 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b3e8 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b050 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda730 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda4b0 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b3d4 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be176c during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda6cc during global destruction.
Attempt to free unreferenced scalar: SV 0x28be15dc during global destruction.


 On the other hand, in an Apache configuration file, you cannot use the
 use directive, you must use the PerlModule directive.  But this
 PerlModule directive has no valid syntax to allow the second part
 (-compile = ':common').

 Ok so far ?

I got that.

 So how would you find a way to tell Apache and mod_perl to load the
 Apache2::Const module, but /also/ do the -compile = ':common' part ?

 Fortunately, in Perl there is always more than one way to do it.
 That's where the already-named startup.pl script comes into play, along
 with the PerlRequire directive.

The include file in question has a Perl.../Perl section.  So I tried
putting the use...-common = ':common' inside there (two lines).  Then
running the apachectl(8) command, I got the same results as above.  Still
no joy.

I got farther along just by renaming the include file so that apache2
could not see it (but of course this screws the pooch for the application
in question).  After the renaming, # apachectl start succeeded.

 By using the Apache/mod_perl configuration directive
 PerlRequire /path/to/some/script.pl
 you tell Apache and mod_perl to also compile and run the named script,
 /during the Apache configuration phase/.  And in this script, you can use
 the line :
 use Apache2::Const -compile = ':common';
 (because in a Perl script the use directive /can/ be used, with the
 additional parameters and all).

See above.

 (Note: the name of this script is often startup.pl, but that is only a
 convention, and you can use any script name you like, as long as the
 PerlRequire directive points to it).

I do this for Perl applications that I write.

 (Note also that it does not matter that the rest of the application never
 references this script; it is executed /once/ during the configuration
 phase of Apache, and just sets things up 

RE: set environment variables in tomcat

2011-05-27 Thread James B. Muir
In order to pass an environment variable via mod_jk to tomcat you need to set 
the JkEnvVar in your jk.conf file.  For example,

JkEnvVar  REMOTE_USER   %{REMOTE_USER}

-James

From: Kim Goldov [mailto:kgol...@gmail.com]
Sent: Thursday, May 26, 2011 8:24 PM
To: modperl@perl.apache.org
Subject: set environment variables in tomcat

I'm connecting to a tomcat server from our web server using mod_jk. I'm setting 
environment variables with each request in the PerlAuthenHandler and 
PerlHeaderParserHandler. I'm able to read the variables in PHP, perl fcgi, and 
wsgi, however they are not being passed to tomcat. Is there a way to pass these 
environment variables through?

--
Kim

IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


Apache2::Cookie and cookie names

2011-05-19 Thread James B. Muir
Hi All,

In a modperl2 handler, using Apache2::Cookie, I have code as follows to fetch 
the names of the requests cookies:

my @cookie_names = (eval { $cookie_jar-cookies() });
if ($@) { _oops(Could not parse cookies blah blah.); }

I understand that with this code I either get all of the cookie names if they 
all can be parsed, or I get none of the cookie names if a parsing exception is 
thrown.

Is there a way to get the names of all of the cookies that could be parsed up 
until the exception was thrown? I've seen in other postings this nifty example 
for getting the cookie jar:

my $cookie_jar = eval { Apache2::Cookie::Jar-new($r) } || $@-jar;

I'm wondering if there might be something as succinct and elegant as this for 
getting the cookie names.
-James



IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


RE: libapreq2 build to /usr/lib64

2011-04-29 Thread James B. Muir
Ah, that looks simpler. Thanks.
-James


-Original Message-
From: Morten Bjørnsvik [mailto:morten.bjorns...@experian-da.no]
Sent: Friday, April 29, 2011 3:01 AM
To: James B. Muir; modperl@perl.apache.org
Subject: RE: libapreq2 build to /usr/lib64

Hi
I use the following when compiling libapreq:
(the vaiables are just paths to the dirs and bins)

Apache2::Request  2.13  libapreq2-2.13.tar.gz downloaded_201012171512 
$PERL_BIN Makefile.PL --with-apache2-apxs=$APXS_BIN --with-perl=$PERL_BIN 
--enable-lib64 --with-expat=$APACHE_DIR

--
MortenB


-Original Message-
From: James B. Muir [mailto:james.b.m...@hitchcock.org]
Sent: 28. april 2011 22:56
To: modperl@perl.apache.org
Subject: RE: libapreq2 build to /usr/lib64

I followed this lead earlier to today but it did not lead anywhere in this 
case. Thanks for suggesting it.

Fortunately I did find the solution. I added --libdir=/usr/lib64 to the 
./configure:

#!/bin/bash

cd /usr/local/src/libapreq2-2.13

env LDFLAGS=-L/usr/lib64 -R/usr/lib64 -lexpat ./configure --with-apache2-apxs=
/usr/sbin/apxs --enable-perl-glue --with-perl=/usr/bin/perl 
--libdir=/usr/lib64

make 
make test 
make install

-James


IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law.  If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited.  If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


libapreq2 build to /usr/lib64

2011-04-28 Thread James B. Muir
Hello,

I am receiving the following message from Apache2 after installing libapreq2 
and Apache2::Request:

/usr/sbin/apachectl -t
httpd: Syntax error on line 201 of /etc/httpd/conf/httpd.conf: Cannot load /etc/
httpd/modules/mod_apreq2.so into server: libapreq2.so.3: cannot open shared obje
ct file: No such file or directory

I think I'm getting this message because I'm having difficulties getting 
libapreq2 to install to the /usr/lib64 directory. I'm running:

Red Hat Enterprise Linux Server release 5.6 (Tikanga)
Kernel 2.6.18-238.5.1.el5 on an x86_64

Here is my build script:

# cat hdrs_config_libapreq2.sh
#!/bin/bash

cd /usr/local/src/libapreq2-2.13

env LDFLAGS=-L/usr/lib64 -R/usr/lib64 -lexpat ./configure --with-apache2-apxs=
/usr/sbin/apxs --enable-perl-glue --with-perl=/usr/bin/perl

make 
make test

When I issue the make install libapreq2 is installed in /usr/lib/ rather than 
/usr/lib64

# ls -lF /usr/lib/libapreq*
-rw-r--r-- 1 root root 342366 Apr 28 10:43 /usr/lib/libapreq2.a
-rwxr-xr-x 1 root root993 Apr 28 10:43 /usr/lib/libapreq2.la*
lrwxrwxrwx 1 root root 18 Apr 28 10:43 /usr/lib/libapreq2.so - libapreq2.so
.3.8.0*
lrwxrwxrwx 1 root root 18 Apr 28 10:43 /usr/lib/libapreq2.so.3 - libapreq2.
so.3.8.0*
-rwxr-xr-x 1 root root 204072 Apr 28 10:43 /usr/lib/libapreq2.so.3.8.0*

So I think my build script needs something. What am I missing?
-James



IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


RE: libapreq2 build to /usr/lib64

2011-04-28 Thread James B. Muir
I followed this lead earlier to today but it did not lead anywhere in this 
case. Thanks for suggesting it.

Fortunately I did find the solution. I added --libdir=/usr/lib64 to the 
./configure:

#!/bin/bash

cd /usr/local/src/libapreq2-2.13

env LDFLAGS=-L/usr/lib64 -R/usr/lib64 -lexpat ./configure --with-apache2-apxs=
/usr/sbin/apxs --enable-perl-glue --with-perl=/usr/bin/perl 
--libdir=/usr/lib64

make 
make test 
make install

-James

-Original Message-
From: Randolf Richardson [mailto:rand...@modperl.pl]
Sent: Thursday, April 28, 2011 12:13 PM
To: modperl@perl.apache.org
Subject: Re: libapreq2 build to /usr/lib64

 Hello,

 I am receiving the following message from Apache2 after installing libapreq2 
 and Apache2::Request:

 /usr/sbin/apachectl -t
 httpd: Syntax error on line 201 of /etc/httpd/conf/httpd.conf: Cannot load 
 /etc/
 httpd/modules/mod_apreq2.so into server: libapreq2.so.3: cannot open shared 
 obje
 ct file: No such file or directory

 I think I'm getting this message because I'm having difficulties getting 
 libapreq2 to install to the /usr/lib64 directory. I'm running:

 Red Hat Enterprise Linux Server release 5.6 (Tikanga)
 Kernel 2.6.18-238.5.1.el5 on an x86_64

 Here is my build script:

 # cat hdrs_config_libapreq2.sh
 #!/bin/bash

 cd /usr/local/src/libapreq2-2.13

 env LDFLAGS=-L/usr/lib64 -R/usr/lib64 -lexpat ./configure 
 --with-apache2-apxs=
 /usr/sbin/apxs --enable-perl-glue --with-perl=/usr/bin/perl

 make 
 make test

 When I issue the make install libapreq2 is installed in /usr/lib/ rather 
 than /usr/lib64

 # ls -lF /usr/lib/libapreq*
 -rw-r--r-- 1 root root 342366 Apr 28 10:43 /usr/lib/libapreq2.a
 -rwxr-xr-x 1 root root993 Apr 28 10:43 /usr/lib/libapreq2.la*
 lrwxrwxrwx 1 root root 18 Apr 28 10:43 /usr/lib/libapreq2.so - 
 libapreq2.so
 .3.8.0*
 lrwxrwxrwx 1 root root 18 Apr 28 10:43 /usr/lib/libapreq2.so.3 - 
 libapreq2.
 so.3.8.0*
 -rwxr-xr-x 1 root root 204072 Apr 28 10:43 /usr/lib/libapreq2.so.3.8.0*

 So I think my build script needs something. What am I missing?
 -James

I'm not sure if this is related, but on NetBSD a few months ago we
experienced a similar compile problem with pkgsrc.  If you search for
wrapper in the following web page, you'll see a solution that I
hope might help to provide some insight to a solution for you:

Cannot compile www/p5-libapreq2 package
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=43385

The work-around was to delete the package's work/.wrapper/bin/cc
and work/.wrapper/bin/ld files (so that the main/proper ones with
the OS are used?) between the make and make install commands.

(The reason for the p5- prefix is to classify it as being a part
of Perl 5, as I understand it; this is still the full libapreq2
package though.)

Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer  Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com



IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law.  If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited.  If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


Can't locate object method STORE via package APR::Request::Param::Table

2011-02-25 Thread James B. Muir
Hello,

I am using the excellent Apache2::Request module.

I'm writing a mod_perl2 authen handler. I'd like to be able to modify the value 
of, or delete, a parameter and then allow the request to be further processed 
by the mod_jk response handler.

Based on my reading it looks like it should be easy to handle requests sent 
with the GET method. However, I've also got to be able to handle the POST 
method. Based on my testing of the POST method I see the following error 
message in the apache2 error log:

Can't locate object method STORE via package APR::Request::Param::Table

My reading suggests to me that it is not possible to modify the value of, or 
remove, a parameter in the body of a POST request and pass that modified body 
to mod_jk.

Is this true?
-James


IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


RE: POST method and PerlAuthenHandler

2011-02-02 Thread James B. Muir
I've got Apache2::Request working and POST requests are working very nicely.

Thanks for steeing me in the right direction!
-James



From: Joe Schaefer [joe_schae...@yahoo.com]
Sent: Thursday, January 27, 2011 11:12 AM
To: James B. Muir; modperl@perl.apache.org
Subject: Re: POST method and PerlAuthenHandler

Use apreq.

From: James B. Muir james.b.m...@hitchcock.org
To: modperl@perl.apache.org modperl@perl.apache.org
Sent: Thu, January 27, 2011 11:08:24 AM
Subject: POST method and PerlAuthenHandler

Hello,

I am writing a perl authentication module for Apache2 that must inspect some 
request parameters before authorizing the requestor and forwarding the request 
to a tomcat server via mod_jk.

With the GET request method this is easy, I can inspect the parameters using 
$r-args and forward the request.

With the POST request method I can READ the request body, but it appears that 
the request body is removed from the request and is not forwarded to tomcat via 
mod_jk. Is this correct?

How do I inspect POST request parameters without modifying the request?

I know there must be a standard way to do this kind of thing but I have been 
unable find the answer after several hours of reading.
Thank you for your help.
-James





IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


POST method and PerlAuthenHandler

2011-01-27 Thread James B. Muir
Hello,

I am writing a perl authentication module for Apache2 that must inspect some 
request parameters before authorizing the requestor and forwarding the request 
to a tomcat server via mod_jk.

With the GET request method this is easy, I can inspect the parameters using 
$r-args and forward the request.

With the POST request method I can READ the request body, but it appears that 
the request body is removed from the request and is not forwarded to tomcat via 
mod_jk. Is this correct?

How do I inspect POST request parameters without modifying the request?

I know there must be a standard way to do this kind of thing but I have been 
unable find the answer after several hours of reading.
Thank you for your help.
-James





IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.


build of libapreq2 fails

2011-01-27 Thread James B. Muir
Hi, I am trying to build libapreq2 so that I may use it with Apache2 and 
mod_perl. I'm on a Solaris 10 system. The version of Apache I am using is old:

./bin/apachectl -v
Server version: Apache/2.0.59
Server built:   Aug 22 2006 11:38:34

I receive the following surprising errors during the build of libapreq2:


gmake[2]: Entering directory `/opt/sfw/libapreq2-2.13/module'
/bin/bash ../libtool --tag=CC   --mode=link gcc  -g -O2 `/usr/local/libapreq2-2.
13/apreq2-config --link-libtool`  -L/usr/local/apache2/lib -laprutil-0 -L/usr/lo
cal/apache2/lib -lapr-0  -o test_cgi test_cgi.o
gcc -g -O2 -o .libs/test_cgi test_cgi.o  /opt/sfw/libapreq2-2.13/library/.libs/l
ibapreq2.so -L/usr/local/apache2/lib /usr/local/apache2/lib/libaprutil-0.so /usr
/local/apache2/lib/libapr-0.so -lsendfile -lrt -lm -lsocket -lnsl -lresolv -lpth
read  -R/usr/local/apache2/lib
Undefined   first referenced
symbol in file
XML_Parse   /usr/local/apache2/lib/libaprutil-0.so
XML_ParserCreate/usr/local/apache2/lib/libaprutil-0.so
XML_ErrorString /usr/local/apache2/lib/libaprutil-0.so
XML_SetUserData /usr/local/apache2/lib/libaprutil-0.so
XML_ParserFree  /usr/local/apache2/lib/libaprutil-0.so
XML_GetErrorCode/usr/local/apache2/lib/libaprutil-0.so
XML_SetCharacterDataHandler /usr/local/apache2/lib/libaprutil-0.so
XML_SetElementHandler   /usr/local/apache2/lib/libaprutil-0.so
ld: fatal: Symbol referencing errors. No output written to .libs/test_cgi
collect2: ld returned 1 exit status
gmake[2]: *** [test_cgi] Error 1
gmake[2]: Leaving directory `/opt/sfw/libapreq2-2.13/module'


I recently installed libexpat to /usr/local/lib.

ls -lF libexpat*
-rw-r--r--   1 root root  492744 Dec 14 16:23 libexpat.a
-rwxr-xr-x   1 root root 816 Dec 14 16:23 libexpat.la*
lrwxrwxrwx   1 root root  17 Dec 14 16:23 libexpat.so - 
libexpat.so.1.5.2*
lrwxrwxrwx   1 root root  17 Dec 14 16:23 libexpat.so.1 - 
libexpat.so.1.5.2*
-rwxr-xr-x   1 root root  305504 Dec 14 16:23 libexpat.so.1.5.2*

Does anyone have any idea why I am seeing the undefined symbols when I build 
libapreq2? Do I need to rebuild apache to resolve this?
This is the script I am using to build libapreq2:

#!/usr/bin/bash

# Make sure we can get to gcc, but not cc. Set the path
# to find the gcc compiler in /usr/local/bin.
# Use the GNU make in /usr/sfw/bin/

PATH=/usr/local/bin:/usr/sfw/bin:/usr/sbin:/usr/bin:/usr/ccs/bin
export PATH

cd /usr/local/libapreq2-2.13

perl Makefile.PL --with-apache2-apxs=/usr/local/apache2/bin/apxs

gmake


Thanks for any input on this matter,
-James


IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and 
may contain information that is privileged, confidential, and protected from 
disclosure under applicable law. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.