[rt-users] Troubleshooting RT FastCGI Problems

Jay R. Ashworth jra at baylink.com
Tue May 31 23:41:37 EDT 2005


On Tue, May 31, 2005 at 08:55:10AM -0400, Brian W. Spolarich wrote:
> rt-users-bounces at lists.bestpractical.com wrote:
> > On Wed, May 25, 2005 at 01:23:36PM -0400, Jon Daley wrote:
> >>  	I was hoping he was joking and didn't mean it at all.  On a
> >> side-topic, I have not been impressed with redhat's up2date.  My
> >> day-job's ISP uses up2date to update the web server occasionally, and
> >> I think about 30% of the time it has caused an outage of one kind or
> >> another.  I guess you have to have two servers, to make
> >> sure the updates don't break stuff.
> > 
> > OT: Yes, you do.  Don't ever run updates cold on a production
> > server, if you can at all help it.
> 
>   I'm a little surprised at the snarkiness of the responses to my
> comment.

No, no, no... I watch House, and Buffy: that wasn't snarky.  :-)

>          I'm very familiar with the "lets have an complete and
> duplicate test environment" philosophy, which is great if you're running
> a systems engineering department with lots of staff (which I have done).
> In my current role I have an IT department of one (myself, half-time)
> and hosted servers with a dedicated hosting provider.  Having a
> duplicate test environment is unrealistic.

And sometimes, that's what you have to deal with.

>   I did bother to offer my experiences because I thought they might be
> actually helpful to others. :-)

:-)

>   RT _IS_ a rather fragile and picky application -- it has lots of
> external dependencies, is relatively hard to install, and I've been able
> to break it inadvertently on a number of occasions.  That doesn't mean
> RT isn't a very good application -- its definitely the best thing out
> there in the OSS space in my opinion, and I like much of the design
> philosophy behind it.  But that doesn't mean it couldn't be more
> self-contained.

It's interesting that you expand this so well; between RT, Seagull and
the Horde, and WebGUI, I've been giving a lot of thought myself lately
to componentized software, and the tradeoffs you impose on your users
because you decided to build it that way/they take on themselves to put
up with because they like your package.

It's not a value judgement against developers who go there, by any
means.  But there certainly *are* considerations to using packages that
work that way, as you note.  textdeps/fixdeps is one of the better
installer/text packages for such environments that I have seen.

But I can't help thinking that someone needs to package up that, as
well as the best of the environment testing methodologies from other
major packages of this ilk, and turn it loose for everyone who's
working in that "large componentized package" space...

Some of it, I suspect, in internal; your packages need to know what
resources they need, and test for them at runtime, and probably the
development management environment needs to have a good way of pinning
down specific breakage that comes from that, as opposed to other
things.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

      If you can read this... thank a system administrator.  Or two.  --me



More information about the rt-users mailing list