Trying again

OK, after a false start, I’m trying again…

However, now I’m having a different issue.

We have one apache server that we’re trying to put several things on.
Here’s the virtual hosts section:

ServerName help.qa.tripwire.com DocumentRoot /var/www/html/dcl

#<VirtualHost 10.69.1.14>
#ServerName rt.qa.tripwire.com
#ServerAlias helpfish.qa.tripwire.com
#DocumentRoot /usr/local/rt2/WebRT/html
#PerlModule Bundle::DBI
#PerlRequire /usr/local/rt2/bin/webmux.pl
#

SetHandler perl-script

PerlHandler RT::Mason

#
#

I have php pages in /var/www/html/dcl that work fine when I leave the
second virtual host (for RT) commented out.

If I uncomment the RT section, it breaks DCL. The error log for apache
reports the following when trying to access:

[Fri Mar 1 15:01:00 2002] [error] [Mason] File does not exist:
/usr/local/rt2/WebRT/html/dcl/index.php3

So, it looks like mason is being used for all the pages, even through it’s
only specified in the second virtual host.

Ideas?

Russ Johnson
Stargate Online

http://www.dimstar.net
telnet://telnet.dimstar.net
ICQ: 3739685

I feel like I’m diagonally parked in a parallel universe.

#<VirtualHost 10.69.1.14>
#ServerName rt.qa.tripwire.com
#PerlModule Bundle::DBI

Try ‘PerlModule Apache::DBI’ instead. I’m not sure what the effect of
referencing a CPAN module collection (the ‘Bundle’) would be under Apache,
but I daresay that it cannot be good.

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

Hmm, I copied that directly out of my httpd.conf file on my working version
of RT.

And actually, RT is working on that box. Although, I changed that line, and
suddenly, apache wouldn’t run… come to find out that Apache::DBI wasn’t
installed… Weird… even with that not installed, RT seemed to be working.

What would break if Apache::DBI isn’t installed?

At 08:56 PM 3/4/2002 +0100, you wrote:>On Fri, 1 Mar 2002, Russ Johnson wrote:

#<VirtualHost 10.69.1.14>
#ServerName rt.qa.tripwire.com
#PerlModule Bundle::DBI

Try ‘PerlModule Apache::DBI’ instead. I’m not sure what the effect of
referencing a CPAN module collection (the ‘Bundle’) would be under Apache,
but I daresay that it cannot be good.

Russ Johnson
Stargate Online

http://www.dimstar.net
telnet://telnet.dimstar.net
ICQ: 3739685

I feel like I’m diagonally parked in a parallel universe.

Hmm, I copied that directly out of my httpd.conf file on my working version
of RT.

And actually, RT is working on that box. Although, I changed that line, and
suddenly, apache wouldn’t run… come to find out that Apache::DBI wasn’t
installed… Weird… even with that not installed, RT seemed to be working.

What would break if Apache::DBI isn’t installed?

‘RT’ ?

Apache::DBI is pretty streamlining chaff for processes running under
Apache that use the perl DBI:: modules (eg, database connections). It
maintains, per apache process, a connection to the db that is persistent
across seperate pages. This means that on each page served, there is not
a seperate connection ( plus associated overhead) made to the database.

perldoc Apache::DBI will give you more gory details.

If its not there, either RT will not work, or it will be much slower (open
a seperate connection to the database on each page request).

Tuning Apache to run properly under database applications is another ball
game all together.

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

Well, it evidently doesn’t break it, as I have a fully functional (at
least, everything is working…) RT 2.0.7 installed with the following in my
httpd.conf:

<VirtualHost 10.69.1.11>
ServerName helpfish.qa.tripwire.com
ServerAlias helpfish
DocumentRoot /local/rt2/WebRT/html
PerlModule Bundle::DBI
PerlRequire /local/rt2/bin/webmux.pl

SetHandler perl-script
PerlHandler RT::Mason

I just checked, and that instance of the string “DBI” is the only instance
in my entire conf file. Maybe my new installation (RT 2.0.11) will be
faster, although we haven’t noticed any performance issues.

At 09:59 AM 3/5/2002 +0100, you wrote:>On Mon, 4 Mar 2002, Russ Johnson wrote:

Hmm, I copied that directly out of my httpd.conf file on my working version
of RT.

And actually, RT is working on that box. Although, I changed that line, and
suddenly, apache wouldn’t run… come to find out that Apache::DBI wasn’t
installed… Weird… even with that not installed, RT seemed to be
working.

What would break if Apache::DBI isn’t installed?

‘RT’ ?

Apache::DBI is pretty streamlining chaff for processes running under
Apache that use the perl DBI:: modules (eg, database connections). It
maintains, per apache process, a connection to the db that is persistent
across seperate pages. This means that on each page served, there is not
a seperate connection ( plus associated overhead) made to the database.

perldoc Apache::DBI will give you more gory details.

If its not there, either RT will not work, or it will be much slower (open
a seperate connection to the database on each page request).

Tuning Apache to run properly under database applications is another ball
game all together.

Regards,


Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Russ Johnson
Stargate Online

http://www.dimstar.net
telnet://telnet.dimstar.net
ICQ: 3739685

I feel like I’m diagonally parked in a parallel universe.

Hmm you most defenitely won’t have persistent DB connections.
And like it was pointed out before - it should be Apache::DBI

This is the way we run it:

