Re: mod_perl and perl RPMs and Oracle 9iAS

[Rafael Caceres <rc...@aasa.com.pe>]

Dear Friends:

I'm facing a dilemma here. We are testing an Oracle 9iAS installation 
(Apache 1.3.19, mod_ssl 2.8.1, mod_perl 1.25 as DSO, Perl 5.005_03) on Red 
Hat Linux 7.2, which itself came with Perl 5.6.0, and from your comments, 
that's bad..
On the other hand, Oracle's product does not include all the sources -which 
could have patches- making up the mod_perl enabled Apache, so I've got 
various basic choices:

-Do double installations of perl modules, for the 5.6.0 and 5.005_03 Perls.
-Install new modules only for 5.005.3, for use in web development. Do 
double installs only for those usefull for admin work.
-Obtain and install all the modules installed for 5.6.0 and install them 
for the 'Oracle' 5.005_03 Perl, then replace the /usr/bin/perl with the 
5.005_03 version.
-Go the tough route and try to replace 5.005_03 in Oracle's product with 
5.6.1, where the problem would be absence of source for any Oracle modules. 
This would also thow support from Oracle out the window when/if the box 
ends testing and goes into production.

I'm eyeing the first option as the easiest, most stable. Now that means 
using 5.005_03 as DSO under Red Hat 7.2. Is that combination stable? Or is 
Perl 5.6.1 required to have stability for mod_perl as DSO on that platform?

Your comments will be appreciated.

Regards,
Rafael Caceers


At 09:38 PM 3/5/2002 -0500, you wrote:

>Just thought I'd drop a note here and let people know we've errata'd
>perl 5.6.1 and mod_perl 1.26 for Red Hat Linux 7.2.  Most
>significantly, mod_perl as a DSO under 7.2 work properly now.  I've
>spoken with a few of you off list about some of the issues, so
>hopefully this release will solve the problems people have had in the
>past with Red Hat and mod_perl DSOs.  Not to mention banishing 5.6.0
>from 7.2 :)
>
>Chip
>
>--
>Chip Turner                   cturner@redhat.com
>                               Red Hat Network

RE: mod_perl and perl RPMs and Oracle 9iAS

[Rob Bloodgood <ro...@empire2.com>]

> I've always used DBI along with DBD::Oracle for Database access, and I
> intend to use them along  Oracle 9iAS's other capabilities.
>
> So if I'm following you correctly, the steps involved are:
> -get the 5.6.1 RPM (which doesn't seem to be in Red Hat's site anyway)
> -get the Apache 1.3.19 sources (to be used in the next step), then
> 'discarded' without installing Apache per se.
> -get the mod_perl 1.24_01-2.src.rpm and compile it as a DSO
> -reinstall all previously installed packages, so other programs
> using them
> keep working
> -install the modules the mod_perl apps require
> -change the apachectl and httpd.conf files to reflect the proper
> perl 'home'
> -change httpd.conf to load the mod_perl.so file from it's new location
>
> Is this list OK?

Hmm... if you like RPM's, then you should
download the updated perl-5.6.1 in the UPDATES/ERRATA section for RH7.2

reinstall all required packages, USING CPAN!!!! for the stuff you needed
before.

the rest depends: are you comfortable with RH rpm version of Apache? If you
use that, plus the new, updated mod_perl-1.26 RPM (which is DSO, and is also
on the Errata page), your configuration and recompilation is no longer
necessary.  Otherwise, you have the right idea.

> > > Yes, there are at least two modules: mod_plsql and mod_oprocmgr
> > > for which which there is no source, so rebuilding seems to be
> > > out of the question
> >
> >Those modules are *only* for the Oracle administrative webservice, as I
> >mentioned above.  If you want to use Oracle from Perl/mod_perl, do it
like
> >everybody else: DBI and DBD::Oracle (for the record, I build them for 9i
> >several months ago with 0 headaches).  This *does* include the ability to
> >execute PL/SQL.
>
> The mod_plsql is called heavily from the Oracle 9iAS Portal
> applets, so it needs to be kept in place.

So are you using Oracle Portal applets, or mod_perl?  We seem to have
miscommunicated somewhere.

Yes, it needs to be kept in place... because you aren't touching that copy
of apache and perl, right? :-) I mean, if you want to use the supplied
Oracle stuff that badly, then put it on a different port number.  That way
you can reference the Oracle stuff without being trapped in a little box
where you're afraid to recompile/reconfigure/make more useful for YOUR
situation.

L8r,
Rob

RE: mod_perl and perl RPMs and Oracle 9iAS

[Rafael Caceres <rc...@aasa.com.pe>]

