I’m trying to get RT 3.4.0 going on a Fedora Core 2 box, using the
latest stable release of MySQL (4.1.9). I’m getting an authentication
error when I try to do the database initialization. I found this
reference in the list archive
(The rt-users May 2003 Archive by thread
014025.html) but the answer of “Don’t use MySQL 4.1.x” doesn’t seem to
apply anymore – the docs indicate anything in 4.1.x should be fine.
Someone else seems to have had the same problem more recently
(The rt-users August 2004 Archive by thread
025558.html) but I don’t see a response to that thread.
If the root mysql user has a password, the connect immediately after
the first connect attempt, like so:
usr/bin/perl //usr/local/rt3/sbin/rt-setup-database --action init --dba
root --prompt-for-dba-password
In order to create or update your RT database,this script needs to
connect to your mysql instance on localhost as root.
Please specify that user’s database password below. If the user has no
database
password, just press return.
Password:
DBI connect(‘;host=localhost’,‘root’,…) failed: Client does not
support authentication protocol requested by server; consider upgrading
MySQL client at //usr/local/rt3/sbin/rt-setup-database line 101Failed
to connect to dbi:mysql:;host=localhost as root: Client does not
support authentication protocol requested by server; consider upgrading
MySQL client at //usr/local/rt3/sbin/rt-setup-database line 101,
line 1.make: *** [initialize-database] Error 255
If the mysql root user has no password (and I just type enter at the
password prompt) it goes a bit further, but still dies:
Password:
Now creating a database for RT.
Creating mysql database rt3.
Now populating database schema.
Creating database schema.
Done setting up database schema.
Now inserting database ACLs
Done setting up database ACLs.
Now inserting RT core system objects
[Mon Feb 7 20:27:50 2005] [crit]: Connect Failed Client does not
support authentication protocol requested by server; consider upgrading
MySQL client
at //usr/local/rt3/sbin/rt-setup-database line 384
(/usr/local/rt3/lib/RT.pm:285)
make: *** [initialize-database] Error 255
Does this look familiar to anyone? Is there something I can do to
further troubleshoot this, or are the docs wrong about 4.1.x working?
Thanks,
Matt
PGP.sig (186 Bytes)
This is a FAQ and has been discussed on the list many times in the past
two months. In short, your mysql client and server libs are out of sync.On Mon, Feb 07, 2005 at 03:40:09PM -0500, Matt Pounsett wrote:
I’m trying to get RT 3.4.0 going on a Fedora Core 2 box, using the
latest stable release of MySQL (4.1.9). I’m getting an authentication
error when I try to do the database initialization. I found this
reference in the list archive
(The rt-users May 2003 Archive by thread
014025.html) but the answer of “Don’t use MySQL 4.1.x” doesn’t seem to
apply anymore – the docs indicate anything in 4.1.x should be fine.
Someone else seems to have had the same problem more recently
(The rt-users August 2004 Archive by thread
025558.html) but I don’t see a response to that thread.
If the root mysql user has a password, the connect immediately after
the first connect attempt, like so:
usr/bin/perl //usr/local/rt3/sbin/rt-setup-database --action init --dba
root --prompt-for-dba-password
In order to create or update your RT database,this script needs to
connect to your mysql instance on localhost as root.
Please specify that user’s database password below. If the user has no
database
password, just press return.
Password:
DBI connect(‘;host=localhost’,‘root’,…) failed: Client does not
support authentication protocol requested by server; consider upgrading
MySQL client at //usr/local/rt3/sbin/rt-setup-database line 101Failed
to connect to dbi:mysql:;host=localhost as root: Client does not
support authentication protocol requested by server; consider upgrading
MySQL client at //usr/local/rt3/sbin/rt-setup-database line 101,
line 1.make: *** [initialize-database] Error 255
If the mysql root user has no password (and I just type enter at the
password prompt) it goes a bit further, but still dies:
Password:
Now creating a database for RT.
Creating mysql database rt3.
Now populating database schema.
Creating database schema.
Done setting up database schema.
Now inserting database ACLs
Done setting up database ACLs.
Now inserting RT core system objects
[Mon Feb 7 20:27:50 2005] [crit]: Connect Failed Client does not
support authentication protocol requested by server; consider upgrading
MySQL client
at //usr/local/rt3/sbin/rt-setup-database line 384
(/usr/local/rt3/lib/RT.pm:285)
make: *** [initialize-database] Error 255
Does this look familiar to anyone? Is there something I can do to
further troubleshoot this, or are the docs wrong about 4.1.x working?
Thanks,
Matt
The rt-users Archives
RT Administrator and Developer training is coming to your town soon! (Boston, San Francisco, Austin, Sydney) Contact training@bestpractical.com for details.
Be sure to check out the RT Wiki at http://wiki.bestpractical.com
This is a FAQ and has been discussed on the list many times in the past
two months. In short, your mysql client and server libs are out of
sync.
Hrm… okay, sorry to bring it up again… a search of the list archives
didn’t come up with anything other than the two items I mentioned.
I don’t see how my libs could be out of sync, however. I followed the
FC2 instructions at
Request Tracker Wiki to the
letter.
% rpm -qa | grep -i mysql
MySQL-shared-compat-4.1.9-0
MySQL-server-4.1.9-0
perl-DBD-MySQL-2.9003-4
MySQL-client-4.1.9-0
There certainly haven’t been any non-RPM installations of MySQL on this
machine, so I don’t see how there could be libs left laying around.
Just in case, I just removed and re-installed the 4.1.9 RPMs from
MySQL, and saw no change.
Anyone have any other thoughts?
PGP.sig (186 Bytes)
This is a FAQ and has been discussed on the list many times in the
past
two months. In short, your mysql client and server libs are out of
sync.
Hrm… okay, sorry to bring it up again… a search of the list archives
didn’t come up with anything other than the two items I mentioned.
And sorry to follow up to my own posting… but just double-checked,
and this isn’t an FAQ… at least, it’s not on the FAQ list at
http://wiki.bestpractical.com/index.cgi?FAQ
If there’s another FAQ somewhere that covers this, I’d be pleased to
know its location.
Thanks
Matt
PGP.sig (186 Bytes)
This is a FAQ and has been discussed on the list many times in the past
two months. In short, your mysql client and server libs are out of
sync.
Okay… I see where the problem is. The mysql client and server libs
are in sync… it’s DBD::Mysql itself that has the problem. The
confusion stems from the FC2 install doc, step 4, which says to remove
the existing MySQL 3.x RPMs using --nodeps. Since the MySQL client RPM
and the DBD::MySQL RPM are co-dependant, I incorrectly assumed the
document author would be aware that perl-DBD-MySQL would be installed,
and that it was intentionally left off the list of RPMs to remove…
that it was possibly intended to work with the MySQL 4.x libraries…
an assumption that seemed supported by the use of the MySQL 4.x compat
libraries. The FC2 doc should probably be updated to include
perl-DBD-MySQL in the list of RPMs to be removed.
It unfortunately looks like DBD::MySQL won’t compile against those
three specific MySQL RPMs, due to a missing mysql_config. That’s a
separate issue to be worked out, however. I’ll dig up the correct
selection of RPMs and then follow up here.
Thanks for the info,
Matt
PGP.sig (186 Bytes)
It unfortunately looks like DBD::MySQL won’t compile against those
three specific MySQL RPMs, due to a missing mysql_config.
You’/re likely looking for a mysql-dev or mysql-devel RPM.
Jesse
Matt,
The wiki docs have always been a problem. Since they are community
written, many of the docs were written with older versions in mind and
they have not been tagged as to which version they were working with.
I had many many problems due to issues similar to what you
experienced. The gist was right but the specifics were out of date.
It would be great if you could update the install doc or put a comment
in with your solutions and include what versions you were working
with. No one else will do this.
Done. In addition to clarifying the issue with DBD::MySQL, I inserted
a note about other (possible) missing dependancies, just in case the
user’s install selection for the OS doesn’t match that of the original
author. That should help prevent people from assuming the doc is
exhaustive.
I’m just doing a test install now, for evaluation at the office… but
if/when we do a full production install I’ll come back and update the
doc from start to finish. Mind you, I may be using FC3 by then… but
that doc looks like it’s needed anyway.
Cheers,
Matt
PGP.sig (186 Bytes)
There was a patch from Matthew Meyer for 3.2.2 to implement corrections
for custom field changes in bulk updates. In 3.4.0 the Custom Field
behavior was massive changed and bulk updates on custom fields are now
completly removed. Have somebody re-implementet this funktionality for
for 3.4.0? Or can we hope to have this “must-have” feature back in a
released version?
Thanks,
_Stefan
I want to add to Stefan’s remark that this is really a must-have feature
for us too! Can you please add this feature to 3.4.x as well?
Thanks,
Vasanth-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Stefan
Fischer
Sent: Tuesday, February 08, 2005 4:56 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] RT 3.4.0 CustomField changes on Bulk update
There was a patch from Matthew Meyer for 3.2.2 to implement corrections
for custom field changes in bulk updates. In 3.4.0 the Custom Field
behavior was massive changed and bulk updates on custom fields are now
completly removed. Have somebody re-implementet this funktionality for
for 3.4.0? Or can we hope to have this “must-have” feature back in a
released version?
Thanks,
_Stefan
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
RT Administrator and Developer training is coming to your town soon!
(Boston, San Francisco, Austin, Sydney) Contact
training@bestpractical.com for details.
Be sure to check out the RT Wiki at http://wiki.bestpractical.com