We’ve just started using RT1 and are very happy with it. We’re not quite ready
to start experimenting with RT2, but I’m subscribed to this list so I can keep
up to date with developments.
I’ve seen references to RT2 working best with apache+mod_perl, but that it can
be used via CGI at some performance cost.
Is the fact that it works best with mod_perl simply because Mason works best
with mod_perl or are there other reasons? I found a reference on the mason web
site (Mason+Poet: Home) that
described how to run mason via CGI. The person who wrote it said he didn’t
notice any performance problems, though their mason components weren’t heavily
used and performance wasn’t critical to them.
I saw an earlier message on this list from Tobias (“Errors with perl 5.6”,
Fri, 9 Jun 2000 16:57:16 +0200) in which he said:
You’re lucky, when I tried installing mod_perl, it crashed even without
and perl handlers at all.
…
I have no clue about webmux.pl, I’m using CGI. If you also would like to
run CGI, I might give you a snapshot of my rtmux.pl.
This suggests that it is possible to run RT2 without mod_perl. Does this
require using the technique described in the reference above, or is there some
other (better suited to RT?) way?
And if one of the main developers of RT2 is currently not using mod_perl, will
that be a “supported” option when RT2 is released?
Our concerns about having to run apache+mod_perl in order to run RT2 are the
increased complexity/load for our web server and that that our request tracker
database might then have to be accessible to the uid that the web server runs
as.
Is the fact that it works best with mod_perl simply because Mason works best
with mod_perl or are there other reasons?
The major reason why mod_perl will be faster is that we don’t have to do
the startup & initializing overhead each time the script is run, and that
it’s possible to use caches. This is feasible with stuff like FCGI
and eventually IPC::Shareable as well, so I don’t think it will be that
different. Though, FCGI requires a library linked into perl [sic], I
haven’t done that yet (thought I should wait until 5.6.1 is around before
recompiling my perl), so I don’t know. Plain CGI is awfully slow.
I found a reference on the mason web
site (Mason+Poet: Home) that
described how to run mason via CGI. The person who wrote it said he didn’t
notice any performance problems, though their mason components weren’t heavily
used and performance wasn’t critical to them.
We’ve read that, and I’ve copied something from there.
I have no clue about webmux.pl, I’m using CGI. If you also would like to
run CGI, I might give you a snapshot of my rtmux.pl.
This suggests that it is possible to run RT2 without mod_perl.
(…)
And if one of the main developers of RT2 is currently not using mod_perl, will
that be a “supported” option when RT2 is released?
Yes. When RT 2.0 is shipped, it should be trivial to set it up using CGI
or FCGI instead of mod_perl.
Our concerns about having to run apache+mod_perl in order to run RT2 are the
increased complexity/load for our web server
I don’t think the load will be increased, but there are some complexity;
I have a feeling that debugging will be harder, and that the web server
will be more fragile.
Though Mason do have some excellent debugging functionality … which I
haven’t studied too much because I didn’t want to fight setting it up
without mod_perl.
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”
On Thu, 15 Jun 2000, Tobias Brox wrote (in response to comments from
Duncan McEwan):
Our concerns about having to run apache+mod_perl in order to run RT2 are the
increased complexity/load for our web server
I don’t think the load will be increased, but there are some complexity;
I have a feeling that debugging will be harder, and that the web server
will be more fragile.
Though Mason do have some excellent debugging functionality … which I
haven’t studied too much because I didn’t want to fight setting it up
without mod_perl.
But Duncan went on to say:
and that that our request tracker database might then have to be
accessible to the uid that the web server runs as.
Which Tobias did not answer. That’s too important a question to duck that
way. Unless you run a seperate apache+mod_perl just for RT, then the
database needs to be writable to “www” (or whatever apache runs as), if
you run under mod_perl. At least that’s my understanding. Correct me if
I’m wrong.
I’m also quite surprised that you are doing development under 5.6.0. That
doesn’t sound like a good way to get something out that will run on the
thousands (millions?) of sites running earlier versions for years to come.
[Disclaimer: of course I have no right to say this, because I’m not doing
the work, and I haven’t even been paying attention for months (busy doing
other stuff).]
Charlie Brady
Aurema Pty Ltd
PO Box 305, Strawberry Hills, NSW 2012, Australia Email:charlieb@aurema.com, Tel: +61 2 9698 2322, Fax: +61 2 9699 9174
“I think it would be a good idea.” Gandhi, on Western Civilisation.
and that that our request tracker database might then have to be
accessible to the uid that the web server runs as.
Which Tobias did not answer. That’s too important a question to duck that
way.
Well … yeah, it is - and it’s a problematic issue. The original idea
was to put the perl script setgid, and have the config.pm where the
database password is stored readable only for the rt group. This breaks a
bit for mod_perl, and might add significal complexity to the
installation (some web servers and mail servers don’t like
suid/sgid-scripts, some OSes don’t provide it to scripts, etc). I don’t
know what the best idea is, though Jesse mumbled something about a
client/server version.
I guess we should discuss the alternatives closer at RTCon.
My old idea about this problem, in general, is that the password from the
user should be used for gaining access to the database, and that ACL
complexity should be handled over to the DBMS. Actually I even think it
might work for mysql, because mysql have a very fine-grained ACL system
(it’s possible to set ACLs for single rows, isn’t it?).
I’m also quite surprised that you are doing development under 5.6.0. That
doesn’t sound like a good way to get something out that will run on the
thousands (millions?) of sites running earlier versions for years to come.
I have installed 5.6.0, but officially we are to support 5.005. And you
do have a point, I’ve already gotten complaints because I’ve
unknowingly written stuff that only worked for 5.6.0.
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”
I’m also quite surprised that you are doing development under 5.6.0. That
doesn’t sound like a good way to get something out that will run on the
thousands (millions?) of sites running earlier versions for years to come.
despite claims to the contrary, 5.6.0 IS the stable release of perl, and,
excepting mod_peril, it runs very nicely. rt is in development,
anyways. you can expect the 5.6 series to continue to stabilize, but if
you’re developing to a 5.0 perl, you might very well run into major
issues with deprecated interfaces, etc.
that said, rt doesn’t work with 5.6 and mod_perl - or at least, i have not
been able to get it to work.
Blue Lang Unix Systems Admin
QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604
Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015
that said, rt doesn’t work with 5.6 and mod_perl - or at least, i have not
been able to get it to work.
Jesse has been able to get it work with mod_perl and 5.005, and I’ve
gotten it work with CGI and perl 5.6.0 … so you’d better try harder
bah, 5.005 is easy - there is a whole mailing list devoted to ‘why won’t
mod_perl run under 5.6?’ it will be a while before the 5.6/mod_perl
combo is ironed out. apparently the large file support in perl makes
mod_perl blow up - or some such. i’ve been put on SQL parser deathwatch at
work, so my rt hacking time is gone for a while.
always got time to mouth off on the list, tho.
if anyone else wants to try it under 5.6, i can relay the info i got from
the mod_perl list wrt what is probably happening.
Blue Lang Unix Systems Admin
QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604
Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015
I’m also quite surprised that you are doing development under 5.6.0. That
doesn’t sound like a good way to get something out that will run on the
thousands (millions?) of sites running earlier versions for years to come.
I have installed 5.6.0, but officially we are to support 5.005. And you
do have a point, I’ve already gotten complaints because I’ve
unknowingly written stuff that only worked for 5.6.0.
If I werebn’t on the road, I’m the one who would be complaining at tobias about
this. 5.005 is the current minimum requirement for RT2. I run RT2 on 5.005 and
will be for a while
jesse
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”
jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Transporters are so ungodly. if god had wanted us to travel great distances
instantaneously, he would have given us an internal
materialisation/dematerialisation control.
– Shoshe Cole
it will be a while before the 5.6/mod_perl