My server is running Fedora 8 and was running RT 3.6.5 ok. Most files
were located in /usr/share/rt3. I have just upgraded to RT 3.8.7 and
changed the installation directory to /opt/rt3. All references in
/etc/httpd/conf*/* have been changed to refer to /opt/rt3 but the
/usr/share/rt3 directory is still present. RT is running on port 8080 to
avoid conflict with another application.
After the upgrade, RT refuses to run. The log shows this message:
[Fri Apr 16 15:04:34 2010] [error] [client 172.16.100.228] Can’t locate
object method “_Accessible” via package “SubscribeDashboard” (perhaps
you forgot to load “SubscribeDashboard”?) at
/usr/lib/perl5/vendor_perl/5.8.8/DBIx/SearchBuilder/Record.pm line
423.\nCompilation failed in require at /opt/rt3/bin/…/lib/RT.pm line 443.\n
Looking around online, I don’t find this specific message referenced
anywhere. However, similar messages with other methods are quoted. The
general idea seems to be that something isn’t up-to-date as expected. So
I’ve run “yum update” on the server and updated everything. I then used
cpan to update File::Temp since the repositories don’t seem to be
current for that module. After restarting the web server (Apache 2), RT
still fails in exactly the same way.
Obviously, I’m still missing something simple. Can anyone tell me what?
Dave Close
My server is running Fedora 8 and was running RT 3.6.5 ok. Most files
were located in /usr/share/rt3. I have just upgraded to RT 3.8.7 and
changed the installation directory to /opt/rt3. All references in
/etc/httpd/conf*/* have been changed to refer to /opt/rt3 but the
/usr/share/rt3 directory is still present. RT is running on port 8080 to
avoid conflict with another application.
After the upgrade, RT refuses to run. The log shows this message:
[Fri Apr 16 15:04:34 2010] [error] [client 172.16.100.228] Can’t locate
object method “_Accessible” via package “SubscribeDashboard” (perhaps
you forgot to load “SubscribeDashboard”?) at
/usr/lib/perl5/vendor_perl/5.8.8/DBIx/SearchBuilder/Record.pm line
423.\nCompilation failed in require at /opt/rt3/bin/…/lib/RT.pm line 443.\n
Looking around online, I don’t find this specific message referenced
anywhere. However, similar messages with other methods are quoted. The
general idea seems to be that something isn’t up-to-date as expected. So
I’ve run “yum update” on the server and updated everything. I then used
cpan to update File::Temp since the repositories don’t seem to be
current for that module. After restarting the web server (Apache 2), RT
still fails in exactly the same way.
Obviously, I’m still missing something simple. Can anyone tell me what?
Dave Close
Hi Dave,
I am not sure if this is going to help you, but I had the same problem
as you have now. I was trying to do a smooth upgrade from 3.6 to 3.8 and
my idea was to run two versions at once only on different ports.
For reasons that I cannot fathom, this was not possible - I could run
only one version at port 80, be it 3.6 or 3.8. After all it was not that
much of a problem for me, because our RT installation was kind of fresh
one, without many users…
I suggest that you try to set up environment for new version of RT on
different machine, read the docs about migrating DB, set it up and after
you have it running just move it to orginal server and replace the old
version.
Martin
Mgr. Martin Drasar drasar@ics.muni.cz
Network Security Department http://ics.muni.cz/
CSIRT-MU http://www.muni.cz/csirt
Institute of Computer Science, Masaryk University, Brno, Czech Republic
PGP Key ID: 0x944BC925
I am not sure if this is going to help you, but I had the same problem
as you have now. I was trying to do a smooth upgrade from 3.6 to 3.8 and
my idea was to run two versions at once only on different ports.
For reasons that I cannot fathom, this was not possible - I could run
only one version at port 80, be it 3.6 or 3.8. After all it was not that
much of a problem for me, because our RT installation was kind of fresh
one, without many users…
First you say you tried different ports and then the the same port.
Did you mean different names? I’ve successfully run 3.8.1 and 3.8.6
concurrently on different virtual hosts (without doing the db upgrades).
Cambridge Energy Alliance: Save money. Save the planet.
First you say you tried different ports and then the the same port.
Did you mean different names? I’ve successfully run 3.8.1 and 3.8.6
concurrently on different virtual hosts (without doing the db upgrades).
I have tried two virtual hosts, one on port 80 and one on port 8080.
The port 80 had version 3.6.x and port 8080 had version 3.8.x
Because this setup was not working I have changed the configuration of
host on port 80 to point to RT 3.8.x directory (thus leaving me with
only one version). Suddenly I was able to run 3.8.x.
I admit that I have not done any deep testing, because I was happy to
see 3.8.x working. I have transitioned my scrips and left 3.6.x far
behind me.
Also note that I have tried version 3.6.x and 3.8.x concurrently and you
have different 3.8.x version - there may be a difference.
Mgr. Martin Drasar drasar@ics.muni.cz
Network Security Department http://ics.muni.cz/
CSIRT-MU http://www.muni.cz/csirt
Institute of Computer Science, Masaryk University, Brno, Czech Republic
PGP Key ID: 0x944BC925
Thank you to Martin Drasar, Jerrad Pierce, and Ian Pellew for their
replies to my query. However, the problem remains unresolved and hasn’t
really been addressed here. Note that RT was working on exactly the same
port with exactly the same Apache configuration.
I had an opportunity to abort a corporate push for SharePoint, but
without the ability to get RT working again, I am doomed to fail.
A week ago, I wrote:
My server is running Fedora 8 and was running RT 3.6.5 ok. Most files
were located in /usr/share/rt3. I have just upgraded to RT 3.8.7 and
changed the installation directory to /opt/rt3. All references in
/etc/httpd/conf*/* have been changed to refer to /opt/rt3 but the
/usr/share/rt3 directory is still present. RT is running on port 8080
to avoid conflict with another application.
After the upgrade, RT refuses to run. The log shows this message:
[Fri Apr 16 15:04:34 2010] [error] [client 172.16.100.228] Can’t
locate object method “_Accessible” via package “SubscribeDashboard”
(perhaps you forgot to load “SubscribeDashboard”?) at
/usr/lib/perl5/vendor_perl/5.8.8/DBIx/SearchBuilder/Record.pm line
423.\nCompilation failed in require at /opt/rt3/bin/…/lib/RT.pm line
443.\n
Looking around online, I don’t find this specific message referenced
anywhere. However, similar messages with other methods are quoted. The
general idea seems to be that something isn’t up-to-date as expected.
So I’ve run “yum update” on the server and updated everything. I then
used cpan to update File::Temp since the repositories don’t seem to be
current for that module. After restarting the web server (Apache 2),
RT still fails in exactly the same way.
Obviously, I’m still missing something simple. Can anyone tell me
what?
Dave Close, Thales Avionics, Irvine California USA
Software integration and performance testing
cell +1 949 394 2124, dave.close@us.thalesgroup.com
I don’t send HTML email and I prefer not to receive it.
HTML email is ugly and a significant security exposure.
Thank you to Martin Drasar, Jerrad Pierce, and Ian Pellew for their
replies to my query. However, the problem remains unresolved and hasn’t
really been addressed here. Note that RT was working on exactly the same
port with exactly the same Apache configuration.
Yes, but you changed the installation directory.
I had an opportunity to abort a corporate push for SharePoint, but
without the ability to get RT working again, I am doomed to fail.
Could you start the installation all over and first remove any trace of
RT except the database?
Further could you post your configure options?
I have a feeling that there is a mix up of two installations. Scan /etc
for anything related to RT and also /usr/share/rt
Seems that you previously installed using an rpm so you could check that
rpm for where all those files ended up and see if anything is left after
de-install.
Seems that you previously installed using an rpm so you could check that
rpm for where all those files ended up and see if anything is left after
de-install.
You were right. I had forgotten that the previous RT was installed from
an RPM as it had been nearly two years. Once I removed the RPM, the
error message in the subject vanished. Of course, there were then some
Perl modules that could not be found, but a few symbolic links cured
that problem. Thanks for the suggestion.
Dave Close