Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]
Another thing that can be done is keep the app server + DB inside your LAN and place a reverse proxy on your DMZ, that adds some level of protection. Rafael On Feb 9, 2021, 2:08 PM -0500, Clive Eisen , wrote: On 9 Feb 2021, at 18:45, James Smith wrote: It doesn't matter what db - and whether you wrap it in eval it is a problem (postgres has a similar problem - the one with least problems is MySQL) - if you have a secure environment where your databases are in a firewalled zone it will happen to all of them... It's a nasty bit of networking - it does mean our meant to be secure enterprise level apps running against Oracle and less secure and less stable than the other apps we have (go figure!)… 20 years ago I had exactly this argument with Amex when we wanted to use it for payment on the site I then worked for. They said put a firewall between the app and db layerx I said it's a dedicated nic/vlan on both sides and the ONLY port that is open is the db - what is a firewall going to add to that. Eventually they agreed. Security people who say firewall firewall firewall will solve all your security issues (or even some of them) are useless. Most of them do it by the book - which should in all case just be the starting point. Just my 2p — C
Re: setHandler question
Andre,
Ryan Gies wrote:
On 12/14/2012 8:52 AM, André Warnier wrote:
I suppose that in the end I will want to do something like this :
my $finfo = $r-finfo();
# do something to $finfo to set the flag
$r-finfo($finfo);
$r-handler('modperl');
$r-set_handlers(PerlResponseHandler = \_my_response_handler);
but how do I do something to $finfo ?
Or am I totally off-track here ?
TIA
For what it's worth, I have consistent success in using $r-finfo to
tell Apache the final destination. In the case that $you_want_to_hook
(below) is false, Apache will also serve the intended file. The timing
used is:
PerlMapToStorageHandler
$r-filename($path); # where $path is an absolute file-system path
$r-finfo(APR::Finfo::stat($path, APR::Const::FINFO_NORM, $r-pool));
return Apache2::Const::OK;
PerlFixupHandler
if ($you_want_to_hook) {
$r-push_handlers(PerlResponseHandler = \_response_handler);
$r-handler('modperl');
return Apache2::Const::OK;
}
Let me explain better what I am looking for :
LocationMatch /IIS_app/(.*)$
PerlAuthenHandler SLC-authenticate
PerlAuthzHandler SLC-authorize
PerlSetVar SLC_login_page /public/login.html
...
ProxyPassMatch http://localhost:8800/$1
/LocationMatch
In other words,
- Apache+mod_perl is acting as a reverse proxy for an application running under
IIS on the
same server
- but this IIS application requires a special HTTP header to authenticate the
user
- In the Location above, the PerlAuthenHandler checks if the user is
authenticated.
- If yes, it adds the required HTTP header to the request, and then a few
steps later
the proxying happens to IIS, and that's fine.
- If not, it sends back a login page.
What I want to do refers to the sends back a login page.
In case the user is not authenticated, I do /not/ want Apache to proxy the call
to IIS.
I want to reset the response handler so that it is no longer mod_proxy, but
mod_perl, and
my own PerlResponseHandler (which sends back the login page
/public/login.html, after
munching on it).
But what happens is that the proxying runs anyway, and the request ends up in
IIS, but
without the authentication header.
That's what I want to avoid.
What you want works for me when reverse proxying to Tomcat or another Apache by
adding a
require valid-user inside the LocationMatch
Regards,
Rafael Caceres
Re: acces control via cookies for webdirectories again
Timon, I'd suggest you take a look at Apache2::AuthTicket, and either use it 'as is' or add ad-hoc info to the cookie at creation time. Handler setup would be there and you could also be sure that the id cookie has not been tampered with. Regards, Rafael Caceres - Original Message - From: Timon Roth timon.r...@digitalforce.ch To: modperl modperl@perl.apache.org Sent: Wednesday, March 14, 2012 2:57:38 AM Subject: acces control via cookies for webdirectories again hello list i habe tried also a second scenario with the PerlProcessConnectionHandler and the PerlPreConnectionHandler. i must then first read the header from the client via the socket. thats very cool. but how can i then route the client forward to the desired page he initially used wanted to see? thans for any help and suggestions! greets, timon -- Timon Roth, Triemlistrasse 92, 8047 Zürich +4143 8174031,+4179 6365728, skype: timon.roth timon.r...@digitalforce.ch, www.digitalforce.ch http://tel.search.ch/zuerich/triemlistrasse-92/timon-roth
Looking for an Apache::Sandwich replacement for mod_perl2 / Apache2
Hi, I've been trying to move a site which uses Apache::Sandwich to Apache2/mod_perl2. I'm having trouble replicating the functionality on mod_perl2. Is anyone aware of such a replacement module, or one that could be modified for this purpose? Regards, Rafael Caceres
Is Apache2::Layout compatible with Apache 2.2.XX ?
Hi All, I am migrating a server from apache 1.3 with mod_perl1 to apache 2.2.x with mod_perl2. The Apache2::Layout module used usefull as a replacement/starting-point for getting Apache::Sandwich functionality. The Apache2::Layout module compiles, but the test results in core dumps. Is this module compatible with apache 2.2.x ? Regards, Rafael Caceres
Trivial changes to the Apache configuration result in segfaults for TWiki (installed as a mod_perl based application)
Hello All, I'm having a very strange problem with a mod_perl application: TWiki. Unrelated changes to the httpd.conf like adding an Alias or an Location section, or even adding or removing a comment result in segfaults in that application. Other applications, either cgi or Apache::Registry based applications keep working with no problem. Also unnafected is our mod_perl based Single Sign On. Has anyone seen something like this before? Rafael
Re: MP1 - MP2 migration Problems.
Andre, On Wed, 2008-02-13 at 23:00 +0100, André Warnier wrote: Of course, what I forgot to mention below - and sorry if you know that already - is that whichever perl modules you pre-load in your main Apache server config via the startup.pl script, you do not need to use anymore in all your perl scripts or Apache/mod_perl handlers. This is the first time that NOT using use because it was preloaded is mentioned. In fact, how would the modules compile (while testing for example)? (At the cost of having them (insibly) duplicated in all the children processes). Again, this is the first time this is mentioned. It would mean that, say 10 or 20 scripts under mod_perl using DBI,DBD::Oracle,CGI and Template would have the effect of using up to 20 times the memory footprint? Wasn't preloading suposed to do the exact opposite? I'm at a loss here But it may simplify your migration problems, and you can always tune this later. André Regards, Rafael Caceres
Re: [MP2] [QUESTION] authentication modules (reuse of mod_auth_basic, mod_auth_digest, mod_auth_ntlm) and cookies
authentication). Last but not least, my session tracking module has to be developed in Perl ! Thanks Gaetan Regards, Rafael Caceres
Re: Un-baking a baked cookie
Colin, At least with CGI.pm, what I do is 'bake' an empty cookie. That has the desired effect. Rafael Caceres On Fri, 2008-01-04 at 21:47 -0500, Colin Wetherbee wrote: Good evening. Is it possible to un-bake a baked cookie? From the Apache2::Cookie documentation, bake() adds a Set-Cookie header to the outgoing headers table. Is there a way to undo this without manually editing the headers, preferably with Apache2::Cookie methods? (As an aside, would somebody mind briefly explaining the difference between the Set-Cookie and Set-Cookie2 headers? Is Set-Cookie2 preferred now? Can it be implemented by just changing instances of bake() to bake2()?) Thanks. Colin !DSPAM:477ef043147221748623000! Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com
RE: seg faults when running modperl and GD::Graph
Matt,
I had the problem with PHP4, but you can do a quick test commenting the
LoadModule php5_module line on your httpd.conf file and testing before
going full course. If that prevents the crash, then my guess is you'll
have to build PHP5 yourself.
Rafael
On Tue, 2007-09-04 at 14:06 -0700, Matt Williamson wrote:
Ok, thanks.
I am not so familiar with php. I have
LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
And
IfModule mod_php5.c
AddType application/x-httpd-php .php .phtml .php3
AddType application/x-httpd-php-source .phps
/IfModule
So I guess I have mod_php5.
Do I have to recompile, or do you think I might find a php without GD as
a pre-compiled ubuntu package?
I actually don't think I need php on this system, would removing it have
the same effect?
Matt
-Original Message-
From: Rafael Caceres [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 04, 2007 1:38 PM
To: Matt Williamson
Cc: modperl@perl.apache.org
Subject: Re: seg faults when running modperl and GD::Graph
If you have PHP (with mod_php) enabled on that server, that's the
culprit and it can be fixed by compiling PHP without GD support.
On Tue, 2007-09-04 at 13:12 -0700, Matt Williamson wrote:
I noticed that my server is segfaulting when I run a script using
GD::Graph
e.g.
[Fri Aug 31 09:26:14 2007] [notice] child pid 6385 exit signal
Segmentation fault (11)
[Fri Aug 31 09:26:18 2007] [notice] child pid 6386 exit signal
Segmentation fault (11)
[Fri Aug 31 09:26:23 2007] [notice] child pid 6387 exit signal
Segmentation fault (11)
[Fri Aug 31 09:30:06 2007] [notice] child pid 6394 exit signal
Segmentation fault (11)
[Fri Aug 31 09:30:52 2007] [notice] child pid 6462 exit signal
Segmentation fault (11)
[Fri Aug 31 09:31:01 2007] [notice] child pid 6448 exit signal
Segmentation fault (11)
[Fri Aug 31 09:31:06 2007] [notice] child pid 6463 exit signal
Segmentation fault (11)
I am running an ex-cgi script under ModPerl::Registry
Location /perl
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
/Location
I have read some other places on the web about seg faults,
suggesting
that it might be conflicts with other modules, e.g. php. However, it
looks pretty clear that it is the GD::Graph that is doing it.
Has anyone else seen this? Does anyone know how to fix/debug this? I
am
going to try running my cgi with the PerlRun to see if that makes a
difference, although I'd prefer to run in modperl if I can.
Thank you in advance for your help
Matt
Information from NOD32
This message was checked by NOD32 Antivirus System for Linux Mail
Servers.
part000.txt - is OK
http://www.eset.com
!DSPAM:46ddc895252708074279129!
Information from NOD32
This message was checked by NOD32 Antivirus System for Linux Mail Servers.
part000.txt - is OK
http://www.eset.com
Re: seg faults when running modperl and GD::Graph
If you have PHP (with mod_php) enabled on that server, that's the culprit and it can be fixed by compiling PHP without GD support. On Tue, 2007-09-04 at 13:12 -0700, Matt Williamson wrote: I noticed that my server is segfaulting when I run a script using GD::Graph e.g. [Fri Aug 31 09:26:14 2007] [notice] child pid 6385 exit signal Segmentation fault (11) [Fri Aug 31 09:26:18 2007] [notice] child pid 6386 exit signal Segmentation fault (11) [Fri Aug 31 09:26:23 2007] [notice] child pid 6387 exit signal Segmentation fault (11) [Fri Aug 31 09:30:06 2007] [notice] child pid 6394 exit signal Segmentation fault (11) [Fri Aug 31 09:30:52 2007] [notice] child pid 6462 exit signal Segmentation fault (11) [Fri Aug 31 09:31:01 2007] [notice] child pid 6448 exit signal Segmentation fault (11) [Fri Aug 31 09:31:06 2007] [notice] child pid 6463 exit signal Segmentation fault (11) I am running an ex-cgi script under ModPerl::Registry Location /perl SetHandler perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlOptions +ParseHeaders /Location I have read some other places on the web about seg faults, suggesting that it might be conflicts with other modules, e.g. php. However, it looks pretty clear that it is the GD::Graph that is doing it. Has anyone else seen this? Does anyone know how to fix/debug this? I am going to try running my cgi with the PerlRun to see if that makes a difference, although I'd prefer to run in modperl if I can. Thank you in advance for your help Matt !DSPAM:46ddbc27171191804284693! Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com
Re: Trying to install mod_perl 2.0 on SUSE Linux 2.6 (Dual Processor)
On Tue, 2007-07-03 at 09:43 -0400, David Weintraub wrote:
I am attempting to install mod_perl on a SUSE Linux 2.6.6-7 dual
processor machine. It already has Apache 2.0.49 and Perl 5.8.3
installed. In fact, it already had perl_mod 1.x installed, but I decided
to install perl_mod 2.0.3.
The included perl with SLES is threaded, you probably want to build your
own perl. As for Apache 2, my advice is to also build it from source
yourself.
I copied mod_perl.so to /usr/lib64/apache2/mod_perl.so and made a
symbolic link to /usr/lib64/apache2-prefork/mod_perl.so. I modified
/etc/sysconfig/apache2 so that APACHE_MODULES includes perl.
SLES does not include/have the Apache2 source, so how did you build
mod_perl.so?
I was able to successfully install Mason 1.36 and mod_perl 2.0.3, I
tried to go through the documentation, and found out about the renaming.
However, when I restarted Apache, I got the error that
/etc/apache2/mod_perl-startup.pl failed.
I eliminated the use Apache2 (); statement and changed all instances
of Apache to Apache2 (which I believe I was suppose to do). I then
had problems with the ENV statement, changed it to look for
$ENV(MOD_PERL), and tried Apache again, but failed because
$ENV{MOD_PERL} is not defined.
Here's the /etc/apache2/mod_perl-startup.pl I am using:
$ENV{MOD_PERL} =~ /^CGI-Perl/ or die MOD_PERL not used!;
#use Apache2 ();
use lib qw(/srv/www/perl-lib);
# enable if the mod_perl 1.0 compatibility is needed
# use Apache::compat ();
use ModPerl::Util (); #for CORE::GLOBAL::exit
#use ModPerl::RequestRec ();
#use ModPerl::RequestIO ();
#use ModPerl::RequestUtil ();
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::RequestUtil ();
#use Apache2::Server ();
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Log ();
use APR::Table ();
use ModPerl::Registry ();
use Apache2::Const -compile = ':common';
use APR::Const -compile = ':common';
1;
Not even too sure what else I need to add. In fact, I am not even too
sure how Apache starts up. There's two scripts /etc/init.d/apache and
/etc/init.d/apache2, but there is nothing in /etc/init.d/rc.3 that calls
either of those scripts.
--
David Weintraub
[EMAIL PROTECTED]
Regards,
Rafael Caceres
Re: Growing Up
On Mon, 2007-04-16 at 12:21 -0700, Will Fould wrote: Hi, I have a service that is currently running a basic LAMP stack with mod_perl and life has been good! The site running has been getting very busy and I've ordered a second machine with intention to move the database off that machine and start the growing up process. I am looking for next steps to growing up from this machine. Can somebody recommend a good article, presentation or document that advocates various strategies to growing up the current architecture (i.e. basic load balancing, network topology, switches, etc. )? I realize that milage will vary based on the particular service and demands. Currently, the site does not deliver a lot of static content that can be cached or cause huge I/O issues (i.e. images, media, huge pages, etc). Our database is probably 95% read-only. Thanks a lot There is a consideration, regarding using a proxy or a different server, that has not been brought up: If there is mod_perl based access control for the static files, then it's basically impossible not to go through a mod_perl server to serve them. In fact, I'm not sure what the effect would be in that scenario if a proxy was used: would it serve the static file regardless of the access control?, does it depend on the expiration data on the headers sent through the proxy when the acess controled static file was sent? Rafael Caceres Analizado por ThMailServer para Linux.
Re: Apache::DBI questions
On Thu, 2007-03-29 at 10:57 -0400, Jonathan Vanasco wrote: On Mar 29, 2007, at 9:27 AM, Kelvin Wu wrote: 1. Do I still need to use 'use Apache::DBI;' in my script (or in startup.pl) if I already set 'PerlModule Apache::DBI' in httpd.conf? Putting it in startup.pl makes sure that memory sharing is maximized. 2. Will Apache::DBI work (caches and manages connections etc) if I dont change my CGI script DB calls but simply adding one line use Apache::DBI? In fact, just keep the 'use DBI;' in your CGI scripts, Apache::DBI works under the hood to make sure that IDENTICAL connections made from scripts under the same httpd child will use the same handles. Rafael Analizado por ThMailServer para Linux.
Re: Perl Authentication Handler and Cookie Issue
Sumit,
Fetching the cookie has nothing to do with the Perl handlers. They are
setting the cookie. You could check this with a small program such as:
#!/point/to/your/perl -T
include CGI;
use vars qw{$query}; #
use vars qw{$cookie};
$query = new CGI;
$cookie = $query-cookie(YOUR COOKIE NAME) || ;
print $query-header();
print cookie was:$cookie;
print $query-end_html();
Unfortunately, I'm not familiar with Java JSP, but do a search on 'java
cookies' to find out how to read cookies from Java.
Rafael
On Tue, 2007-02-20 at 11:56 -0500, Sumit Shah wrote:
Hello,
I did a small test to see if I can fetch the cookies without using
PerlAccessHandler and PerlAuthenHandler. I was able to fetch the cookies
using the following directive:
FilesMatch \.(html)$
*SetHandler perl-script
PerlHandler CAS::SSO
*/FilesMatch
and NOT if I use the following:
FilesMatch \.(jsp)$*
PerlAccessHandler CAS::SSO
*ErrorDocument 403
http://cas.gce2000.com/SecurityServices/JSP/SSOReLogin.jsp
/FilesMatch
or this:
FilesMatch \.(jsp|class)$
*AuthName realm
AuthType Basic
PerlAuthenHandler CAS::SSO
Require valid-user
*/FilesMatch
I would appreciate if someone could tell me the reason for this.
Thanks
Sumit
Sumit Shah wrote:
Hello,
I have modified my code to handle such scenarios. But the handler
still fails to fetch the cookies. The browser does pass the cookies. I
can see them in IEHTTPHeaders. I would appreciate if someone could let
me know why this could happen?
Thanks
Sumit
Robert Landrum wrote:
Sumit Shah wrote:
Hello,
I have a Mod Perl authentication handler and it needs to retrieve
the session id from a cookie. It is unable to retrieve any cookies
and I get the following error. It does not even print any of the
cookies. I would appreciate any help with this.
my $token = $cookies{'SessionID'}-value;
chomp($token);
$log-error(3. Session ID == $token);
You're trying to call a method against a value that may or may not
exist. That's a big no-no.
if(defined $cookies{'SessionID'}) {
$token = $cookies{'SessionID'}-value;
}
else {
$log-error(No SessionID cookie);
}
Rob
Analizado por ThMailServer para Linux.
!DSPAM:45db27a5188765526914969!
Analizado por ThMailServer para Linux.
Re: mod_perl2 make test fails various address related tests
On Wed, 2007-01-31 at 10:19 -0800, Philip M. Gollucci wrote: Rafael Caceres wrote: I'm doing a first pass at building mod_perl 2.0.3 for apache 2.0.59 with a SUSE Linux Enterprise Server 9. The server is configured not to use IPv6, apr was configured with --disable-ip6, apache 's config log says ac_cv_define_APR_HAVE_IPV6 = no and it was built with the --with-apr and --with-apr-util options pointing to the apr built with no IPv6 support. But, the logs for apache, as well as the mod_perl test logs show addresses completely different from the configured ones. This is causing a number of network address related tests in mod_perl2 to fail. Is there a way to force http and/or mod_perl to use and report ipv4 addresses? Any pointers will be appreciated. Thanks, Can you post some directory paths and ldd output for httpd bin/mp2bug will be sufficient too. Output of bin/mp2bug: 2. Used Components and their Configuration: *** mod_perl version 2.03 *** using /usr/sources/mpApache2.0/mod_perl-2.0.3/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB = aprext MP_AP_PREFIX = /usr/local/apache2 MP_COMPAT_1X = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 MP_USE_GTOP= 1 *** /usr/local/apache2/bin/httpd -V Server version: Apache/2.0.59 Server built: Feb 6 2007 00:00:43 Server's Module Magic Number: 20020903:12 Server loaded: APR 0.9.13, APR-UTIL 0.9.13 Compiled using: APR 0.9.13, APR-UTIL 0.9.13 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/usr/local/apache2 -D SUEXEC_BIN=/usr/local/apache2/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /usr/bin/ldd /usr/local/apache2/bin/httpd linux-gate.so.1 = (0xe000) libssl.so.0.9.7 = /usr/lib/libssl.so.0.9.7 (0x40029000) libcrypto.so.0.9.7 = /usr/lib/libcrypto.so.0.9.7 (0x40059000) libaprutil-0.so.0 = /usr/local/apr/lib/libaprutil-0.so.0 (0x40149000) libexpat.so.0 = /usr/lib/libexpat.so.0 (0x4015d000) libapr-0.so.0 = /usr/local/apr/lib/libapr-0.so.0 (0x4017d000) librt.so.1 = /lib/tls/librt.so.1 (0x4019c000) libm.so.6 = /lib/tls/libm.so.6 (0x401a4000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x401c6000) libnsl.so.1 = /lib/libnsl.so.1 (0x401f7000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0x4020b000) libdl.so.2 = /lib/libdl.so.2 (0x4021c000) libc.so.6 = /lib/tls/libc.so.6 (0x4021f000) /lib/ld-linux.so.2 (0x4000) *** (apr|apu)-config linking info -L/usr/local/apr/lib -laprutil-0 -lexpat -L/usr/local/apr/lib -lapr-0 -lrt -lm -lcrypt -lnsl -lpthread -ldl *** /usr/bin/perl -V Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=linux, osvers=2.6.5-7.282-default, archname=i686-linux uname='linux rcaceres5 2.6.5-7.282-default #1 tue aug 29 10:40:40 utc 2006 i686 i686 i386 gnulinux ' config_args='-Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -de' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.3.3 (SuSE Linux)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Locally applied patches: SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962 Built under linux Compiled at Jan 29 2007 01:52:38 %ENV
Re: mod_perl2 make test fails various address related tests
I'm doing a first pass at building mod_perl 2.0.3 for apache 2.0.59 with a SUSE Linux Enterprise Server 9. The server is configured not to use IPv6, apr was configured with --disable-ip6, apache 's config log says ac_cv_define_APR_HAVE_IPV6 = no and it was built with the --with-apr and --with-apr-util options pointing to the apr built with no IPv6 support. But, the logs for apache, as well as the mod_perl test logs show addresses completely different from the configured ones. This is causing a number of network address related tests in mod_perl2 to fail. Is there a way to force http and/or mod_perl to use and report ipv4 addresses? Any pointers will be appreciated. Thanks, Rafael Caceres Analizado por ThMailServer para Linux.
Re: Apache segfaults with Oracle AS10g (9.0.4.0) when attempting to use mod_perl
Maruthi, The only time anything is written to the logs is the case where the 'script.pl' under /perl has no XS components. In that case, no error or warning results. Any of the other cases mentioned in my initial posting results in absolutely nothing output to the logs (with LogLevel debug) and apache coredumps. Regards, Rafael Caceres On Wed, 2005-10-05 at 10:02 +0530, Maruthi Vara Prasad Chirravuri wrote: Hi, Can u send the /var/log/httpd/error.log and /var/log/messages output. Ch. Maruthi Vara Prasad. On 10/5/05, Rafael Caceres [EMAIL PROTECTED] wrote: When trying to use any mod_perl functionality in the Apache server included with Oracle AS10g under AIX 5.3, such as -'PerlModule Apache::Status' -'PerlModule Apache::DBI' or others using XS, Apache does a coredump. The same coredump occurs if no XS using module is loaded from httpd.conf but used in a script run from the /perl location. The same occurs if an XS using module is run with 'PerlRequire initial_load.pl' The PERL5LIB value is correctly set in the Apache httpd.conf, so that is not the problem. Oracle support has provided very little help to date, and mod_perl usage is critical for our SingleSignOn system. Any help is appreciated, Rafael Caceres !DSPAM:4343d6aa291741820910393!
Apache segfaults with Oracle AS10g (9.0.4.0) when attempting to use mod_perl
When trying to use any mod_perl functionality in the Apache server included with Oracle AS10g under AIX 5.3, such as -'PerlModule Apache::Status' -'PerlModule Apache::DBI' or others using XS, Apache does a coredump. The same coredump occurs if no XS using module is loaded from httpd.conf but used in a script run from the /perl location. The same occurs if an XS using module is run with 'PerlRequire initial_load.pl' The PERL5LIB value is correctly set in the Apache httpd.conf, so that is not the problem. Oracle support has provided very little help to date, and mod_perl usage is critical for our SingleSignOn system. Any help is appreciated, Rafael Caceres
setting REMOTE_USER with Apache::AuthCookie for use on a 2nd server through mod_rewrite
Hi, I need to place an application which requires REMOTE_USER to be set in an external non mod_perl enabled Apache reverse proxy that is called by an internal mod_perl enabled Apache through mod_rewrite. The idea is that a directory in the internal, mod_perl enabled server would have the following config: Directory /a/directory .. #Set $r-connection-user (REMOTE_USER) PerlFixupHandler Authcookie::Based-recognize_user RewriteEngine on RewriteRule ^/appname http:external.web.server/appname [P] /Directory to cause the external app to recognize the user when it executes. Is this possible? Rafael Caceres
Logs showing DBD::Oracle errors from nonexistant and/or unconnected apps
Hi, About a month ago, we started having our Apache (1.3.29,mod_perl 1.29) logs showing many DBD::Oracle errors (basically ORA-01001:Invalid Cursor, ORA-01007: variable not in select list, ORA-01461: can bind a LONG value only for insert in a LONG column, ORA-03120: two-task conversion routine - integer overflow) ocurring on the AuthTicket.pm module and an internal bugtrack.pl application running under Apache::Registry and using DBD::Oracle. The last change to them ocurred in march, and both are hitted hundreds of times per day. All applications connect to the same database, as the same user and with similar characteristics, and we use Apache::DBI. Checking the /var/log/messages file on the server, I've seen many similar to: Sep 13 08:10:47 intranet RT: DBD::Oracle::db prepare failed: ORA-03114: not connected to ORACLE (DBD ERROR: OCIStmtExecute/Describe) [for Statement select fullname from util.sso_users where username = ?] at /usr/local/apache/perl/ssouser.pl line 357. (/usr/local/rt3/lib/RT.pm:235) Now, RT is the RT3 help tickets application, which is protected by an authorization module (derived from AuthTicket.pm) using DBD::Oracle. But ssouser.pl is an application totally unrelated to RT3 and AuthTicket.pm. I'm at a loss here. Any help or pointers will be much appreciated Rafael -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Perl 5.8.0 to 5.8.1 under RH 9 - mod_perl problem
On Tue, 2004-01-27 at 11:24, Perrin Harkins wrote: Seems like a lot of upgrading just to go from 5.8.0 to 5.8.1, but I guess a lot of bug fixes and enhancements were added. There were a few. The one that mattered the most to me is that the locale issues are fixed so that you don't have to reset your locale on Red Hat 9 anymore. But really, if it was working for you, you don't need to upgrade. But while 5.8.0 compiles clean (after a LANG=;export LANG), trying to get 5.8.1, 5.8.2 and 5.8.3 to compile on Red Hat 9 (gcc 3.2.2-5 and glibc 2.3.2-27.9.7) with: sh Configure -de make make test fails on test 17 at lib/Time/Local The problems seem to have to do with my PCs havint PET (Lima, Peru time) timezone, and have thus far precluded my upgrading perl. Rafael -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Different results using mod_proxy or mod_rewrite vs direct server - followup
On Mon, 2004-01-12 at 17:55, Stas Bekman wrote: Rafael Caceres wrote: I'm setting up a HTTP/HTPPS reverse proxy server with apache on my DMZ. The proxy will access an internal server (insidelan.server.com) to provide content to outside users. I've attempted using mod_proxy: VirtualHost 1.2.3.4:80 ServerName insidelan.server.com ProxyPass / http://insidelan.server.com/ ProxyPassReverse / http://insidelan.server.com/ /Virtualhost and using mod_rewrite: VirtualHost 1.2.3.4:443 ServerName insidelan.server.com RewriteRule /(.*)$ http://insidelan.server.com/$1 [P] /VirtualHost Don't you miss: ProxyPassReverse / http://insidelan.server.com/ in the mod_rewrite case if you want it to be equivalent to the mod_proxy vhost setup? [P] does only the 'ProxyPass / http://insidelan.server.com/' part. You're right. Fact is we exercised the HTTPS part only when using the login windows, which inmediately redirected to /index using HTTP. Is there a way to make sure that people coming through the DMZ can only see a subset of the site (say, an /extranet branch)? Everything seems to work fine (including the HTTPS proxy, cookies, etc., etc.), except that I'm getting: Proxy Error The proxy server received an invalid response from an upstream server The proxy server could not handle the requet GET /perl/program.pl Reason: Document contains no data The very same URL: http://insidelan.server.com/perl/program.pl (that runs under Apache::Registry) works just fine when used from inside the LAN (that is, directly). I also copied program.pl to the cgi-bin directory (to run it as a standard CGI), and called the resulting URL: http://insidelan.server.com/cgi-bin/program.pl and what comes up is the text of the generated HTML page. Strangely enough, some other perl scripts (in cgi-bin or perl) work fine through the proxy. What's the global difference between working and non-working scripts (e.g. are all non-working are processing GET requests?). I found that the difference could be attributed to /cgi-bin having PerlSendHeader Off and /perl having PerlSendHeader On. The scripts using Template Toolkit (and not having an print $query-header (or similar) did not show up when viewed through the proxy. The quick fix was adding the print $query-header to scripts using Template Toolkit. What still puzzles me, is that they work when viewed directly and through a standard Squid proxy, and what to do if I ever need to set cookies that can depend on template work. Rafael Caceres -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Different results using mod_proxy or mod_rewrite vs direct server
I'm setting up a HTTP/HTPPS reverse proxy server with apache on my DMZ. The proxy will access an internal server (insidelan.server.com) to provide content to outside users. I've attempted using mod_proxy: VirtualHost 1.2.3.4:80 ServerName insidelan.server.com ProxyPass / http://insidelan.server.com/ ProxyPassReverse / http://insidelan.server.com/ /Virtualhost and using mod_rewrite: VirtualHost 1.2.3.4.90 ServerName insidelan.server.com RewriteRule /(.*)$ http://insidelan.server.com/$1 [P] /VirtualHost Everything seems to work fine (including the HTTPS proxy, cookies, etc., etc.), except that I'm getting: Proxy Error The proxy server received an invalid response from an upstream server The proxy server could not handle the requet GET /perl/program.pl Reason: Document contains no data The very same URL: http://insidelan.server.com/perl/program.pl (that runs under Apache::Registry) works just fine when used from inside the LAN (that is, directly). I also copied program.pl to the cgi-bin directory (to run it as a standard CGI), and called the resulting URL: http://insidelan.server.com/cgi-bin/program.pl and what comes up is the text of the generated HTML page. Strangely enough, some other perl scripts (in cgi-bin or perl) work fine through the proxy. The proxy is Apache 1.3.29, mod_perl 1.27. The server inside the LAN is: Apache 1.3.26,mod_perl 1.27 I'm crossposting because the problem seems to be originated in the combination perl/reverse proxy. Any help will be appreciated. Rafael -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
