Troubleshooting RT FastCGI Problems

RT Users
1

I’m having some sudden difficulty with RT and FastCGI.

I recently upgraded RT to the latest version from the previous release
last week. Once I got FastCGI installed it worked without problems. I
changed from the Apache module approach because of some other issues I
was having that I wanted to isolate.

Now I’m getting 500 Server Errors from Apache when I go to /rt on my
server.

Here is the config:

RT-related configuration directives

AddDefaultCharset UTF-8
AddHandler fastcgi-script fcgi
<Directory “/opt/rt3/share/html”>
Options FollowSymLinks ExecCGI
AllowOverride None

Pass through requests to for noauth

Alias /NoAuth/ /opt/rt3/share/html/NoAuth/
ScriptAlias /rt /opt/rt3/bin/mason_handler.fcgi

FastCgiServer /opt/rt3/bin/mason_handler.fcgi -idle-timeout 120

When I start apache I see this in error_log:

[Wed May 25 11:34:16 2005] [crit] (13)Permission denied: FastCGI: can’t
create server “/opt/rt3/bin/mason_handler.fcgi”: bind() failed
[/etc/httpd/logs/fastcgi/362fab4db3d651b6d082c0358ebb4d83]

Here are the perms on /etc/httpd/logs/fastcgi (/etc/httpd/logs is a
symlink to /var/log/httpd):

root@ws1:fastcgi# find /var/log/httpd/fastcgi -ls
588939 4 drwxrwxrwx 3 apache apache 4096 May 25 11:26
/var/log/httpd/fastcgi
588940 4 drwxrwxrwx 2 apache apache 4096 May 13 10:54
/var/log/httpd/fastcgi/dynamic

After a bit more head-scratching, and trying to manually set a
FastCgiIpcDir in /tmp, I found that /var/log/httpd was permitted 700
root:root. chmod 755 /var/log/httpd fixed the problem. I upgraded
Apache this week (RHEL3 release stream) and the patch must have
repermitted /var/log/httpd.

I’m finding RT to be quite fragile. :slight_smile:

-brian

Brian W. Spolarich ~ IT Consultant ~ USCAR ~ +1-248-223-9044

2

After a bit more head-scratching, and trying to manually set
a FastCgiIpcDir in /tmp, I found that /var/log/httpd was
permitted 700 root:root. chmod 755 /var/log/httpd fixed the
problem. I upgraded Apache this week (RHEL3 release stream)
and the patch must have repermitted /var/log/httpd.

I’m finding RT to be quite fragile. :slight_smile:

So RT is fragile because Red Hat reset the permissions on
/var/log/httpd?

What’s more fragile is your evalution of Red Hat’s updates.

Chris Covington
IT
Plus One Health Management
75 Maiden Lane Suite 801
NY, NY 10038
646-312-6269
http://www.plusoneactive.com

3

I’m finding RT to be quite fragile. :slight_smile:

So RT is fragile because Red Hat reset the permissions on
/var/log/httpd?

What’s more fragile is your evalution of Red Hat’s updates.

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.

4

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.

Cheers,
– jra
Jay R. Ashworth jra@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
5

rt-users-bounces@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. 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.

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

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.

Regards,

-brian

6

rt-users-bounces@lists.bestpractical.com 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. :slight_smile:

     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. :slight_smile:

:slight_smile:

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@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