Rob Bloodgood wrote:
> > Perrin Harkins wrote:
> > >Rafael Caceres wrote:
> > >>I'm facing a dilemma here. We are testing an Oracle 9iAS installation
> > >>(Apache 1.3.19, mod_ssl 2.8.1, mod_perl 1.25 as DSO, Perl 5.005_03) on
> > >>Red Hat Linux 7.2, which itself came with Perl 5.6.0, and from your
> > >>comments, that's bad..
> > >
> > >First of all, if it's working for you then don't worry about it.
> >
> > I have not started testing scripts that currently work on other boxes. I
> > will install the required modules for the 5.005_03 perl used by Oracle
> > 9iAS, and see what happens.
> > This road forces me to have the two perl versions coexisting, or,
> > to search
> > for all the perl modules installed for the 5.6 version by the rpm's on
> > initial installation, install them for the 5.005_03 version and
> > then remove
> > the 5.6 one permanently.
>
>OK, for starters:
>Oracle includes their own version of perl/apache/mod_perl for the Web
>interface they are bundling with the new 9i servers.  It's their own
>version, built by their own people, for their own usage, on their own
>product, in its own path, under the Oracle product installation tree.
>
>Let 'em have it.  It's only a few megs of disk space, and if your 9i
>installation works, GREAT.  Don't think of it as two versions co-existing.
>Think of it as Oracle's insurance to themselves that their system will have
>the exact parts it needs.  Besides, except for a few configuration files,
>shouldn't everything under $ORACLE_HOME be considered hands-off anyway?

They dont seem to use it though, there is no visible perl script on the 
default httpd.conf other than the printenv script under /cgi-bin.
But, they set PERL5LIB to point to their perl in apachectl and httpd.conf, 
which I guess can be fixed in the mentioned places.


>Now, on to the real world: 10 minutes ago I just saw a post by a RedHat
>employee stating that there are new RPM's for Perl 5.6.1 and the latest
>mod_perl.  Which means you can download and install them, and THEN begin
>installing other modules, like Apache::DBI, Apache::Session, etc etc
>according to your needs, into the "real" perl installation tree, where all
>of YOUR system's perl modules live.

I've always used DBI along with DBD::Oracle for Database access, and I 
intend to use them along  Oracle 9iAS's other capabilities.

So if I'm following you correctly, the steps involved are:
-get the 5.6.1 RPM (which doesn't seem to be in Red Hat's site anyway)
-get the Apache 1.3.19 sources (to be used in the next step), then 
'discarded' without installing Apache per se.
-get the mod_perl 1.24_01-2.src.rpm and compile it as a DSO
-reinstall all previously installed packages, so other programs using them 
keep working
-install the modules the mod_perl apps require
-change the apachectl and httpd.conf files to reflect the proper perl 'home'
-change httpd.conf to load the mod_perl.so file from it's new location

Is this list OK?

> > Yes, there are at least two modules: mod_plsql and mod_oprocmgr for which
> > there is no source, so rebuilding seems to be out of the question
>
>Those modules are *only* for the Oracle administrative webservice, as I
>mentioned above.  If you want to use Oracle from Perl/mod_perl, do it like
>everybody else: DBI and DBD::Oracle (for the record, I build them for 9i
>several months ago with 0 headaches).  This *does* include the ability to
>execute PL/SQL.

The mod_plsql is called heavily from the Oracle 9iAS Portal applets, so it 
needs to be kept in place.


>L8r,
>Rob
>
>#!/usr/bin/perl -w
>use Disclaimer qw/:standard/;

Regards,
Rafael

Re: mod_perl and perl RPMs and Oracle 9iAS

[darren chamberlain <dl...@users.sourceforge.net>]

Quoting Rafael Caceres <rc...@aasa.com.pe> [Mar 06, 2002 12:22]:
> Perrin Harkins wrote:
> >Unless there is some additional module provided by Oracle
> >which has a C component and no source, you should be fine to
> >replace everything they gave you if you want to.  I wouldn't
> >bother though, unless it's giving you trouble.
> 
> Yes, there are at least two modules: mod_plsql and mod_oprocmgr
> for which there is no source, so rebuilding seems to be out of
> the question

...unless they are built dynamically, in which case you should be
able to load them as DSOs, provided you use the same version of
Apache.  Yes?

(darren)

-- 
Although I can accept talking scarecrows, lions, and great
wizards of emerald cities, I find it hard to believe there
is no paperwork involved when your house lands on a witch.

RE: mod_perl and perl RPMs and Oracle 9iAS

[Rob Bloodgood <ro...@empire2.com>]

