I’m trying to install rt-1.0.2. The CLI appears to work but the
web interface doesn’t. Attempting to use the web scripts,
I get “Internal Server Error… Premature end of script
headers: …”
When I run the admin-webrt.cgi and webrt.cgi files
at a Unix command-line, what appears to be
the correct HTML is displayed.
perl 5.004p4, CGI.pm 2.56, apache 1.3.3, FreeBSD 2.2.6.
Why would the scripts appear to work from a command-line,
but not from a browser?
Help?
I’m trying to install rt-1.0.2. The CLI appears to work but the
web interface doesn’t. Attempting to use the web scripts,
I get “Internal Server Error… Premature end of script
headers: …”
Apache’s error logs should have more info than that.
What happens when you run the cgi from the commandline as the user
that apache runs as?
When I run the admin-webrt.cgi and webrt.cgi files
at a Unix command-line, what appears to be
the correct HTML is displayed.perl 5.004p4, CGI.pm 2.56, apache 1.3.3, FreeBSD 2.2.6.
Why would the scripts appear to work from a command-line,
but not from a browser?Help?
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Pelcgb-serrqbz abj!
At 11:17 PM 3/8/2000 -0500, you wrote:
I’m trying to install rt-1.0.2. The CLI appears to work but the
web interface doesn’t. Attempting to use the web scripts,
I get “Internal Server Error… Premature end of script
headers: …”Apache’s error logs should have more info than that.
Apache’s error logs show:
[Wed Mar 8 10:55:41 2000] [error] [client 138.23.168.101] Premature end of
script headers: /h/webdata/cgi-bin/admin-webrt.cgi
Can’t locate /usr/local/reqtrack/etc/config.pm in @INC (@INC contains:
/usr/local/lib/perl5/i386-freebsd/5.00404 /usr/local/lib/perl5
/usr/local/lib/perl5/site_perl/i386-freebsd /usr/local/lib/perl5/site_perl
/usr/local/reqtrack/lib) at /usr/local/reqtrack/bin/rtmux.pl line 20.
What happens when you run the cgi from the commandline as the user
that apache runs as?
$ ./admin-webrt.cgi
Can’t locate /usr/local/reqtrack/etc/config.pm in @INC (@INC contains:
/usr/local/lib/perl5/i386-freebsd/5.00404 /usr/local/lib/perl5
/usr/local/lib/perl5/site_perl/i386-freebsd /usr/local/lib/perl5/site_perl
/usr/local/reqtrack/lib) at /usr/local/reqtrack/bin/rtmux.pl line 20.
/usr/local/reqtrack/etc/config.pm does exist:
total 13
dr-xr-x— 3 reqtrack reqtrack 512 Mar 8 10:15 .
dr-xr-xr-x 6 root wheel 512 Mar 8 10:15 …
-r-xr-x–x 1 reqtrack reqtrack 3529 Mar 8 10:15 config.pm
-r-xr-x–x 1 reqtrack reqtrack 3606 Sep 30 21:22 config.pm.old
-r-xr-x–x 1 reqtrack reqtrack 516 Mar 8 10:15 mysql.acl
-r-xr-x–x 1 reqtrack reqtrack 561 Feb 20 1999 mysql.acl.orig
drwxr-x— 3 reqtrack reqtrack 512 Mar 8 10:15 templates
Barnett Hsu Voicemail: (714) 989-3100 x 1461
E-mail: hsub@softhome.net Web: http://bhworld.cjb.net/
PGP Public Key at Barnett's PGP Public Keys
That sounds like a permissions problem. Either some parent of reqtrack isn’t readable
by nobody or webrt.cgi has lost its setuidness
jesseOn Wed, Mar 08, 2000 at 10:03:35PM -0800, Barnett Hsu wrote:
At 11:17 PM 3/8/2000 -0500, you wrote:
On Wed, Mar 08, 2000 at 01:05:26PM -0800, Barnett Hsu wrote:
I’m trying to install rt-1.0.2. The CLI appears to work but the
web interface doesn’t. Attempting to use the web scripts,
I get “Internal Server Error… Premature end of script
headers: …”Apache’s error logs should have more info than that.
Apache’s error logs show:
[Wed Mar 8 10:55:41 2000] [error] [client 138.23.168.101] Premature end of
script headers: /h/webdata/cgi-bin/admin-webrt.cgi
Can’t locate /usr/local/reqtrack/etc/config.pm in @INC (@INC contains:
/usr/local/lib/perl5/i386-freebsd/5.00404 /usr/local/lib/perl5
/usr/local/lib/perl5/site_perl/i386-freebsd /usr/local/lib/perl5/site_perl
/usr/local/reqtrack/lib) at /usr/local/reqtrack/bin/rtmux.pl line 20.What happens when you run the cgi from the commandline as the user
that apache runs as?$ ./admin-webrt.cgi
Can’t locate /usr/local/reqtrack/etc/config.pm in @INC (@INC contains:
/usr/local/lib/perl5/i386-freebsd/5.00404 /usr/local/lib/perl5
/usr/local/lib/perl5/site_perl/i386-freebsd /usr/local/lib/perl5/site_perl
/usr/local/reqtrack/lib) at /usr/local/reqtrack/bin/rtmux.pl line 20./usr/local/reqtrack/etc/config.pm does exist:
cd /usr/local/reqtrack/etc
ls -la
total 13
dr-xr-x— 3 reqtrack reqtrack 512 Mar 8 10:15 .
dr-xr-xr-x 6 root wheel 512 Mar 8 10:15 …
-r-xr-x–x 1 reqtrack reqtrack 3529 Mar 8 10:15 config.pm
-r-xr-x–x 1 reqtrack reqtrack 3606 Sep 30 21:22 config.pm.old
-r-xr-x–x 1 reqtrack reqtrack 516 Mar 8 10:15 mysql.acl
-r-xr-x–x 1 reqtrack reqtrack 561 Feb 20 1999 mysql.acl.orig
drwxr-x— 3 reqtrack reqtrack 512 Mar 8 10:15 templates
Barnett Hsu Voicemail: (714) 989-3100 x 1461
E-mail: hsub@softhome.net Web: http://bhworld.cjb.net/
PGP Public Key at Barnett's PGP Public Keys
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Gur SOV jnagf gb znxr guvf fvt vyyrtny.
At 10:10 AM 3/9/2000 -0500, you wrote:
That sounds like a permissions problem. Either some parent of reqtrack
isn’t readable
by nobody or webrt.cgi has lost its setuidness
Ok. It looks like it was a permissions problem.
I had to change the permissions on /usr/local/reqtrack/etc
itself to be world read/execute. All of the parents of
that directory were already world read/execute. After
changing the permissions, the web interface appeared in
my browser.
While playing around with changing the priority of
requests and so forth, I discovered I needed to change
the permissions of /usr/local/reqtrack/etc/templates
and its subdirectories to be world read/execute as well.
Otherwise, the e-mails that get sent out regarding
the transactions contain only an error message.
So far my co-workers and I have been impressed with
Request Tracker’s web interface. However, unless
I missed something somewhere, I noticed that there
doesn’t seem to be any way to display the transactions
themselves in both the cli and web interfaces. Only
the transaction history can be displayed? So it appears
I would have to save all of the e-mail or I won’t
have the contents of the requestor’s e-mail and
so forth to refer back to?
Barnett Hsu Voicemail: (714) 989-3100 x 1461
E-mail: hsub@softhome.net Web: http://bhworld.cjb.net/
PGP Public Key at Barnett's PGP Public Keys
So far my co-workers and I have been impressed with
Request Tracker’s web interface. However, unless
I missed something somewhere, I noticed that there
doesn’t seem to be any way to display the transactions
themselves in both the cli and web interfaces. Only
the transaction history can be displayed? So it appears
I would have to save all of the e-mail or I won’t
have the contents of the requestor’s e-mail and
so forth to refer back to?
That also sounds like a permissions problem. If the RT scripts running
from the web server cannot read the transactions, that is how it will
look. Go back to the install documentation and check every step.
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.
At 12:01 PM 3/10/2000 +1100, Charlie Brady wrote:
That also sounds like a permissions problem. If the RT scripts running
from the web server cannot read the transactions, that is how it will
look. Go back to the install documentation and check every step.
I already went through the install documentation
when I discovered the first problem. But anyway,
yes, this one was a permissions problem as well.
I had to make the transactions directory and all
of its subdirectories world readable/executable.
Then I discovered that if I tried to reply to a
requestor via the web interface, that also results
in the “Internal Server Error” web page. I ended
up having to make the transactions directory and
its subdirectories be world writable too. Then
that worked.
I never expected to have permissions problems –
permissions were set by the Makefile and I didn’t
change any permissions until after I got the
“Internal Server Error” pages. Considering the
scripts were setuid, I would have thought there
wouldn’t be any permissions problems…
Oh well, thanks to all for the help.
At 12:01 PM 3/10/2000 +1100, Charlie Brady wrote:
That also sounds like a permissions problem. If the RT scripts running
from the web server cannot read the transactions, that is how it will
look. Go back to the install documentation and check every step.I already went through the install documentation
when I discovered the first problem. But anyway,
yes, this one was a permissions problem as well.
I had to make the transactions directory and all
of its subdirectories world readable/executable.
You shouldn’t need to do that. You should find a solution which works
correctly without being too promiscuous. You may need to change some
ownership, or something else, but you should seek a solution which
is less drastic.
…
I never expected to have permissions problems –
permissions were set by the Makefile and I didn’t
change any permissions until after I got the
“Internal Server Error” pages. Considering the
scripts were setuid, I would have thought there
wouldn’t be any permissions problems…
Are you sure that the setuid is working? You aren’t mounting via NFS are
you?
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.
Barnett Hsu wrote:
At 10:10 AM 3/9/2000 -0500, you wrote:
That sounds like a permissions problem. Either some parent of reqtrack
isn’t readable
by nobody or webrt.cgi has lost its setuidnessOk. It looks like it was a permissions problem.
I had to change the permissions on /usr/local/reqtrack/etc
itself to be world read/execute. All of the parents of
that directory were already world read/execute. After
changing the permissions, the web interface appeared in
my browser.
Actually, I found on my system that I needed to change permissions to
allow SUID (chmod +s … ). In my opinion this slightly more secure than
allowing world read and execute access. I believe this was required
because Apache runs as wwwrun.nogroup and rt was attempting to change to
a different user which caused a permissions failure in absence of the
SUID attribute.
Steve
Webrt.cgi wasn’t suid by default?On Fri, Mar 10, 2000 at 06:33:07AM -0800, Steve Isaacs wrote:
Barnett Hsu wrote:
At 10:10 AM 3/9/2000 -0500, you wrote:
That sounds like a permissions problem. Either some parent of reqtrack
isn’t readable
by nobody or webrt.cgi has lost its setuidnessOk. It looks like it was a permissions problem.
I had to change the permissions on /usr/local/reqtrack/etc
itself to be world read/execute. All of the parents of
that directory were already world read/execute. After
changing the permissions, the web interface appeared in
my browser.Actually, I found on my system that I needed to change permissions to
allow SUID (chmod +s … ). In my opinion this slightly more secure than
allowing world read and execute access. I believe this was required
because Apache runs as wwwrun.nogroup and rt was attempting to change to
a different user which caused a permissions failure in absence of the
SUID attribute.Steve
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
. . . when not in doubt, get in doubt. – Old Discordian Proveb
Jesse wrote:
Webrt.cgi wasn’t suid by default?
Not when I installed. Did I miss something?
Steve
I don’t know. Let me poke at things.On Fri, Mar 10, 2000 at 08:50:22AM -0800, Steve Isaacs wrote:
Jesse wrote:
Webrt.cgi wasn’t suid by default?
Not when I installed. Did I miss something?
Steve
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Gur SOV jnagf gb znxr guvf fvt vyyrtny.
Ok. that’s just wrong [tm]
Can anyone who’s seeing this behavior send me an ls -lR of a clean RT install
along with what platform you’re on etc…
It doesn’t appear to happen on installs I do.
jesseOn Fri, Mar 10, 2000 at 10:57:37AM -0500, Jesse wrote:
I don’t know. Let me poke at things.
On Fri, Mar 10, 2000 at 08:50:22AM -0800, Steve Isaacs wrote:
Jesse wrote:
Webrt.cgi wasn’t suid by default?
Not when I installed. Did I miss something?
Steve
–
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91Gur SOV jnagf gb znxr guvf fvt vyyrtny.
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
pretty soon we’re going to HAVE to have hypertext mail!
–Tim Berners Lee. (8 Jan 1993 on www-talk)
Webrt.cgi wasn’t suid by default?
Not when I installed. Did I miss something?
Did you run install as either 1) the rt user or 2) as root? If not
did you see any kind of error message?
– Daniel R. danielr@ccs.neu.edu [http://www.ccs.neu.edu/home/danielr/]
Daniel Rinehart wrote:
Webrt.cgi wasn’t suid by default?
Not when I installed. Did I miss something?Did you run install as either 1) the rt user or 2) as root? If notdid you see any kind of error message?
– Daniel R. danielr@ccs.neu.edu [http://www.ccs.neu.edu/home/danielr/]
I ran the install as root and didn’t notice any error messages.
Steve
At 04:32 PM 3/10/2000 +1100, Charlie Brady wrote:
I never expected to have permissions problems –
permissions were set by the Makefile and I didn’t
change any permissions until after I got the
“Internal Server Error” pages. Considering the
scripts were setuid, I would have thought there
wouldn’t be any permissions problems…Are you sure that the setuid is working? You aren’t mounting via NFS are
you?
Well, in my case, this turns out to be what was wrong.
The partitions were local partitions, not NFS. However,
it turns out the partition where the scripts were at
was mounted with the nosuid option. (oops…)
After my boss remounted the partition without the nosuid
option and I ran “make fixperms” to get rid of the
permission changes I made trying to fix the problem,
RT works perfectly. We’ve now switched from the
software we were previously using over to RT.
Thanks all for the help.
Barnett Hsu Voicemail: (714) 989-3100 x 1461
E-mail: hsub@softhome.net Web: http://bhworld.cjb.net/
PGP Public Key at Barnett's PGP Public Keys
Well, in my case, this turns out to be what was wrong.
The partitions were local partitions, not NFS. However,
it turns out the partition where the scripts were at
was mounted with the nosuid option. (oops…)
That could certainly do it 
After my boss remounted the partition without the nosuid
option and I ran “make fixperms” to get rid of the
permission changes I made trying to fix the problem,
RT works perfectly. We’ve now switched from the
software we were previously using over to RT.
Cool! wIncidentally, what were you using before?
Thanks all for the help.
Barnett Hsu Voicemail: (714) 989-3100 x 1461
E-mail: hsub@softhome.net Web: http://bhworld.cjb.net/
PGP Public Key at Barnett's PGP Public Keys
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
…realized that the entire structure of the net could be changed to be made
more efficient, elegant, and spontaneously make more money for everyone
involved. It’s a marvelously simple diagram, but this form doesn’t have a way
for me to draw it. It’ll wait. -Adam Hirsch
At 12:12 AM 3/14/2000 -0500, Jesse wrote:
Cool! wIncidentally, what were you using before?
reqng 1.3.9.
Barnett Hsu Voicemail: (714) 989-3100 x 1461
E-mail: hsub@softhome.net Web: http://bhworld.cjb.net/
PGP Public Key at Barnett's PGP Public Keys