ServerName helpdesk.na.sca.com DocumentRoot /usr/local/rt2/WebRT/html PerlModule Apache::DBI PerlFreshRestart On PerlRequire /usr/local/rt2/bin/webmux.pl SetHandler perl-script PerlHandler RT::Mason

<Location /chart>
SetHandler perl-script
PerlHandler +Apache::GD::Graph
## These are optional (defaults shown)
## In days:
#PerlSetVar Expires 30
## In megs:
#PerlSetVar CacheSize 5242880
#PerlSetVar ImageType png
#PerlSetVar JpegQuality 75 # 0 to 100
#PerlSetVar TTFFontPath /usr/ttfonts:
#/var/ttfonts:/usr/X11R6/lib/X11/fonts/ttf/:
#/usr/X11R6/lib/X11/fonts/truetype/:
#/usr/share/fonts/truetype

Unix is like a wigwam - no gates, no windows, apache inside

Johan Edstrom, SCA IT Services
johan.edstrom@sca.com
Tel : +1 920 727 8821
Fax : +1 920 727 8810
Cell : +1 920 205 6472

Quoting Russ Johnson russj@dimstar.net [Mar 05, 2002 12:52]:

Well, it evidently doesn’t break it, as I have a fully
functional (at least, everything is working…) RT 2.0.7
installed with the following in my httpd.conf:

<VirtualHost 10.69.1.11>
ServerName helpfish.qa.tripwire.com
ServerAlias helpfish
DocumentRoot /local/rt2/WebRT/html
PerlModule Bundle::DBI
^^^^^^^^^^^
This doesn’t do anything; it should be Apache::DBI. Bundle::DBI
is an empty module (i.e., devoid of Perl).

PerlRequire /local/rt2/bin/webmux.pl

SetHandler perl-script
PerlHandler RT::Mason

(darren)

Absence is to love what wind is to fire.
It extinguishes the small, it enkindles the great.

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

Quoting Russ Johnson russj@dimstar.net [Mar 05, 2002 12:52]:

Well, it evidently doesn’t break it, as I have a fully
functional (at least, everything is working…) RT 2.0.7
installed with the following in my httpd.conf:

<VirtualHost 10.69.1.11>
ServerName helpfish.qa.tripwire.com
ServerAlias helpfish
DocumentRoot /local/rt2/WebRT/html
PerlModule Bundle::DBI
^^^^^^^^^^^
This doesn’t do anything; it should be Apache::DBI. Bundle::DBI
is an empty module (i.e., devoid of Perl).

That was my point. Having that misconfigured on my server does not seem to
be having any ill effects. Since I’m in the process of replacing that
server, and the current one is presently working, I’m leaving it alone.

Russ Johnson
Stargate Online

http://www.dimstar.net
telnet://telnet.dimstar.net
ICQ: 3739685

How many of you believe in telekinesis?
If you do raise my hand…

Quoting Russ Johnson russj@dimstar.net [Mar 05, 2002 14:26]:

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

Quoting Russ Johnson russj@dimstar.net [Mar 05, 2002 12:52]:

Well, it evidently doesn’t break it, as I have a fully
functional (at least, everything is working…) RT 2.0.7
installed with the following in my httpd.conf:

<VirtualHost 10.69.1.11>
ServerName helpfish.qa.tripwire.com
ServerAlias helpfish
DocumentRoot /local/rt2/WebRT/html
PerlModule Bundle::DBI
^^^^^^^^^^^
This doesn’t do anything; it should be Apache::DBI. Bundle::DBI
is an empty module (i.e., devoid of Perl).

That was my point. Having that misconfigured on my server does
not seem to be having any ill effects. Since I’m in the process
of replacing that server, and the current one is presently
working, I’m leaving it alone.

Ah, I see.

The thing is, Apache::DBI is not necessary; it never is. All
it does is redefine a few DBI class methods, so that connections
are persistant until a child exits (that’s an over-simplification,
but essentially true). It makes database access faster, because
the connections to the database are already open, but removing it
will not cause the database or the app to stop working (unless
you are hitting a performance ceiling). The way Apache::DBI and
DBI are set up, if you load DBI before Apache::DBI in your
httpd.conf, Apache::DBI does not do anything (DBI checks for the
existence of Apache::DBI and modifies itself accordingly, not the
other way around).

In fact, Apache::DBI can cause problems, if your database can’t
handle the number of persistant connections that you are trying
to maintain. For example, a mod_perl server with a lot of
independent modules, each with their own db to connect to (all
running on the same database instance) will each have their own
persistent DBI connection under Apache::DBI. With (for example)
10 different modules, and 16 Apache children, we now have 160
persistent connections to the database (keep in mind that
Apache::DBI caches connections based on the variables used to
connect initially; any change in the DBD string means a new
persistent connection). If you are running that app on a web
farm, say three machines, we’ve just jumped to 480 persistent
connections to your database machine. If the box running your db
is beefy enough, and well configured, this may not phase you; but
then again, if your boxen are beefy enough, you may not need
Apache::DBI.

All that being said, if you are running a single app on a single
httpd, accessing a single db server, then Apache::DBI can make a
huge difference, especially on databases like Oracle on which
connecting is expensive.

(darren)

Buying books would be a good thing if one could also buy the time to
read them in: but as a rule the purchase of books is mistaken for the
appropriation of their contents.
– Arthur Schopenhauer