CGI::Vars


#1

I’m not sure if my problem here (see excerpt from apache error log
below) has to do with the version of CGI.pm I’m running (in regard to
the FAQ Q2.6: “What do I do when RT can’t locate CGI::Vars” / “Your
version of CGI.pm is out of date. Please upgrade to at least version
2.53.”). The browser reports “Internal Server Error” when trying to load
the RT login page.

apache error log:
[Tue Aug 29 09:33:24 2000] [error] [client xxx.xxx.xxx.xxx] Premature
end of script headers: /usr/local/rt/bin/cgi/webrt.cgi
Undefined subroutine CGI::Vars

Perl 5.00503 is installed, and as far as I know, we’ve been running RT
with whatever version of CGI.pm gets installed with Perl 5.005. Can
anyone tell me how to verify what version CGI.pm is at and if I need to
upgrade? More docs to read? Thanks.


#2

Emm… most likely your problem is a lack of ANY CGI.pm.
I don’t believe it’s a standard part of perl.

Read the README file in rt, make sure you have installed all the software
listed there. Everything listed would not by default be on your machine. So
you’ll have to install Digest-MD5, Msql-Mysql-modules, CGI.pm-2.56 and so on
before you can install RT cleanly.

-Feargal.

Feargal Reilly,
Systems Administrator,
The CIA.
+353-86-8157621


#3

Thanks. RT was running yesterday, as it has been for months, so I’m
assuming that all the dependencies have been in place. We have over 1000
requests logged, and it’s a great tool, by the way.

Instead, I’m poring through logs and bash histories of the root account
and the acounts of three other admins who’ve worked on this box over the
past year to see what might have been done recently. Turns out, someone
just installed arkeia. However, the binaries and logs seem to be all
fairly neatly packaged in it’s default install location (/usr/knox/).

So what else? mysqld is running. I can even interact with the rt
database with the command line mysql interface. I also have another
mysql database on the machine that I can access via web pages using
mysql_connect to make queries – so I’m pretty sure at least the mysql
parts are working as they should be. As for CGI.pm, it’s there, I just
don’t know what version it is.

I certainly will check the readme, but I don’t think this is the right
direction.

Feargal Reilly wrote:


#4

It actually sounds to me like something reverted your CGI.pm to an older version.

What does perl -MCGI -e’print $CGI::VERSION’;
tell you?On Tue, Aug 29, 2000 at 10:50:05AM -0400, Neil Curri wrote:

Thanks. RT was running yesterday, as it has been for months, so I’m
assuming that all the dependencies have been in place. We have over 1000
requests logged, and it’s a great tool, by the way.

Instead, I’m poring through logs and bash histories of the root account
and the acounts of three other admins who’ve worked on this box over the
past year to see what might have been done recently. Turns out, someone
just installed arkeia. However, the binaries and logs seem to be all
fairly neatly packaged in it’s default install location (/usr/knox/).

So what else? mysqld is running. I can even interact with the rt
database with the command line mysql interface. I also have another
mysql database on the machine that I can access via web pages using
mysql_connect to make queries – so I’m pretty sure at least the mysql
parts are working as they should be. As for CGI.pm, it’s there, I just
don’t know what version it is.

I certainly will check the readme, but I don’t think this is the right
direction.

Feargal Reilly wrote:

Emm… most likely your problem is a lack of ANY CGI.pm.
I don’t believe it’s a standard part of perl.

Read the README file in rt, make sure you have installed all the software
listed there. Everything listed would not by default be on your machine. So
you’ll have to install Digest-MD5, Msql-Mysql-modules, CGI.pm-2.56 and so on
before you can install RT cleanly.

-Feargal.


Feargal Reilly,
Systems Administrator,
The CIA.
+353-86-8157621

I’m not sure if my problem here (see excerpt from apache error log
below) has to do with the version of CGI.pm I’m running (in regard to
the FAQ Q2.6: “What do I do when RT can’t locate CGI::Vars” / “Your
version of CGI.pm is out of date. Please upgrade to at least version
2.53.”). The browser reports “Internal Server Error” when trying to load
the RT login page.

apache error log:

[Tue Aug 29 09:33:24 2000] [error] [client xxx.xxx.xxx.xxx] Premature
end of script headers: /usr/local/rt/bin/cgi/webrt.cgi
Undefined subroutine CGI::Vars

Perl 5.00503 is installed, and as far as I know, we’ve been running RT
with whatever version of CGI.pm gets installed with Perl 5.005. Can
anyone tell me how to verify what version CGI.pm is at and if I need to
upgrade? More docs to read? Thanks.


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


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


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

jesse reed vincent — root@eruditorum.orgjesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Emacs is a pretty good operating system, but Unix has a better editor.


#5

If it’s giving that error, and it works via the command line then
something must have happened to your CGI::Vars.

Try a:

perl -e 'for (@INC) {printf “%d %s\n”, $i++, $_ } ’

to see where perl is looking for the various modules.

Then search these localtions for CGI.pm
If you take a look in that file it’ll tell you what version it is:

$CGI::VERSION=‘2.66’;

I think you need CGI.pm > 2.53 for RT. 2.66 is the latest I think.

I suspect it is there, but your @INC array may not include a reference to
where it is, and as such the perl web interface is not working.

Good luck,

Paul


#6

Jesse wrote:

It actually sounds to me like something reverted your CGI.pm to an older version.

Yeah, I have 2 copies of CGI.pm. The one that I think webrt.cgi must be
calling is in /usr/lib/perl5/5.00503/, it’s at version 2.46. The other
CGI.pm - version 2.62 - is in a subdirectory of /tmp, along with some
other modules (but they’re all grouped under the directory called
"CGI.pm-2.62", so I assume they all have to do with CGI.pm). A search
for “CGI.pm” yielded:

