mod_perl and RedHat 6
I'm trying to migrate a server to a new machine running 64-bit RedHat 6. The stock RedHat setup is apache 2.2.15, php 5.3.3 and perl 5.10.1. Normally I build the latest Apache 2.2 and Perl/mod_perl in /usr/local and just use that. However, this server will also use Drupal so I figured I'd build PHP locally as well. I'm unable to get PHP 5.3 or 5.4 to link properly with the installed mysql, pcre and gd libraries (all of which are installed along with the devel packages), so I was thinking of just using the stock Apache and PHP and trying to build a newer mod_perl with the /usr/local/bin/perl which is 5.14.2. So I tried /usr/local/bin/perl Makefile.PL MP_APXS=/usr/sbin/apxs This compiles, but make test gives me this: Test Summary Report --- t/api/server_const.t (Wstat: 0 Tests: 6 Failed: 2) Failed tests: 5-6 Files=242, Tests=2614, 122 wallclock secs ( 1.30 usr 0.41 sys + 91.90 cusr 10.94 csys = 104.55 CPU) Result: FAIL Failed 1/242 test programs. 2/2614 subtests failed. I'm not sure how serious this failure is and whether I should consider installing the resulting mod_perl.so file instead of the stock one. I can always just use the stock Perl/mod_perl but I'd really prefer a newer Perl. Alternatively, I suppose I can try and set up a reverse proxy to run the Drupal stuff on the stock Apache and mod_perl stuff on the custom Apache/mod_perl, but I expect I'll run into complications there with various virtual hosts and such. Any suggestions? Thanks, Dan
Re: mod_perl and RedHat 6
On Tuesday, May 01, 2012 10:51:40 am Fred Moyer wrote: t/api/server_const.t (Wstat: 0 Tests: 6 Failed: 2) I'm not sure how serious this failure is and whether I should consider The RedHat Apache uses a custom server signature so there is a bit of a mismatch on that test. Nothing to worry about, you can install and it will work fine. Thank you, that's a big help
Question about caching
Hello, I'm looking at upgrading some legacy code that runs under mod_perl with an eye towards making it more scalable. I understand the value of having one light-weight server for static content, and a reverse proxy back to a heavy-weight Apache with mod_perl, and I understand I can use something like Varnish or mod_cache to add a caching layer, but I'm wondering if there is much if any value to caching templates at the application level. The apps are mostly dynamic forms based on HTML::Template. H::T has some caching options but they seem more aimed at CGI users. I could convert to Template::Toolkit, which as I understand converts to compiled Perl code (which would presumably mean that mod_perl would leave the template objects in memory). So does anybody recommend going down to the application level to cache templates (either by tinkering with HTML::Template or trying to pre-load TT objects), or is there more bang for the buck by focusing on the server level? Or is both the way to go? Not sure where diminishing returns kicks in. Thanks, Dan
Building mod_perl for authentication
I've now tried various version of Perl (5.10.1, 5.12.4, 5.14.1), and various version of Apache, but I'm unable to get Apache to run when mod_perl is installed. The error logs show symbol lookup error: /usr/local/lib/perl5/site_perl/5.14.1/x86_64- linux/auto/ModPerl/Util/Util.so: undefined symbol: Perl_xs_apiversion_bootcheck This is from an earlier attempt to test more recent versions of Perl, which seemed to do everything I need OK. That led me to remove ./site_perl/5.14.1 altogether, so at least I'm able to run Apache version 2.2.21 with Perl 5.12.4 and mod_perl 2.0.5. However authentication still doesn't work. When I call $r-user in my authenticaion script for a URL that uses basic authentication, I don't get the login pop-up at all, and $r-user returns a value of ' (single quote) when I run make test in mod_perl, the logs show: *** The following error entry is expected and harmless *** [Sat Oct 08 08:27:58 2011] [error] [client 127.0.0.1] custom die hook: Undefined subroutine TestError::runtime::no_such_func called at /home/daxtell/src/mod_perl-2.0.5/t/response/TestError/runtime.pm line 150.\n [Sat Oct 08 08:28:03 2011] [error] [client 127.0.0.1] user stas: authentication failure for /: Password Mismatch *** The following error entry is expected and harmless *** [Sat Oct 08 08:28:08 2011] [error] [client 127.0.0.1] need AuthName: /TestModperl__setauth [Sat Oct 08 08:28:15 2011] [error] [client 127.0.0.1] Undefined subroutine TestHooks::error::bomb called at /home/daxtell/src/mod_perl-2.0.5/t/hooks/TestHooks/error.pm line 21.\n [Sat Oct 08 08:28:15 2011] [error] [client 127.0.0.1] Undefined subroutine TestHooks::error::bomb called at /home/daxtell/src/mod_perl-2.0.5/t/hooks/TestHooks/error.pm line 21.\n Any thoughts on why this would suddenly stop working? Also, is there any reason not to try and use Perl 5.14.2 with mod_perl? Thanks, Dan
Building mod_perl 2.0.5
Hi, I'm trying to upgrade some 64-bit Linux servers and though I'd upgrade Perl as well. I've built the latest Apache (2.0.21), Perl (5.14.2) and mod_perl (2.0.5), but mod_perl fails three tests: api/request_rec filter/out_str_reverse err_headers_out When I went ahead and installed this on a test server, some stuff worked but some custom authentication handlers failed. The last time I built everything from source I used Perl 5.10.1 and mod_perl 2.0.4, I believe. Is there a recommended version of Perl to use when building mod_perl? Thanks, Dan
Re: Building mod_perl 2.0.5
On Friday, October 07, 2011 04:35:08 pm Fred Moyer wrote: On Fri, Oct 7, 2011 at 1:15 PM, Dan Axtell daniel.axt...@snet.net wrote: That version of Apache is the legacy 2.0.x branch. Any chance you can upgrade to 2.2.x? Some of the authentication handling changed IIRC. I'm sorry, I meant to say I'm building Apache 2.2.21, mod_perl 2.0.5., perl 5.14.2 I wanted to upgrade Apache because of some of the recent security holes found.
Authentication and cookies
I'm trying to upgrade mod_perl authentication/authorization handlers for
application menu to be more fine-grained by using cookies. The basic idea is
- restrict a script alias in httpd.conf with basic authentication calling the
custon handlers
- validate the user ID/password in the authentication handler, and look up
role and client access info; stash in cookie. If a valid cookie is already
there, authenticat
- in authorization, check for cookie, reset if it's not there, and authorize
based on role and client information
- in menu app, check for cookie, and configure output depending on user's
role.
What happens is that even though the browser shows a cookie with the correct
info, the menu ends up with a no cookie found error, and the logs show
neither the authorization handler nor app are seeing the cookie. Hitting
refresh on the menu shows both handlers seeing the cookie and the menu comes
up correctly.
I've tried using both CGI::Cookie and Apache2::Cookie; I get the same problem
either way. Currently the authentication handler sets the cookie as follows:
my $cookie = Apache2::Cookie-new($r, -name = 'ls_authentication',
value = { user_id = $user, digest = crypt($password,
$salt), role_id = $ur{role_id}, clients = $client_list });
if ($cookie) {
$cookie-bake($r);
} else {
warn Unable to make cookie;
}
I get no warning, and the cookie looks fine in the browser's debug tool, but
the next handler and app just don't see it. This is how I try and read it in
the authorization handler:
my $jar = Apache2::Cookie::Jar-new($r);
my $cookie = $jar-cookies('ls_authentication');
if ($cookie) {
$have_cookie = 1;
my %fields = $cookie-value;
if ($fields{'user_id'}) {
$user = $fields{'user_id'};
}
if ( $fields{'role_id'} ) {
$user_role = $fields{'role_id'};
}
if ( $fields{'clients'} ) {
@user_clients = split(/,/, $fields{'clients'}); # turn client
list back into array
}
warn AUTHORIZATION: found cookie, user ID = $user, user role =
$user_role if $DEBUG;
} else {
warn AUTHORIZATION: NO COOKIE FOUND if $DEBUG;
}
I'm running Perl 5.12.1, Apache 2.2.17 and libapreq2 2.13 built from source.
Is using 'bake' insufficient to make the cookie visible by the next handler?
I've tried using both
$r-err_headers_out-set('Set-Cookie', $cookie);
and
$r-err_headers_out-addt('Set-Cookie', $cookie);
but I get the same problem.
Does anyone know of any up to date demos of using cookies in mod_perl2
authentication handlers?
Re: Authentication handlers in a proxy setting
To do access control for static files while still using your mod_perl auth handler, take a look at mod_auth_tkt or perlbal. Thanks!
Re: Authentication handlers in a proxy setting
It would be more logical to do the authentication on the front-end server. Then, if the back-end server needs the result of the authentication, you could add an appropriate HTTP header (with the user-id and maybe more stuff) to the request, before proxying it to the back-end. The idea is that (supposedly) the communication between the front-end and the back-end happens on a secure or private channel, so if the back-end gets this header, it knows it comes from the front-end. Getting the content of a request header is pretty light-weigth, so the work to do on the back-end for AAA could be minimal, since it can believe what the front-end tells it. That makes sense, but the Apache documentation on server configuration suggests a very light-weight front end server with the heavy-weight perl server on the back end. It seems like a lot of overhead to have mod_perl on the front end purely for authentication; I might as well keep the monolithic configuration I have now. Thanks for the input, though, it helps clarify things. Dan
Authentication handlers in a proxy setting
Hi, I wrote some mod_perl handlers for authentication and authorization, basically to set cookies and check user roles. I use them for both static and dynamic content from Perl scripts. I'm looking into splitting Apache into two servers, one optimized for static content and acting as a reverse proxy for the dynamic content Apache server. I understand that in the static httpd.conf, I can do things like: ProxyPass /perl/ http://dynamic.server:8080/perl/ ProxyPassReverse/perl/ http://dynamic.server:8080/perl/ and in the dynamic server's httpd.conf, I can add ScriptAlias and Location directives to call my authentication handlers. What I don't understand is what to do about static directories that want to use the handlers via Directory directive, or via a local .htdocs file. Does any such directory need to be forwarded to the dynamic server in order to then call the handlers? Thanks, Dan
Re: mod_perl compilation problem
Did you remove all previous perl build fragments that may have been compiled without -fPIC? That is, can you try a clean install with a prefix like /home/myuser/testperl, and then try to build mod_perl against that perl installation? I'll try that next. Question: my home box is opensuse 11.0 and it comes with perl 5.10 + mod_perl for and AMD x86_64. Can I just upload the mod_perl.so binary, or will small differences like the perl binary being in different locations stop it from working?
mod_perl compilation problem
I'm still trying to figure out how to build mod_perl on an AMD x86_64 system. It's running gcc 4.1.1 on Red Hat 4.1.1-52. Perl 5.8.8 + Apache + mod_perl is already installed, but I wanted to try and build everything with 5.10 because I've read that the RedHat Perl binaries are sometimes very slow, and I want to check out some of the Perl 5.10 features on a new server. I'm building Perl with these options: Configure -de -Dprefix=/usr/local -Accflags=-fPIC Perl builds, tests, and seems to run fine. When I make mod_perl, I get this error: /usr/bin/ld: /usr/local/lib/perl5/5.10.0/x86_64-linux/CORE/libperl.a(gv.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/perl5/5.10.0/x86_64-linux/CORE/libperl.a: could not read symbols: Bad value collect2: ld returned 1 exit status If I'm building Perl explicity with -fPIC, why does mod_perl think I'm not? I suppose I can live with 5.8.8, but there should be a way to build this. Dan
Re: Compiling Perl + mod_perl on 64-bit linux
On Tuesday 26 August 2008 7:14:35 am you wrote: I had something that sounds the same. Setting CCFLAGS didnt work, but sh ./Configure -de -Accflags='-fPIC' (etc) did give a libperl that worked on AMD x86_64. With 5.10 though. OK, I tried this: sh ./Configure -de -Accflags='-fPIC' -Dprefix=/usr/local \ -Dloclibpth=/usr/lib64 one peculiarity of my make, gnu make 3.81, is I have to edit the makefile to comment out all the lines like: av$(OBJ_EXT): command-line or it won't work. So make works, make test works, but gives various warnings like: makefile:612: target `lib/auto/Encode/Byte/Byte.a' given more than once in the same rule. makefile:612: target `lib/auto/Encode/CN/CN.a' given more than once in the same rule. After installing, if I try and run a CGI script with /usr/local/bin/perl, from the command line, I get: Attempt to free unreferenced scalar: SV 0xda2bf0 at /usr/local/lib/perl5/site_perl/5.8.8/HTML/Template.pm line 916. Weak references are not implemented in the version of perl at /usr/local/lib/perl5/site_perl/5.8.8/CGI/FormBuilder.pm line 15 This script ran yesterday with the Perl 5.8.8 I had build all the modules with. Trying to run perl -MCPAN also seg faults. What gives? -fPIC seems to make the interpreter useless, but I can't build mod_perl without it. Dan
Re: Compiling Perl + mod_perl on 64-bit linux
On Tuesday 26 August 2008 2:28:46 pm Niels Larsen wrote: I dont have a good answer. But editing the Makefile may hide the real error .. which error appears when not editing the Makefile, and Google with that error, no hints? what happens if -Dloclibpth=/usr/lib64 is omitted? and of curiosity, what was the reason for going back to perl 5.8 from 5.10? (i feel 5.10 is less stable than 5.8, but doesnt get in my way). I think if I leave out /usr/lib64, perl won't compile. I've tried so many variations they kind of blend together The make command gives this error: make: *** No rule to make target `command-line', needed by `miniperlmain.o'. Stop doing make -f Makefile let's perl compile, except for x2p, which gives a similar error. I've worked around this by taking out lines from the makefile like: av$(OBJ_EXT): command-line The main reason for wanting 5.8.x is I have some legacy apps that use CGI::Builder, which won't compile under 5.10. At this point I'm going to focus on getting it to build on 5.10, since that actually has a working mod_perl binary for my AMD64 box. Thanks for the help so far.
Compiling Perl + mod_perl on 64-bit linux
Hi, I've recently upgraded my main linux machine, but unfortunately the distribution (OpenSuse 11.0, AMD x86_64) has everything with Perl 5.10. I have some software that runs under mod_perl that requires Perl 5.8.8. No problem, I just build 5.8.8, right? Well, after two days I was able to get Perl and all my modules to build, but mod_perl won't link with this error: /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: /usr/local/lib/perl5/5.8.8/x86_64-linux/CORE/libperl.a(perl.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompilewith -fPIC /usr/local/lib/perl5/5.8.8/x86_64-linux/CORE/libperl.a: could not read symbols: Bad value I'm trying to recompile Perl with -fPIC, but I can't get it to build at all now. So trying to understand some basics here: what are the Perl requirements? Should Perl be built with static or dynamic libraries? Thanks, Dan
Re: Compiling Perl + mod_perl on 64-bit linux
You will need to compile perl with -fPIC on x86_64, I think I did it with: ccflags='-fPIC' sh Configure -Dprefix /path to perl I can't remember _exactly_ if that was it though. The other options would be to manually the edit the Makefiles but I don't remember having to do that. OK, I've gone through the Configure process several times. With the latest, I'm able to make, test and install Perl but it won't run anything, much less build mod_perl, as it gives this error: Attempt to free unreferenced scalar: SV 0xb4e570 at Makefile.PL line 34. BEGIN failed--compilation aborted at Makefile.PL line 34. I've built Perl with no threads, dynamic loading, DynaLoader is using dl_dlopen, -fPIC, and shared libperl.so. I've tried building it without dynamic loading, but it won't build. I've tried building Perl with no dynamic loading, same results. Any ideas?
Re: [slightly OT] Catalyst? Maypole?
On Friday 20 January 2006 12:19 pm, Jonathan Vanasco wrote: Personally, I dislike RoR intensely - part from the language, part from the implementation, and part from the cultish following that just seems like a bunch of kool aid drinkers all too often. Maypole and Catylst are both interesting, but I'm really not a fan of all the automagic object relational stuff (which i think they share with RoR). I think its great for small projects, but for larger things I think it actually complicates stuff. I've been meaning to look at Catalyst, but I'm pretty happy with the CGI::Builder framework, which is very flexible, is pretty well integrated with other CPAN tools such as session management and templates modules, and more or less follows the Apache request cycle. It started out as an improved CGI::Application clone but is much better and more flexible.
Using MP2 and CPAN modules
Hi, my server is running Apache 2.0.54 and MP 2.0.2. I'm trying to become familiar with the environment, but I get the impression most CPAN modules really want to run under Apache 1.X. In particular, I installed Apache::SessionManager, but can't get Apache to restart when I add the config lines PerlModule Apache::SessionManager PerlTransHandler Apache::SessionManager I get the error Can't locate Apache/Const.pm when Apache tries to load SessionManager. I know that the SessionManager module is requiring modules like Apache::Const, Apache::RequestRec, Apache::SubRequest, etc. which all exist on my system as Apache2::*. I've tried using those but I get another set of errors. I'm not confident of my ability to rewrite this module to get it working. So I'm wondering in general, should I downgrade to Apache/mod_perl version 1 if I want to use CPAN modules? Or is MP2 really becoming the preferred environment? Thanks, Dan
More on Apache::SessionManager/MP2
OK, so I followed the guidelines and changed mod_perl, Apache2::*, constants, etc. I had to uncomment a reference to Apache2::Connection so references to $r-connection-remote_ip() would work. At that point, I can restart the server and load SessionManager, but the minute I try to connect to localhost, I get a 404 error and the logs show only File does not exist: (null). This is merely from loading the module, not actually using it for anything. So at this point it seems like the module is really unusable, at least for mere mortals like myself.
Re: [mp2] Re-using POST data between input handler/filter
I'm currently having a similar problem with mod_perl 2.0.2 and Apache2::AuthCookie 3.08. Adding enctype = application/x-www-form-urlencoded to the form doesn't help. AuthCookie is losing the login form variables when it's set up with the POST method. In the code, the form submit handler is using $r-setup_client_block; return unless $r-should_client_block; These seem to be no longer supported under mod_perl 2, so I'm trying to find a work around. If your authentication system is using AuthCookie that might be the problem. Dan
Getting started with Apache::AuthCookie
Hi, I'm new to mod_perl programming, and I'm trying to write an authentication/authorization system under mod_perl 2.0. I've been suing mod_auth, but I need a database-driven system and mod_auth_mysql won't complie on my system (that's another story). I'm trying to use Apache2::AuthCookie to build a cookie-based, data-driven authentication system with custom login screen, etc. I'm finding myself very confused by the process. I've read the man page, but I don't quite get how the login form is connected to a submit handler, or where the submit handler goes (in the module? in a script?). Does anyone know where I can can get a working example? I've tried looking at the code generated to test the module, but I can't even get the basic login form to come up. I've google around but the only thing I find are variations on the man page. Any suggestions? Thank, Dan
Re: Class::DBI and CGI::Application under mod_perl
I started using CGI::Application a while ago and found it pretty easy to use. I think you might look into using CGI::Builder, which is basically the same idea but more flexible and with lots of nice extensions for various templating systems, etc.
