After upgrading my RT server (4.2.1) from Fedora 19 / Perl 5.16 to
Fedora 20 / Perl 5.18, Apache is no longer willing to start RT. It
complains about attempting to require packages twice. And this message
appears in the Apache log: “Error while loading /opt/rt4/sbin/rt-server:
Perl API version v5.16.0 of OPpSORT_REVERSE does not match v5.18.0 at
/usr/lib64/perl5/DynaLoader.pm line 213.”
Is there a straight-forward solution or must I try to downgrade perl?
Dave Close
Is there a straight-forward solution or must I try to downgrade perl?
Everything must agree.
a) downgrade perl (and everything else tied to that)
b) recompile RT and so forth to all use the new Perl 5.18
After upgrading my RT server (4.2.1) from Fedora 19 / Perl 5.16 to
Fedora 20 / Perl 5.18, Apache is no longer willing to start RT. It
complains about attempting to require packages twice. And this message
appears in the Apache log: “Error while loading /opt/rt4/sbin/rt-server:
Perl API version v5.16.0 of OPpSORT_REVERSE does not match v5.18.0 at
/usr/lib64/perl5/DynaLoader.pm line 213.”Is there a straight-forward solution or must I try to downgrade perl?
This sounds like you’re running mod_perl compiled against the old perl
(5.16) while trying to load the new system perl which runs 5.18.
You need a newer mod_perl package.
If you’re not running mod_perl, you should specify how you’re running
RT and include the whole error message, not just snippets.
-kevin
I wrote:
After upgrading my RT server (4.2.1) from Fedora 19 / Perl 5.16 to
Fedora 20 / Perl 5.18, Apache is no longer willing to start RT. It
complains about attempting to require packages twice. And this message
appears in the Apache log: “Error while loading /opt/rt4/sbin/rt-server:
Perl API version v5.16.0 of OPpSORT_REVERSE does not match v5.18.0 at
/usr/lib64/perl5/DynaLoader.pm line 213.”
Kevin Falcone answered:
This sounds like you’re running mod_perl compiled against the old perl
(5.16) while trying to load the new system perl which runs 5.18.You need a newer mod_perl package.
If you’re not running mod_perl, you should specify how you’re running
RT and include the whole error message, not just snippets.
Good thought but both perl and mod_perl were upgraded at the same time
and both are version 5.18. It appears to be RT which is compiled against
the wrong version.
Jeremy Mates wrote:
b) recompile RT and so forth to all use the new Perl 5.18
Fine. I’m trying to do that. Doesn’t seem like it should need more than
going to my unpackage directory and running “make install”. However,
when I try that, I get,
CORE missing dependencies:
Data::GUID …MISSING
Perl API version v5.16.0 of v does not match v5.18.0 at
/usr/lib64/perl5/DynaLoader.pm line 213.
But the perl-Data-GUID package is /not/ missing.
-rw-r–r-- 1 root root 8799 2013-12-13 05:23
/usr/share/perl5/vendor_perl/Data/GUID.pm
I suspect I’m missing a step /before/ “make install”. Clues?
Dave Close, Thales Avionics, Irvine California USA.
cell +1 949 394 2124, dave.close@us.thalesgroup.com
Good thought but both perl and mod_perl were upgraded at the same time
and both are version 5.18. It appears to be RT which is compiled against
the wrong version.
RT is not a compiled application. It runs under the perl that you
tell Apache to use.
The most common type of error is the wrong version of mdo_perl
Fine. I’m trying to do that. Doesn’t seem like it should need more than
going to my unpackage directory and running “make install”. However,
when I try that, I get,CORE missing dependencies:
Data::GUID …MISSING
Perl API version v5.16.0 of v does not match v5.18.0 at
/usr/lib64/perl5/DynaLoader.pm line 213.But the perl-Data-GUID package is /not/ missing.
ls -l /usr/share/perl5/vendor_perl/Data/GUID.pm
-rw-r–r-- 1 root root 8799 2013-12-13 05:23
/usr/share/perl5/vendor_perl/Data/GUID.pmI suspect I’m missing a step /before/ “make install”. Clues?
Those are two different paths.
Ensure that when you’re in the upgrade directory you have perl-5.18 in
your path before perl-5.16 before running configure.
You appear to have a few perls and differing 32bit vs 64bit problems.
-kevin
Kevin Falcone wrote:
RT is not a compiled application. It runs under the perl that you
tell Apache to use.
Indeed. But my phrase was taken directly from Jeremy Mates’s suggestion.
The most common type of error is the wrong version of mdo_perl
Both perl and mod_perl come from Fedora packages and both are the same
version. If that were my problem, everyone using F20 and perl would be
complaining.
CORE missing dependencies:
Data::GUID …MISSING
Perl API version v5.16.0 of v does not match v5.18.0 at
/usr/lib64/perl5/DynaLoader.pm line 213.But the perl-Data-GUID package is /not/ missing.
ls -l /usr/share/perl5/vendor_perl/Data/GUID.pm
-rw-r–r-- 1 root root 8799 2013-12-13 05:23
/usr/share/perl5/vendor_perl/Data/GUID.pm
Those are two different paths.
Of course, they are. One is the program which detected the error, the
other is the file about which it is complaining. But what the heck is “v”?
Ensure that when you’re in the upgrade directory you have perl-5.18 in
your path before perl-5.16 before running configure.You appear to have a few perls and differing 32bit vs 64bit problems.
I have only one perl installed and no relevant 32-bit packages. Why do
you think otherwise?
Dave Close, Thales Avionics, Irvine California USA.
cell +1 949 394 2124, dave.close@us.thalesgroup.com
The most common type of error is the wrong version of mdo_perl
Both perl and mod_perl come from Fedora packages and both are the same
version. If that were my problem, everyone using F20 and perl would be
complaining.
Since you failed to indicate your deployment method in your original
email, you forced us to guess and grasp at straws.
CORE missing dependencies:
Data::GUID …MISSING
Perl API version v5.16.0 of v does not match v5.18.0 at
/usr/lib64/perl5/DynaLoader.pm line 213.But the perl-Data-GUID package is /not/ missing.
ls -l /usr/share/perl5/vendor_perl/Data/GUID.pm
-rw-r–r-- 1 root root 8799 2013-12-13 05:23
/usr/share/perl5/vendor_perl/Data/GUID.pmThose are two different paths.
Of course, they are. One is the program which detected the error, the
other is the file about which it is complaining. But what the heck is “v”?
Which one is a program, they both look like perl modules to me
/usr/lib64/perl5/DynaLoader.pm
/usr/share/perl5/vendor_perl/Data/GUID.pm
Ensure that when you’re in the upgrade directory you have perl-5.18 in
your path before perl-5.16 before running configure.You appear to have a few perls and differing 32bit vs 64bit problems.
I have only one perl installed and no relevant 32-bit packages. Why do
you think otherwise?
Because one is installed in /usr/share/perl5 the standard RH perl
library path for site_lib. The other is installed in a specific lib64
path and is clearly a leftover from a 5.16 install (or is detecting
in your @INC something left over from 5.16).
When you upgraded this box and perl was upgraded, did the RPM clean
out the old site installed modules because of binary incompatibility?
I’ll repeat my advice:
Ensure that when you’re in the upgrade directory you have perl-5.18 in
your path before perl-5.16 before running configure.
If it’s still failing after you re run configure with perl-5.18 in
your path, please show a full error, Then show us perl -V.
A full error includes attempting to install Data::GUID, not merely
RT telling you that it isn’t installed.
-kevin
Kevin Falcone wrote:
Since you failed to indicate your deployment method in your original
email, you forced us to guess and grasp at straws.
But I wrote, “After upgrading my RT server (4.2.1) from Fedora 19 / Perl
5.16 to Fedora 20 / Perl 5.18…”. In the Fedora world, an upgrade is a
specific YUM operation. Sorry if that wasn’t clear.
CORE missing dependencies:
Data::GUID …MISSING
Perl API version v5.16.0 of v does not match v5.18.0 at
/usr/lib64/perl5/DynaLoader.pm line 213.But the perl-Data-GUID package is /not/ missing.
ls -l /usr/share/perl5/vendor_perl/Data/GUID.pm
-rw-r–r-- 1 root root 8799 2013-12-13 05:23
/usr/share/perl5/vendor_perl/Data/GUID.pmThose are two different paths.
Of course, they are. One is the program which detected the error, the
other is the file about which it is complaining. But what the heck is “v”?Which one is a program, they both look like perl modules to me
/usr/lib64/perl5/DynaLoader.pm
/usr/share/perl5/vendor_perl/Data/GUID.pm
Interpreted programs are still programs. The problem was detected at
line 213 in DynaLoader.pm.
Ensure that when you’re in the upgrade directory you have perl-5.18 in
your path before perl-5.16 before running configure.You appear to have a few perls and differing 32bit vs 64bit problems.
I have only one perl installed and no relevant 32-bit packages. Why do
you think otherwise?Because one is installed in /usr/share/perl5 the standard RH perl
library path for site_lib. The other is installed in a specific lib64
path and is clearly a leftover from a 5.16 install (or is detecting
in your @INC something left over from 5.16).
“Clearly” not.
/usr/share/doc/perl-Data-GUID
/usr/share/doc/perl-Data-GUID/Changes
/usr/share/doc/perl-Data-GUID/LICENSE
/usr/share/doc/perl-Data-GUID/README
/usr/share/man/man3/Data::GUID.3pm.gz
/usr/share/perl5/vendor_perl/Data
/usr/share/perl5/vendor_perl/Data/GUID.pm
The file is where the RPM package wants to put it.
When you upgraded this box and perl was upgraded, did the RPM clean
out the old site installed modules because of binary incompatibility?I’ll repeat my advice:
Ensure that when you’re in the upgrade directory you have perl-5.18 in
your path before perl-5.16 before running configure.If it’s still failing after you re run configure with perl-5.18 in
your path, please show a full error, Then show us perl -V.
A full error includes attempting to install Data::GUID, not merely
RT telling you that it isn’t installed.
/bin/perl
Summary of my perl5 (revision 5 version 18 subversion 2) configuration:
Platform:
osname=linux, osvers=3.11.9-200.fc19.x86_64,
archname=x86_64-linux-thread-multi
uname=‘linux buildvm-12.phx2.fedoraproject.org
3.11.9-200.fc19.x86_64 #1 smp wed nov 20 21:22:24 utc 2013 x86_64 x86_64
x86_64 gnulinux ’
config_args=’-des -Doptimize=-O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
–param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
-Dccdlflags=-Wl,–enable-new-dtags -Dlddlflags=-shared -O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
–param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
-Wl,-z,relro -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.18.2
-Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red
Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local
-Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5
-Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl
-Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl
-Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64
/usr/lib64 -Duseshrplib -Dusethreads -Duseithreads
-Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db
-Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
-Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly
-Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto
-Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto
-Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin
-Dusesitecustomize’
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc=‘gcc’, ccflags =‘-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing
-pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64’,
optimize=‘-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic’,
cppflags=‘-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include’
ccversion=‘’, gccversion=‘4.8.2 20131212 (Red Hat 4.8.2-7)’,
gccosandvers=‘’
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype=‘long’, ivsize=8, nvtype=‘double’, nvsize=8, Off_t=‘off_t’,
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld=‘gcc’, ldflags =’ -fstack-protector’
libpth=/usr/local/lib64 /lib64 /usr/lib64
libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread
-lc -lgdbm_compat
perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version=‘2.18’
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef,
ccdlflags=‘-Wl,–enable-new-dtags’
cccdlflags=‘-fPIC’, lddlflags='-shared -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
–param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
-Wl,-z,relro ’
Characteristics of this binary (from libperl):
Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
PERL_PRESERVE_IVUV PERL_SAWAMPERSAND USE_64_BIT_ALL
USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
USE_REENTRANT_API USE_SITECUSTOMIZE
Locally applied patches:
Fedora Patch1: Removes date check, Fedora/RHEL specific
Fedora Patch3: support for libdir64
Fedora Patch4: use libresolv instead of libbind
Fedora Patch5: USE_MM_LD_RUN_PATH
Fedora Patch6: Skip hostname tests, due to builders not being
network capable
Fedora Patch7: Dont run one io test due to random builder failures
Fedora Patch9: Fix find2perl to translate ? glob properly
(RT#113054)
Fedora Patch10: Update h2ph(1) documentation (RT#117647)
Fedora Patch11: Update pod2html(1) documentation (RT#117623)
Fedora Patch12: Disable ornaments on perl5db AutoTrace tests
(RT#118817)
Fedora Patch14: Do not use system Term::ReadLine::Gnu in tests
(RT#118821)
Fedora Patch15: Define SONAME for libperl.so
Fedora Patch16: Install libperl.so to -Dshrpdir value
Fedora Patch18: Fix crash with &$glob_copy (RT#119051)
Fedora Patch19: Fix coreamp.t rand test (RT#118237)
Fedora Patch20: Reap child in case where exception has been
thrown (RT#114722)
Fedora Patch21: Fix using regular expressions containing
multiple code blocks (RT#117917)
Fedora Patch200: Link XS modules to libperl.so with
EU::CBuilder on Linux
Fedora Patch201: Link XS modules to libperl.so with EU::MM on Linux
Built under linux
Compiled at Jan 7 2014 14:47:21
%ENV:
PERL5LIB=“/root/perl5/lib/perl5:”
PERL_LOCAL_LIB_ROOT=“/root/perl5:”
PERL_MB_OPT=“–install_base /root/perl5”
PERL_MM_OPT=“INSTALL_BASE=/root/perl5”
@INC:
/root/perl5/lib/perl5/x86_64-linux-thread-multi
/root/perl5/lib/perl5
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5
.
Package perl-Data-GUID-0.048-1.fc20.noarch already installed and latest
version
Nothing to do
checking for a BSD-compatible install… /bin/install -c
checking for perl… /bin/perl
checking for chosen layout… relative
checking if user www exists… not found
checking if user www-data exists… not found
checking if user apache exists… found
checking if group www exists… not found
checking if group www-data exists… not found
checking if group apache exists… found
checking if group rt3 exists… not found
checking if group rt exists… found
checking if database name is set… yes
checking if database name is valid… yes
checking for gcc… gcc
checking whether the C compiler works… yes
checking for C compiler default output file name… a.out
checking for suffix of executables…
checking whether we are cross compiling… no
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… none needed
checking for aginitlib in -lgraph… no
checking for gdlib-config… no
checking for gpg… yes
checking for openssl… yes
configure: creating ./config.status
config.status: creating etc/upgrade/3.8-ical-extension
config.status: creating etc/upgrade/split-out-cf-categories
config.status: creating etc/upgrade/generate-rtaddressregexp
config.status: creating etc/upgrade/upgrade-articles
config.status: creating etc/upgrade/vulnerable-passwords
config.status: creating etc/upgrade/switch-templates-to
config.status: creating sbin/rt-attributes-viewer
config.status: creating sbin/rt-preferences-viewer
config.status: creating sbin/rt-session-viewer
config.status: creating sbin/rt-dump-metadata
config.status: creating sbin/rt-setup-database
config.status: creating sbin/rt-test-dependencies
config.status: creating sbin/rt-email-digest
config.status: creating sbin/rt-email-dashboards
config.status: creating sbin/rt-clean-sessions
config.status: creating sbin/rt-shredder
config.status: creating sbin/rt-validator
config.status: creating sbin/rt-validate-aliases
config.status: creating sbin/rt-email-group-admin
config.status: creating sbin/rt-server
config.status: creating sbin/rt-server.fcgi
config.status: creating sbin/standalone_httpd
config.status: creating sbin/rt-setup-fulltext-index
config.status: creating sbin/rt-fulltext-indexer
config.status: creating sbin/rt-serializer
config.status: creating sbin/rt-importer
config.status: creating bin/rt-crontool
config.status: creating bin/rt-mailgate
config.status: creating bin/rt
config.status: creating Makefile
config.status: creating etc/RT_Config.pm
config.status: creating lib/RT/Generated.pm
config.status: creating t/data/configs/apache2.2+mod_perl.conf
config.status: creating t/data/configs/apache2.2+fastcgi.conf
/bin/perl ./sbin/rt-test-dependencies --verbose --with-mysql --with-fastcgi
perl:
>=5.10.1(5.18.2) …found
users:
rt group (rt) …found
bin owner (root) …found
libs owner (root) …found
libs group (bin) …found
web owner (apache) …found
web group (apache) …found
CLI dependencies:
HTTP::Request::Common …found
Getopt::Long >= 2.24 …found
LWP …found
Text::ParseWords …found
Term::ReadKey …found
Term::ReadLine …found
CORE dependencies:
CGI >= 3.38 …found
UNIVERSAL::require …found
Log::Dispatch >= 2.30 …found
Mail::Mailer >= 1.57 …found
XML::RSS >= 1.05 …found
CGI::Cookie >= 1.20 …found
Regexp::Common::net::CIDR …found
Role::Basic >= 0.12 …found
LWP::Simple …found
Scalar::Util …found
Plack::Handler::Starlet …found
HTML::Mason::PSGIHandler >= 0.52 …found
HTML::Entities …found
Errno …found
File::ShareDir …found
Digest::SHA …found
Mail::Header >= 2.12 …found
Text::Wrapper …found
HTML::Scrubber >= 0.08 …found
Symbol::Global::Name >= 0.04 …found
CGI::Emulate::PSGI …found
Text::Template >= 1.44 …found
Regexp::IPv6 …found
Time::ParseDate …found
Tree::Simple >= 1.04 …found
Text::Quoted >= 2.07 …found
Time::HiRes …found
Email::Address::List …found
Class::Accessor >= 0.34 …found
HTML::Quoted …found
Encode >= 2.39 …found
File::Spec >= 0.8 …found
Digest::MD5 >= 2.27 …found
Digest::base …found
DBIx::SearchBuilder >= 1.65 …found
HTML::FormatText::WithLinks::AndTables …found
Locale::Maketext::Lexicon >= 0.32 …found
File::Temp >= 0.19 …found
Date::Manip …found
HTTP::Message >= 6.0 …found
HTML::RewriteAttributes >= 0.05 …found
Apache::Session >= 1.53 …found
Storable >= 2.08 …found
Plack >= 1.0002 …found
Net::CIDR …found
HTML::FormatText::WithLinks >= 0.14 …found
Text::Password::Pronounceable …found
DateTime::Format::Natural >= 0.67 …found
CGI::PSGI >= 0.12 …found
Data::GUID …MISSING
Perl API version v5.16.0 of v does not match v5.18.0 at
/usr/lib64/perl5/DynaLoader.pm line 213.
JSON …found
Locale::Maketext >= 1.06 …found
DateTime::Locale >= 0.40 …found
Crypt::Eksblowfish …found
IPC::Run3 …found
Text::WikiFormat >= 0.76 …found
HTML::Mason >= 1.43 …found
MIME::Entity >= 5.504 …found
Module::Versions::Report >= 1.05 …found
DBI >= 1.37 …found
DateTime >= 0.44 …found
Regexp::Common …found
CSS::Squish >= 0.06 …found
Sys::Syslog >= 0.16 …found
List::MoreUtils …found
Devel::GlobalDestruction …found
Module::Refresh >= 0.03 …found
Devel::StackTrace >= 1.19 …found
Locale::Maketext::Fuzzy >= 0.11 …found
File::Glob …found
Email::Address >= 1.897 …found
DASHBOARDS dependencies:
MIME::Types …found
URI::QueryParam …found
URI >= 1.59 …found
FASTCGI dependencies:
FCGI >= 0.74 …found
FCGI::ProcManager …found
GD dependencies:
GD::Text …found
GD …found
GD::Graph >= 1.47 …found
GPG dependencies:
PerlIO::eol …found
File::Which …found
GnuPG::Interface …found
GRAPHVIZ dependencies:
IPC::Run >= 0.90 …found
GraphViz …found
ICAL dependencies:
Data::ICal …found
MAILGATE dependencies:
Mozilla::CA …found
LWP::Protocol::https …found
Crypt::SSLeay …found
LWP::UserAgent >= 6.0 …found
Getopt::Long …found
Net::SSL …found
Pod::Usage …found
MYSQL dependencies:
DBD::mysql >= 2.1018 …found
SMIME dependencies:
Crypt::X509 …found
String::ShellQuote …found
File::Which …found
USERLOGO dependencies:
Convert::Color …found
SOME DEPENDENCIES WERE MISSING.
CORE missing dependencies:
Data::GUID …MISSING
Perl API version v5.16.0 of v does not match v5.18.0 at
/usr/lib64/perl5/DynaLoader.pm line 213.
Perl library path for /bin/perl:
/root/perl5/lib/perl5/x86_64-linux-thread-multi
/root/perl5/lib/perl5
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5
.
make: *** [testdeps] Error 1
Dave Close, Thales Avionics, Irvine California USA.
cell +1 949 394 2124, dave.close@us.thalesgroup.com
But I wrote, “After upgrading my RT server (4.2.1) from Fedora 19 / Perl
5.16 to Fedora 20 / Perl 5.18…”. In the Fedora world, an upgrade is a
specific YUM operation. Sorry if that wasn’t clear.
Either the upgrade left 5.16 bits behind (packages buggy somehow), or a
manual install was improperly made to the vendor space and has left 5.16
bits behind (rpm would be ignorant of these). The 5.16 bits will need to be
located and removed, probably by looking for *.so, *.bs, *.xs or similar
binary files under the various @INC dirs. /bin/perl is very strange; typical
is /usr/bin/perl; I’d probably KickStart and reinstall a host in such a
state back to a clean slate.
I otherwise avoid this sort of problem by not mixing manual installs with
the system perl and vendor space; either RT and everything is built as a
full RPM, or RT goes into /some/not/vendor/dir along with a
/some/not/vendor/dir perl (and then FastCGI or the like to avoid the mess
that is mod_perl).
Jeremy Mates wrote:
Either the upgrade left 5.16 bits behind (packages buggy somehow), or a
manual install was improperly made to the vendor space and has left 5.16
bits behind (rpm would be ignorant of these). The 5.16 bits will need to be
located and removed, probably by looking for *.so, *.bs, *.xs or similar
binary files under the various @INC dirs.
I’m looking for any such.
/bin/perl is very strange; typical
is /usr/bin/perl; I’d probably KickStart and reinstall a host in such a
state back to a clean slate.
The last several Fedora releases have eliminated the distinction between
/bin and /usr/bin (and between /sbin and /usr/sbin).
lrwxrwxrwx. 1 root root 7 2014-02-13 21:22 /bin → usr/bin
lrwxrwxrwx. 1 root root 8 2014-02-13 21:22 /sbin → usr/sbin
Dave Close, Thales Avionics, Irvine California USA.
cell +1 949 394 2124, dave.close@us.thalesgroup.com
Jeremy Mates wrote:
Either the upgrade left 5.16 bits behind (packages buggy somehow),
or a manual install was improperly made to the vendor space and has
left 5.16 bits behind (rpm would be ignorant of these). The 5.16 bits
will need to be located and removed, probably by looking for *.so,
*.bs, *.xs or similar binary files under the various @INC dirs.
I examined every .pm and .so file in all of the @INC directory trees and
removed any file which was not owned by a current RPM package. After
that, “make install” stopped complaining about a missing UUID but did
complain that the installed version of Locale::Maketext::Fuzzy was not
sufficiently recent. So I had to install that one module via CPAN. Then
“make install” did it’s job without complaint.
So now I have what should be a working RT. But no… Apache says,
[14455] [Wed Feb 19 01:11:15 2014] [error]: Not a HASH reference at
/opt/rt4/sbin/…/lib/RT/Principal.pm line 385.
Stack:
[/opt/rt4/sbin/…/lib/RT/Principal.pm:385]
[/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:660]
[/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:368]
[/opt/rt4/share/html/autohandler:53]
(/opt/rt4/sbin/…/lib/RT/Interface/Web/Handler.pm:211)
The RT log is empty.
Dave Close, Thales Avionics, Irvine California USA.
cell +1 949 394 2124, dave.close@us.thalesgroup.com
Jeremy Mates wrote:
Either the upgrade left 5.16 bits behind (packages buggy somehow),
or a manual install was improperly made to the vendor space and has
left 5.16 bits behind (rpm would be ignorant of these). The 5.16 bits
will need to be located and removed, probably by looking for *.so,
*.bs, *.xs or similar binary files under the various @INC dirs.
Is there a chance you have i686 packages also installed that may have not been caught by the upgrade?
Cheers,
Paul
The information contained in this email and any attachments may be confidential. This email and any attachments are also subject to copyright. No part of them may be reproduced, adapted or transmitted without the written permission of the copyright owner. If you are not the intended recipient, any use, interference with, disclosure or copying of this information is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the message from your system. All email communications to and from NEXTDC Limited are recorded for the purposes of archival and storage.
I wrote:
So now I have what should be a working RT. But no… Apache says,
[14455] [Wed Feb 19 01:11:15 2014] [error]: Not a HASH reference at
/opt/rt4/sbin/…/lib/RT/Principal.pm line 385.Stack:
[/opt/rt4/sbin/…/lib/RT/Principal.pm:385]
[/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:660]
[/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:368]
[/opt/rt4/share/html/autohandler:53]
(/opt/rt4/sbin/…/lib/RT/Interface/Web/Handler.pm:211)The RT log is empty.
This problem was cleared by deleting the browser’s RT cookie.
Dave Close
Now that I have RT running enough to get a login page, I can’t get /any/
login to work, not even root. The Apache log reports, “Unknown password
form (/usr/share/perl5/vendor_perl/RT/User_Overlay.pm:1094)”, and the RT
log is still empty.
Users and passwords are stored in MySQL (actually MariaDB). Checking
that from the command line shows that all the data is still there.
There must be a backdoor way in. Isn’t there?
For those who haven’t been following this saga, this is with RT 4.2.1 on
Fedora 20 with Perl 5.18.
Dave Close
Dave,
Now that I have RT running enough to get a login page, I can’t get /any/
login to work, not even root. The Apache log reports, “Unknown password
form (/usr/share/perl5/vendor_perl/RT/User_Overlay.pm:1094)”, and the RT
log is still empty.
you can look at this page:
http://requesttracker.wikia.com/wiki/RecoverRootPassword
it has steps for RT4 (be sure to use the RT4 way, not the 3.8 way, i believe the password encryption was changed in there somewhere).
There is also steps to check to see if the “root” account was disabled, and how to enable it if it was.
There must be a backdoor way in. Isn’t there?
yes, the above link will get you there. you can “un-disable” a user, if it was disabled, and reset the password to something you know.
from the first entry in the logs, it looks like the passwords are still stored in the “pre-change-to-md5” format (from back in 3.8 i believe). there was some code in there to allow people to use either, but if they changed their password, it would be stored in the new format. it could be that those users you are trying to login with had never changed their passwords since then? (it is mentioned at least here: UPGRADING-3.8 - RT 4.2.17 Documentation - Best Practical )
I hope this helps…
Thanks,
Jok
Now that I have RT running enough to get a login page, I can’t get /any/
login to work, not even root. The Apache log reports, “Unknown password
form (/usr/share/perl5/vendor_perl/RT/User_Overlay.pm:1094)”, and the RT
log is still empty.Users and passwords are stored in MySQL (actually MariaDB). Checking
that from the command line shows that all the data is still there.
RT 4.2.1 doesn’t have a User_Overlay.pm – we stopped shipping _Overlay
files in RT 4.0. Its existence is a sign of a local customization, or
an upgrade from RT 3.8 or earlier which missed the instructions at the
top of UPGRADING-4.0.
It’s also extremely odd that that file is not in /opt/rt4, and is in
vendor_perl. Did you install an RPM of RT 3.8 at some prior point?
Now that I have RT running enough to get a login page, I can’t get /any/
login to work, not even root. The Apache log reports, “Unknown password
form (/usr/share/perl5/vendor_perl/RT/User_Overlay.pm:1094)”, and the RT
log is still empty.Users and passwords are stored in MySQL (actually MariaDB). Checking
that from the command line shows that all the data is still there.RT 4.2.1 doesn’t have a User_Overlay.pm – we stopped shipping _Overlay
files in RT 4.0. Its existence is a sign of a local customization, or
an upgrade from RT 3.8 or earlier which missed the instructions at the
top of UPGRADING-4.0.It’s also extremely odd that that file is not in /opt/rt4, and is in
vendor_perl. Did you install an RPM of RT 3.8 at some prior point?
Yes, I’m sure I did, a long time ago. But I wasn’t using it, thought I
had removed it, and was running from a more conventional installation
process.
Jok Thuau wrote:
you can look at this page:
http://requesttracker.wikia.com/wiki/RecoverRootPassword
Anyway, Jok’s solution did not solve the problem. But it did give me
some more error messages to investigate. I discovered that the
vendor_perl/RT directory content was quite old. I replaced it entirely
with the files from the installation directory, restarted Apache, and
now things seem to work. There are also copies of those files in
/opt/rt4/lib/RT, but that is not in @INC for some reason.
Thanks for everyone for the help and patience.
Dave Close
Anyway, Jok’s solution did not solve the problem. But it did give me
some more error messages to investigate. I discovered that the
vendor_perl/RT directory content was quite old. I replaced it entirely
with the files from the installation directory, restarted Apache, and
now things seem to work. There are also copies of those files in
/opt/rt4/lib/RT, but that is not in @INC for some reason.
RT adds /opt/rt4/lib to its @INC path on startup; copying them into
vendor_perl is unnecessary. In fact, you are only leaving a landmine
for yourself in the future (as happened with the _Overlay files) by
having copied them into vendor_perl.