/tmp/.cpan/build/CGI.pm-2.62
/tmp/.cpan/build/CGI.pm-2.62/examples
/tmp/.cpan/build/CGI.pm-2.62/examples/WORLD_WRITABLE
/tmp/.cpan/build/CGI.pm-2.62/CGI
/tmp/.cpan/build/CGI.pm-2.62/t
/tmp/.cpan/build/CGI.pm-2.62/blib
/tmp/.cpan/build/CGI.pm-2.62/blib/lib
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/auto
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/auto/CGI
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Util.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Carp.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Fast.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Push.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Pretty.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Cookie.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Apache.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Switch.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/arch
/tmp/.cpan/build/CGI.pm-2.62/blib/arch/auto
/tmp/.cpan/build/CGI.pm-2.62/blib/arch/auto/CGI
/tmp/.cpan/build/CGI.pm-2.62/blib/man3
/usr/lib/perl5/5.00503/CGI.pm

Each one of these modules - util.pm, Carp.pm, Fast.pm, etc… - have a
corresponding partner in /usr/lib/perl5/5.00503/, and each module in the
/tmp directory is a more recent version than the ones in
/usr/lib/perl5/5.00503. So, just in the way of getting RT back up, could
I just move these newer modules into their respective places in
/usr/lib/perl5/5.00503/?

The modification dates of these files (including the 2.62 CGI.pm) go
only as late as March of this year. Hmm, I was thinking redhat’s update
script be the culprit, but if it were, and these were recent updates, I
would expect that the “newer” CGI.pm would be at the current version
(2.66, I believe), and the modification dates would read yesterday, not
march. My only other guess is that Arkeia (backup software that someone
else installed yesterday) uses perl, and might have done something while
it was checking for perl libraries? Guess I’m on my own there.


#7

I think the “right” thing to do is just install a new version of CGI.pm
from cpan. it’s pretty easy. Just type the following and let perl do all the work…

perl -MCPAN -eshell
install CGIOn Tue, Aug 29, 2000 at 12:07:59PM -0400, Neil Curri wrote:

Jesse wrote:

It actually sounds to me like something reverted your CGI.pm to an older version.

Yeah, I have 2 copies of CGI.pm. The one that I think webrt.cgi must be
calling is in /usr/lib/perl5/5.00503/, it’s at version 2.46. The other
CGI.pm - version 2.62 - is in a subdirectory of /tmp, along with some
other modules (but they’re all grouped under the directory called
"CGI.pm-2.62", so I assume they all have to do with CGI.pm). A search
for “CGI.pm” yielded:

/tmp/.cpan/build/CGI.pm-2.62
/tmp/.cpan/build/CGI.pm-2.62/examples
/tmp/.cpan/build/CGI.pm-2.62/examples/WORLD_WRITABLE
/tmp/.cpan/build/CGI.pm-2.62/CGI
/tmp/.cpan/build/CGI.pm-2.62/t
/tmp/.cpan/build/CGI.pm-2.62/blib
/tmp/.cpan/build/CGI.pm-2.62/blib/lib
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/auto
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/auto/CGI
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Util.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Carp.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Fast.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Push.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Pretty.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Cookie.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Apache.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI/Switch.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/lib/CGI.pm
/tmp/.cpan/build/CGI.pm-2.62/blib/arch
/tmp/.cpan/build/CGI.pm-2.62/blib/arch/auto
/tmp/.cpan/build/CGI.pm-2.62/blib/arch/auto/CGI
/tmp/.cpan/build/CGI.pm-2.62/blib/man3
/usr/lib/perl5/5.00503/CGI.pm

Each one of these modules - util.pm, Carp.pm, Fast.pm, etc… - have a
corresponding partner in /usr/lib/perl5/5.00503/, and each module in the
/tmp directory is a more recent version than the ones in
/usr/lib/perl5/5.00503. So, just in the way of getting RT back up, could
I just move these newer modules into their respective places in
/usr/lib/perl5/5.00503/?

The modification dates of these files (including the 2.62 CGI.pm) go
only as late as March of this year. Hmm, I was thinking redhat’s update
script be the culprit, but if it were, and these were recent updates, I
would expect that the “newer” CGI.pm would be at the current version
(2.66, I believe), and the modification dates would read yesterday, not
march. My only other guess is that Arkeia (backup software that someone
else installed yesterday) uses perl, and might have done something while
it was checking for perl libraries? Guess I’m on my own there.


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

jesse reed vincent — root@eruditorum.orgjesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
’“As the company that brought users the Internet, Netscape is now inviting
the more than 60 million people who have used our client software to
’tune up’ and upgrade to Netscape Communicator,” said Mike Homer,
senior vice president of marketing at Netscape.’ Sometimes I wonder.


#8

Thanks, that did it. Are there man pages/docs for using cpan at the
command line?.. cpan’s faq’s just give you ftp url’s for their updates.


#9

'perldoc CPAN’On Tue, Aug 29, 2000 at 01:01:59PM -0400, Neil Curri wrote:

Thanks, that did it. Are there man pages/docs for using cpan at the
command line?.. cpan’s faq’s just give you ftp url’s for their updates.

I think the “right” thing to do is just install a new version of CGI.pm
from cpan. it’s pretty easy. Just type the following and let perl do all the work…

perl -MCPAN -eshell
install CGI


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

jesse reed vincent — root@eruditorum.orgjesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven
years.


#10

Hi I m seeing something werid here some times
Some times a ticket gets made say with the user name bill@bill.com and then
we reply to that
form say support@abc.com

They get the reply and then they send back to rt and then they get an email
form rt with there reply in it and it was addressed form them
Its rather werid
any ideas ?