> Perrin Harkins wrote:
> >Rafael Caceres wrote:
> >>I'm facing a dilemma here. We are testing an Oracle 9iAS installation
> >>(Apache 1.3.19, mod_ssl 2.8.1, mod_perl 1.25 as DSO, Perl 5.005_03) on
> >>Red Hat Linux 7.2, which itself came with Perl 5.6.0, and from your
> >>comments, that's bad..
> >
> >First of all, if it's working for you then don't worry about it.
>
> I have not started testing scripts that currently work on other boxes. I
> will install the required modules for the 5.005_03 perl used by Oracle
> 9iAS, and see what happens.
> This road forces me to have the two perl versions coexisting, or,
> to search
> for all the perl modules installed for the 5.6 version by the rpm's on
> initial installation, install them for the 5.005_03 version and
> then remove
> the 5.6 one permanently.

OK, for starters:
Oracle includes their own version of perl/apache/mod_perl for the Web
interface they are bundling with the new 9i servers.  It's their own
version, built by their own people, for their own usage, on their own
product, in its own path, under the Oracle product installation tree.

Let 'em have it.  It's only a few megs of disk space, and if your 9i
installation works, GREAT.  Don't think of it as two versions co-existing.
Think of it as Oracle's insurance to themselves that their system will have
the exact parts it needs.  Besides, except for a few configuration files,
shouldn't everything under $ORACLE_HOME be considered hands-off anyway?

Now, on to the real world: 10 minutes ago I just saw a post by a RedHat
employee stating that there are new RPM's for Perl 5.6.1 and the latest
mod_perl.  Which means you can download and install them, and THEN begin
installing other modules, like Apache::DBI, Apache::Session, etc etc
according to your needs, into the "real" perl installation tree, where all
of YOUR system's perl modules live.

> Yes, there are at least two modules: mod_plsql and mod_oprocmgr for which
> there is no source, so rebuilding seems to be out of the question

Those modules are *only* for the Oracle administrative webservice, as I
mentioned above.  If you want to use Oracle from Perl/mod_perl, do it like
everybody else: DBI and DBD::Oracle (for the record, I build them for 9i
several months ago with 0 headaches).  This *does* include the ability to
execute PL/SQL.

L8r,
Rob

#!/usr/bin/perl -w
use Disclaimer qw/:standard/;

Re: mod_perl and perl RPMs and Oracle 9iAS

[Rafael Caceres <rc...@aasa.com.pe>]

Perrin Harkins wrote:
>Rafael Caceres wrote:
>>I'm facing a dilemma here. We are testing an Oracle 9iAS installation 
>>(Apache 1.3.19, mod_ssl 2.8.1, mod_perl 1.25 as DSO, Perl 5.005_03) on 
>>Red Hat Linux 7.2, which itself came with Perl 5.6.0, and from your 
>>comments, that's bad..
>
>First of all, if it's working for you then don't worry about it.

I have not started testing scripts that currently work on other boxes. I 
will install the required modules for the 5.005_03 perl used by Oracle 
9iAS, and see what happens.
This road forces me to have the two perl versions coexisting, or, to search 
for all the perl modules installed for the 5.6 version by the rpm's on 
initial installation, install them for the 5.005_03 version and then remove 
the 5.6 one permanently.

>I'm curious about this though:
>>On the other hand, Oracle's product does not include all the sources 
>>-which could have patches- making up the mod_perl enabled Apache
>
>Are you saying Oracle provided special modules for you to use?  Are you 
>sure they aren't just the standard DBD::Oracle stuff?  Oracle has never 
>been very interested in helping people solve DBD::Oracle problems before, 
>so I don't see why they would be secretly distributing special versions 
>with private patches.
>
>Unless there is some additional module provided by Oracle which has a C 
>component and no source, you should be fine to replace everything they 
>gave you if you want to.  I wouldn't bother though, unless it's giving you 
>trouble.

Yes, there are at least two modules: mod_plsql and mod_oprocmgr for which 
there is no source, so rebuilding seems to be out of the question

Regards,
Rafael Caceres

Re: mod_perl and perl RPMs and Oracle 9iAS

[Perrin Harkins <pe...@elem.com>]

Rafael Caceres wrote:
> I'm facing a dilemma here. We are testing an Oracle 9iAS installation 
> (Apache 1.3.19, mod_ssl 2.8.1, mod_perl 1.25 as DSO, Perl 5.005_03) on 
> Red Hat Linux 7.2, which itself came with Perl 5.6.0, and from your 
> comments, that's bad..

First of all, if it's working for you then don't worry about it.

I'm curious about this though:
> On the other hand, Oracle's product does not include all the sources 
> -which could have patches- making up the mod_perl enabled Apache

Are you saying Oracle provided special modules for you to use?  Are you 
sure they aren't just the standard DBD::Oracle stuff?  Oracle has never 
been very interested in helping people solve DBD::Oracle problems 
before, so I don't see why they would be secretly distributing special 
versions with private patches.

Unless there is some additional module provided by Oracle which has a C 
component and no source, you should be fine to replace everything they 
gave you if you want to.  I wouldn't bother though, unless it's giving 
you trouble.

- Perrin