Re: Both mod_perl 1 and 2 on same machine
On Tuesday 15 May 2007 22:33, Walt Reed wrote:
> I would prefer however to put all my test modules for this migration in the
> /usr/local/apache2/perllib space, but looking at the mod_perl configure
> options, I didn't see which option specified this... MP_AP_PREFIX?
> MP_AP_DESTDIR? Neither one of those looked appropriate.
BASE=/path/to/somewhere
PERLV=$(perl -e 'printf "%vd", $^V')
make \
INSTALLSITEARCH=$BASE/$PERLV/i586-linux-thread-multi \
INSTALLSITELIB=$BASE/$PERLV \
INSTALLSITEBIN=$BASE/usr/bin \
INSTALLSCRIPT=$BASE/usr/bin \
INSTALLSITEMAN1DIR=$BASE/man/man1 \
INSTALLSITEMAN3DIR=$BASE/man/man3 \
install
Then in the httpd.conf:
PerlSwitches -I${BASE}
I do something like this in RPM builds. So I have httpd and mod_perl bundled
in /opt/apache, /opt/apache22 etc. Apache is located in /opt/apache and
mod_perl in /opt/apache/mod_perl.
This is a bit cumbersome because you have to look out in which tree to install
additional modules. But for me it works.
Torsten
pgp5MXm5XdSK2.pgp
Description: PGP signature
Re: Both mod_perl 1 and 2 on same machine
Modify @INC to only load the libraries you need, and make sure to install the MP1 modules in a different location than the MP2 ones. Basically, install the 'default' server perl modules normally, and install the 'other' ones in a special directory that you then modify @INC to include through use lib () or direct manipulation of @INC in a begin block. -- Dodger Walt Reed wrote: The apache part isn't the problem. I can easily run on different ports, and whatnot. In fact, both apache's are working fine independantly, so it's just the perl / mod_perl issue. When I do a "make install" of mod_perl 2.x I don't want mod_perl 2 based perl modules tromping all over the existing mod_perl 1.3 system install. Both my apache 1.3 and 2.2 installs are custom compiled into apache standard /usr/local/apache / /usr/local/apache2 trees (instead of using the hatchet job versions that redhat likes to ship.) The deal here is that the customer is migrating from an apache 1.3 setup to an apache 2.2 setup and only has one machine available in the colo. Adding another is not feasable at the moment. On Tue, May 15, 2007 at 03:47:19PM -0400, John Saylor said: hi ouch. the only suggestion i have is to reasess your needs. really- you'll spend at least 10 hours dicking around with the network config to say nothing about httpd.conf. if you get paid over $10. and hour, that makes it worth it buy a new machine. -Original Message- From: Walt Reed [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 3:39 PM [deletions] I have a need to install both apache 1.3.x / mod_perl 1.x and apache 2.2.x / mod_perl 2.x on the same machine.
Re: Both mod_perl 1 and 2 on same machine
On Tue, May 15, 2007 at 04:05:38PM -0400, Michael Peters said: > Walt Reed wrote: > > The apache part isn't the problem. I can easily run on different ports, > > and whatnot. In fact, both apache's are working fine independantly, so > > it's just the perl / mod_perl issue. When I do a "make install" of > > mod_perl 2.x I don't want mod_perl 2 based perl modules tromping all > > over the existing mod_perl 1.3 system install. > > They shouldn't tromp over anything. All mod_perl2 modules are in the Apache2 > namespace. Now, this doesn't guarantee that some 3rd party module won't detect > that you're running under mod_perl by trying to use 'Apache2' instead of > looking > at $ENV, but that's a different story... OK, that is exactly what I needed to know. So no big conflicts then in perl module land having both installed... I would prefer however to put all my test modules for this migration in the /usr/local/apache2/perllib space, but looking at the mod_perl configure options, I didn't see which option specified this... MP_AP_PREFIX? MP_AP_DESTDIR? Neither one of those looked appropriate. Other perl modules are easy with PREFIX and LIB.
Re: Both mod_perl 1 and 2 on same machine
On May 15, 2007, at 4:05 PM, Michael Peters wrote: Walt Reed wrote: The apache part isn't the problem. I can easily run on different ports, and whatnot. In fact, both apache's are working fine independantly, so it's just the perl / mod_perl issue. When I do a "make install" of mod_perl 2.x I don't want mod_perl 2 based perl modules tromping all over the existing mod_perl 1.3 system install. They shouldn't tromp over anything. All mod_perl2 modules are in the Apache2 namespace. Now, this doesn't guarantee that some 3rd party module won't detect that you're running under mod_perl by trying to use 'Apache2' instead of looking at $ENV, but that's a different story... Doesn't the mp2 installation require the removal of all mp1/mp2 versions before the namespace renaming ?: // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | SyndiClick.com | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: Both mod_perl 1 and 2 on same machine
On May 15, 2007, at 3:49 PM, Perrin Harkins wrote: My approach would be to install two copies of perl, and put one of them on each. Or, install each in a local perl lib directory rather than the system dir. (Local installs of CPAN modules are well-covered elsewhere.) I'd second the latter suggestion -- 2 separate local installs for all apache/mp related CPAN modules. I'd also remove the /Apache and /Apache2 directories and touch them as flat files -- just to make sure no one can accidentally install files in them. your requirements are likely to cause you a ton of headaches in the future -- best now to plan ahead and minimize them // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | SyndiClick.com | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: Both mod_perl 1 and 2 on same machine
Walt Reed wrote: > The apache part isn't the problem. I can easily run on different ports, > and whatnot. In fact, both apache's are working fine independantly, so > it's just the perl / mod_perl issue. When I do a "make install" of > mod_perl 2.x I don't want mod_perl 2 based perl modules tromping all > over the existing mod_perl 1.3 system install. They shouldn't tromp over anything. All mod_perl2 modules are in the Apache2 namespace. Now, this doesn't guarantee that some 3rd party module won't detect that you're running under mod_perl by trying to use 'Apache2' instead of looking at $ENV, but that's a different story... -- Michael Peters Developer Plus Three, LP
Re: Both mod_perl 1 and 2 on same machine
The apache part isn't the problem. I can easily run on different ports, and whatnot. In fact, both apache's are working fine independantly, so it's just the perl / mod_perl issue. When I do a "make install" of mod_perl 2.x I don't want mod_perl 2 based perl modules tromping all over the existing mod_perl 1.3 system install. Both my apache 1.3 and 2.2 installs are custom compiled into apache standard /usr/local/apache / /usr/local/apache2 trees (instead of using the hatchet job versions that redhat likes to ship.) The deal here is that the customer is migrating from an apache 1.3 setup to an apache 2.2 setup and only has one machine available in the colo. Adding another is not feasable at the moment. On Tue, May 15, 2007 at 03:47:19PM -0400, John Saylor said: > hi > > ouch. > > the only suggestion i have is to reasess your needs. really- you'll > spend at least 10 hours dicking around with the network config to say > nothing about httpd.conf. if you get paid over $10. and hour, that makes > it worth it buy a new machine. > > -Original Message- > From: Walt Reed [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 15, 2007 3:39 PM > [deletions] > I have a need to install both apache 1.3.x / mod_perl 1.x and apache > 2.2.x / mod_perl 2.x on the same machine. > >
Re: Both mod_perl 1 and 2 on same machine
Walt Reed wrote: I have a need to install both apache 1.3.x / mod_perl 1.x and apache 2.2.x / mod_perl 2.x on the same machine. Googling returns some hits from 2004 that mention MP_INST_APACHE2=1, but that option no longer exists in current versions of mod_perl 2. Didn't see anything obvious in the install manual either. Suggestions? I have a couple machines with multiple versions of apache and mod_perl. A front end proxy apache22 installed from ports, and source install of apache13+mod_perl in /usr/local/apache-perl and a source install of apache22+mod_perl2 in /usr/local/apache22-perl. I only have one version of perl and haven't had any problems. -Glenn
Re: Both mod_perl 1 and 2 on same machine
On 5/15/07, Walt Reed <[EMAIL PROTECTED]> wrote: I have a need to install both apache 1.3.x / mod_perl 1.x and apache 2.2.x / mod_perl 2.x on the same machine. [...] Suggestions? My approach would be to install two copies of perl, and put one of them on each. Or, install each in a local perl lib directory rather than the system dir. (Local installs of CPAN modules are well-covered elsewhere.) - Perrin
RE: Both mod_perl 1 and 2 on same machine
hi ouch. the only suggestion i have is to reasess your needs. really- you'll spend at least 10 hours dicking around with the network config to say nothing about httpd.conf. if you get paid over $10. and hour, that makes it worth it buy a new machine. -Original Message- From: Walt Reed [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 3:39 PM [deletions] I have a need to install both apache 1.3.x / mod_perl 1.x and apache 2.2.x / mod_perl 2.x on the same machine.
Both mod_perl 1 and 2 on same machine
I have a need to install both apache 1.3.x / mod_perl 1.x and apache 2.2.x / mod_perl 2.x on the same machine. Googling returns some hits from 2004 that mention MP_INST_APACHE2=1, but that option no longer exists in current versions of mod_perl 2. Didn't see anything obvious in the install manual either. Suggestions?
RE: apache2 does not deny acces though PerlAuthenHandler returns HTTP_UNAUTHORIZED
use Apache::RequestRec;
?
What version of mod_perl are you running? The above line makes me thing
you're running an reall old version of mod_perl2 from prior to the
namespace change, which is probably a really bad idea, and may explain
why Auth isn't working right.
Adam
-Original Message-
From: Moritz Maisel [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 15, 2007 10:46 AM
To: modperl@perl.apache.org
Subject: apache2 does not deny acces though PerlAuthenHandler returns
HTTP_UNAUTHORIZED
Hi List,
I wrote a PerlAuthenHandler to authenticate users that access a
webservice. I supposed that by returning either "OK" or
"HTTP_UNAUTHORIZED" back to apache2 it will allow or deny acces due to
the "require valid-user" directive that I set.
My problem is, that apache executes my handler, but it does not take
care of my return-values. Instead it always serves the request and
grants access.
Any ideas?
Thanks in advance,
Moritz
Section of my apache-configuration:
--- BEGIN ---
PerlModule FOO::Auth
# do authentication:
PerlAuthenHandler FOO::Auth::authen_handler
AuthName "experimental server"
AuthType Basic
Require valid-user
--- END ---
Code of my handler-module:
--- BEGIN ---
package FOO::Auth;
use Data::Dumper;
use Apache::RequestRec;
use Apache::Access;
use Apache::Log;
use Apache::Const -compile => qw(OK DECLINED HTTP_UNAUTHORIZED
FORBIDDEN);
use Apache::RequestUtil ();
sub authen_handler {
my $r = shift;
# get user's authentication credentials
my ($res, $sent_pw) = $r->get_basic_auth_pw;
return $res if $res != Apache::Const::OK;
my $user = $r->user;
print STDERR "$user -> $sent_pw\n";
if ($user eq "mytestuser") {
return OK;
} else {
$r->note_basic_auth_failure;
$r->log_reason("wrong login", $r->uri);
return HTTP_UNAUTHORIZED;
}
}
1;
--- END ---
extract of apache2 error-log:
--- BEGIN ---
notmytestuser -> sad
[Tue May 15 15:53:34 2007] [error] access to /bar/index.php failed for
xxx.xxx.xxx.xxx, reason: wrong login
--- END ---
Re: apache2 does not deny acces though PerlAuthenHandler returns HTTP_UNAUTHORIZED
Michael Peters wrote: > Moritz Maisel wrote: > >>Hi List, >> >>I wrote a PerlAuthenHandler to authenticate users that access a >>webservice. I supposed that by returning either "OK" or >>"HTTP_UNAUTHORIZED" back to apache2 it will allow or deny acces due to >>the "require valid-user" directive that I set. >>My problem is, that apache executes my handler, but it does not take >>care of my return-values. Instead it always serves the request and >>grants access. > > > The HTTP codes are HTTP return codes, not handler return codes. actually, that's not really correct... a handler is expected to return one of o apache handler code (OK, DECLINE, DONE) o apache _error_ code (SERVER_ERROR, FORBIDDEN, etc) the confusion is generally when someone assumes OK (0) is the same as HTTP_OK (200). so, it's always proper to return an HTTP code in the case of "errors" where "error" in apache-speak is anything other than 200. > Use FORBIDDEN instead. actually HTTP_UNAUTHORIZED (401, aka AUTH_REQUIRED) is more proper than FORBIDDEN (403) for basic auth, though either should prevent the content handler from running. offhand I can't see anything in your code that looks wrong - ordinarily, of mod_perl authen doesn't do it's job properly you'll see core errors due to missing AuthUserFile, etc directive that don't really matter if your custom authen is functional. if I had to guess I'd say that something else in your httpd.conf is interfering with your authen setup. the first thing that comes to mind is making sure you have 'Satisfy All' and not 'Satisfy Any' HTH --Geoff
Re: apache2 does not deny acces though PerlAuthenHandler returns HTTP_UNAUTHORIZED
2007/5/15, Michael Peters <[EMAIL PROTECTED]>: The HTTP codes are HTTP return codes, not handler return codes. Use FORBIDDEN instead. I already tried (and now tried again) to use "return FORBIDDEN" instead of "return HTTP_UNAUTHORIZED" without success. :-(
Re: apache2 does not deny acces though PerlAuthenHandler returns HTTP_UNAUTHORIZED
Moritz Maisel wrote: > Hi List, > > I wrote a PerlAuthenHandler to authenticate users that access a > webservice. I supposed that by returning either "OK" or > "HTTP_UNAUTHORIZED" back to apache2 it will allow or deny acces due to > the "require valid-user" directive that I set. > My problem is, that apache executes my handler, but it does not take > care of my return-values. Instead it always serves the request and > grants access. The HTTP codes are HTTP return codes, not handler return codes. Use FORBIDDEN instead. -- Michael Peters Developer Plus Three, LP
apache2 does not deny acces though PerlAuthenHandler returns HTTP_UNAUTHORIZED
Hi List,
I wrote a PerlAuthenHandler to authenticate users that access a webservice.
I supposed that by returning either "OK" or "HTTP_UNAUTHORIZED" back to
apache2 it will allow or deny acces due to the "require valid-user"
directive that I set.
My problem is, that apache executes my handler, but it does not take care of
my return-values. Instead it always serves the request and grants access.
Any ideas?
Thanks in advance,
Moritz
Section of my apache-configuration:
--- BEGIN ---
PerlModule FOO::Auth
# do authentication:
PerlAuthenHandler FOO::Auth::authen_handler
AuthName "experimental server"
AuthType Basic
Require valid-user
--- END ---
Code of my handler-module:
--- BEGIN ---
package FOO::Auth;
use Data::Dumper;
use Apache::RequestRec;
use Apache::Access;
use Apache::Log;
use Apache::Const -compile => qw(OK DECLINED HTTP_UNAUTHORIZED FORBIDDEN);
use Apache::RequestUtil ();
sub authen_handler {
my $r = shift;
# get user's authentication credentials
my ($res, $sent_pw) = $r->get_basic_auth_pw;
return $res if $res != Apache::Const::OK;
my $user = $r->user;
print STDERR "$user -> $sent_pw\n";
if ($user eq "mytestuser") {
return OK;
} else {
$r->note_basic_auth_failure;
$r->log_reason("wrong login", $r->uri);
return HTTP_UNAUTHORIZED;
}
}
1;
--- END ---
extract of apache2 error-log:
--- BEGIN ---
notmytestuser -> sad
[Tue May 15 15:53:34 2007] [error] access to /bar/index.php failed for
xxx.xxx.xxx.xxx, reason: wrong login
--- END ---
RE: "Insecure dependency in eval while running setgid" error
Hello All,
> -Original Message-
> From: Shah, Sagar: IT (LDN)
> Sent: 17 April 2007 09:39
> To: 'Charlie Katz'; modperl@perl.apache.org
> Cc: Perrin Harkins; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> Client Research Development
> Subject: RE: "Insecure dependency in eval while running setgid" error
>
> Hi Charlie,
>
> > -Original Message-
> > From: Charlie Katz [mailto:[EMAIL PROTECTED]
> > Sent: 30 March 2007 19:00
> > To: modperl@perl.apache.org
> > Cc: Perrin Harkins; Shah, Sagar: IT (LDN);
> > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Client Research Development
> > Subject: Re: "Insecure dependency in eval while running
> setgid" error
> >
> > Hi All,
> >
> > I've been following this discussion closely because I had
> > what seems to be the
> > same problem Sagar is having.
> >
> > On Friday 30 March 2007 12:19 pm, Perrin Harkins wrote:
> > > This might be a silly question, but what makes you think
> this has to
> > > do with tainting? If it was a taint problem, wouldn't it say
> > > "Insecure dependency in eval while running with -T switch"? It's
> > > complaining about eval while running setgid. (I know you said you
> > > aren't running setgid, but I think you should be trying to
> > figure out
> > > why it thinks it's setgid, not why something is tainted.)
> >
> > I was initially on-board with Sagar about this being a
> > taint-checker problem,
> > but Perrin's makes a pretty good point: it *is* rather
> > suggestive that the
> > insecure dependency message refers to "while running setgid"
> > at the same time
> > that the server reports GID-EGID mismatch due to a
> > nonsensical EGID. I
> > checked and found that my server displays the EGID problem as
> > well, so
> > decided to take Perrin's advice and investigate this first.
> >
> > I ran ps, which showed that the httpd processes all have
> > their GID matching
> > their EGID. Then I checked in perl by reporting the GID and
> > EGID from the
> > parent and children and found that the nonsensical EGID
> > appears in the
> > children when they are spawned (or at least in the
> > PerlChildInitHandler).
> > This seems to localize the problem to mod_perl.
> >
> > I started greping around in the mod_perl source code (I have
> > 2.0.2) and found
> > this in modperl_perl.c:
> >
> > --
> > --
> > static void modperl_perl_ids_get(modperl_perl_ids_t *ids)
> > {
> > ids->pid = (I32)getpid();
> > #ifdef MP_MAINTAIN_PPID
> > ids->ppid = (I32)getppid();
> > #endif
> > #ifndef WIN32
> > ids->uid = getuid();
> > ids->euid = geteuid();
> > ids->gid = getgid();
> > ids->gid = getegid();
> > --
> > --
> > I changed that last line to
> >
> >ids->egid = getegid();
> >
> > then rebuilt/reinstalled/restarted, and the EGID problem is gone.
> >
> > I checked the 2.0.3 source and found this already fixed there.
> >
> >
> >
> > Sagar, can you try the same thing with your server? Perhaps
> > the "tainting"
> > problem will just disappear once this bug is fixed.
>
>
> Sorry for the delayed reply, I had been on leave and had
> asked the other members of my team to continue to look into
> this and feed back to the list, but as soon as they had
> started looking into the issue they were asked to work on
> something higher priority ;-)
>
> As Fred said, great catch.
>
> The initial feeling in our team was that because we're
> explicitly switching taint mode on all this fix will do is
> change the error message from "in eval while running setgid"
> to something else as per the if/else block in taint.c. That
> said given that there was quite a gap between 2.0.2 and 2.0.3
> I think your suggestion is still worth trying. This or other
> fixes might indirectly resolve the issue and it's always best
> practice to try and repeat what appears to be a bug against
> the latest version of the software. The only reason we held
> off from doing this initially was that there wasn't anything
> in the changes file that seemed connected, but as you've
> shown there are other smaller changes included also.
>
> I'll report back with how I get on.
It's been a while and we've been hacking away at the issue so I thought I'd
report back to the list now that we've finally got to the bottom of it.
Rather than upgrading to mod_perl 2.0.3 straight away we thought we'd first try
and create a smaller test case by hacking away at the code we started with and
taking the good old 'binary chop' approach. We eventually found that we were
able to repeat the problem in a perl script outside mod_perl so I can clearly
state that this problem was not caused by a mod_perl bug.
We continued to work on our test case removing all reference to our own
applications code and then stripping down any CPAN modules that the
