I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then
continued to 4 per the instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly
everyones account gets locked.
I restarted the services, I checked my configs, I’m coming up empty.
What went wrong or where should I be looking?
Thanks.
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. http://www.gsicommerce.com
E-Mail: knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.
I just tracked this down to the password changing in the database…
If I try to log in after upgrading - it works for awhile then stops
working. The question is why?
The workaround:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘knarrj’;
This isn’t good. I would vastly prefer to not have to run the upgrade
again and I would really like to use the old passwords. Is there a
workaround? What changed?On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then
continued to 4 per the instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly
everyones account gets locked.
I restarted the services, I checked my configs, I’m coming up empty.
What went wrong or where should I be looking?
Thanks.
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. http://www.gsicommerce.com
E-Mail: knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.
I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then continued to 4 per the
instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly everyones account gets
locked.
What does “everyones account gets locked” mean?
What is in your debug logs.
What extensions do you have installed.
-kevin
Kevin,
No-one can log in (including root). I eventually figured out I could
reset a password with:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘knarrj’;
This resets the password of the user. I changed my loglevel to debug and
restarted httpd and sure enough I’m locked out again.
log snippit:
[Mon Jun 6 14:54:10 2011] [debug]: RT’s GnuPG libraries couldn’t
successfully read your configured GnuPG home directory
(/opt/rt4/var/data/gpg). PGP support has been disabled
(/opt/rt4/sbin/…/lib/RT/Config.pm:521)
[Mon Jun 6 14:54:29 2011] [error]: FAILED LOGIN for knarrj from
172.25.30.147 (/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:639)
[Mon Jun 6 14:54:36 2011] [error]: FAILED LOGIN for knarrj from
172.25.30.147 (/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:639)
[Mon Jun 6 14:54:50 2011] [error]: FAILED LOGIN for knarrj from
172.25.30.147 (/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:639)
Extensions - we’re very boring here and have no extensions installed.
Thanks,
JoshOn Mon, 2011-06-06 at 10:45 -0400, Kevin Falcone wrote:
On Mon, Jun 06, 2011 at 09:29:03AM -0400, Joshua Knarr wrote:
I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then continued to 4 per the
instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly everyones account gets
locked.
What does “everyones account gets locked” mean?
What is in your debug logs.
What extensions do you have installed.
-kevin
I restarted the services, I checked my configs, I’m coming up empty. What went wrong or where
should I be looking?
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. http://www.gsicommerce.com
E-Mail: knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.
I just tracked this down to the password changing in the database…
If I try to log in after upgrading - it works for awhile then stops working. The question is
why?
The workaround:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘knarrj’;
This isn’t good. I would vastly prefer to not have to run the upgrade again and I would really
like to use the old passwords. Is there a workaround? What changed?
What changed was
http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html
It is also documented in docs/UPGRADING-3.8
It sounds like you have an extension somewhere that clobbers the new
password checking routine. It also sounds like you missed some parts
of the upgrade.
-kevin> On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then continued to 4 per the
instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly everyones account
gets locked.
I restarted the services, I checked my configs, I'm coming up empty. What went wrong or
where should I be looking?
Kevin,
We seriously do not have any extensions, either on the old host or the
new host. We would like to be able to use LDAP at some point but it
isn’t looking good for keeping confluence overall.
I wiped the new box and I wiped the database host and redid the entire
process from the get go - we’re still experiencing the same problem.
It looks like RT is having problems matching the SHA hashes, but I’m
really not sure what’s going on. I know in users.pm we convert the
password the first time the user logs in from MD5 to SHA, but then it
seems to fail all the new SHA matches. WTF?On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
I just tracked this down to the password changing in the database…
If I try to log in after upgrading - it works for awhile then stops working. The question is
why?
The workaround:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘knarrj’;
This isn’t good. I would vastly prefer to not have to run the upgrade again and I would really
like to use the old passwords. Is there a workaround? What changed?
What changed was
[Rt-announce] Security vulnerability in RT 3.0 and up
It is also documented in docs/UPGRADING-3.8
It sounds like you have an extension somewhere that clobbers the new
password checking routine. It also sounds like you missed some parts
of the upgrade.
-kevin
On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then continued to 4 per the
instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly everyones account
gets locked.
I restarted the services, I checked my configs, I'm coming up empty. What went wrong or
where should I be looking?
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. http://www.gsicommerce.com
E-Mail: knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.
We seriously do not have any extensions, either on the old host or the new host. We would like
to be able to use LDAP at some point but it isn’t looking good for keeping confluence overall.
I wiped the new box and I wiped the database host and redid the entire process from the get go
- we’re still experiencing the same problem.
It looks like RT is having problems matching the SHA hashes, but I’m really not sure what’s
going on. I know in users.pm we convert the password the first time the user logs in from MD5
to SHA, but then it seems to fail all the new SHA matches. WTF?
You should be running the vulnerable-passwords script as documented in
the UPGRADING-3.8 documentation which means passwords will already be
in the new SHA format.
Did you do all the upgrade steps?
Please run ‘SHOW CREATE TABLE Users’
-kevin> On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
I just tracked this down to the password changing in the database…
If I try to log in after upgrading - it works for awhile then stops working. The question is
why?
The workaround:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘knarrj’;
This isn’t good. I would vastly prefer to not have to run the upgrade again and I would really
like to use the old passwords. Is there a workaround? What changed?
What changed was
[1][Rt-announce] Security vulnerability in RT 3.0 and up
It is also documented in docs/UPGRADING-3.8
It sounds like you have an extension somewhere that clobbers the new
password checking routine. It also sounds like you missed some parts
of the upgrade.
-kevin
On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then continued to 4 per the
instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly everyones account
gets locked.
I restarted the services, I checked my configs, I'm coming up empty. What went wrong or
where should I be looking?
–
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. [2]http://www.gsicommerce.com
E-Mail: [3]knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is intended only for the use of
the individual or entity named in this transmission. If you are not the intended recipient of
this transmission, you are hereby notified that any disclosure, copying or distribution of the
contents of this transmission is strictly prohibited and that you should delete the contents
of this transmission from your system immediately. Any comments or statements contained in
this transmission do not necessarily reflect the views or position of GSI Commerce, Inc. or
its subsidiaries and/or affiliates.
References
Visible links
- [Rt-announce] Security vulnerability in RT 3.0 and up
- http://www.gsicommerce.com/
- mailto:hellerk@gsicommerce.com
Attached.On Tue, 2011-06-07 at 11:52 -0400, Kevin Falcone wrote:
On Tue, Jun 07, 2011 at 09:23:42AM -0400, Joshua Knarr wrote:
We seriously do not have any extensions, either on the old host or the new host. We would like
to be able to use LDAP at some point but it isn’t looking good for keeping confluence overall.
I wiped the new box and I wiped the database host and redid the entire process from the get go
- we’re still experiencing the same problem.
It looks like RT is having problems matching the SHA hashes, but I’m really not sure what’s
going on. I know in users.pm we convert the password the first time the user logs in from MD5
to SHA, but then it seems to fail all the new SHA matches. WTF?
You should be running the vulnerable-passwords script as documented in
the UPGRADING-3.8 documentation which means passwords will already be
in the new SHA format.
Did you do all the upgrade steps?
Please run ‘SHOW CREATE TABLE Users’
-kevin
On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
I just tracked this down to the password changing in the database…
If I try to log in after upgrading - it works for awhile then stops working. The question is
why?
The workaround:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘knarrj’;
This isn’t good. I would vastly prefer to not have to run the upgrade again and I would really
like to use the old passwords. Is there a workaround? What changed?
What changed was
[1][Rt-announce] Security vulnerability in RT 3.0 and up
It is also documented in docs/UPGRADING-3.8
It sounds like you have an extension somewhere that clobbers the new
password checking routine. It also sounds like you missed some parts
of the upgrade.
-kevin
On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then continued to 4 per the
instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly everyones account
gets locked.
I restarted the services, I checked my configs, I'm coming up empty. What went wrong or
where should I be looking?
–
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. [2]http://www.gsicommerce.com
E-Mail: [3]knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is intended only for the use of
the individual or entity named in this transmission. If you are not the intended recipient of
this transmission, you are hereby notified that any disclosure, copying or distribution of the
contents of this transmission is strictly prohibited and that you should delete the contents
of this transmission from your system immediately. Any comments or statements contained in
this transmission do not necessarily reflect the views or position of GSI Commerce, Inc. or
its subsidiaries and/or affiliates.
References
Visible links
- [Rt-announce] Security vulnerability in RT 3.0 and up
- http://www.gsicommerce.com/
- mailto:hellerk@gsicommerce.com
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. http://www.gsicommerce.com
E-Mail: knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.
output.txt (1.71 KB)
Attached.
You don’t appear to have run the database upgrades.
Which upgrade steps have you done? Please show exactly what you ran
and the outputs. You should be sure to review all relevant
docs/UPGRADING-*
Password varbinary(40) default NULL,
That is not the right size for the passwords, which is why your users
get locked out after the upgrade. Please note that merely fixing the
size is unlikely to fix other problems caused by skipping upgrades.
-kevin> On Tue, 2011-06-07 at 11:52 -0400, Kevin Falcone wrote:
On Tue, Jun 07, 2011 at 09:23:42AM -0400, Joshua Knarr wrote:
We seriously do not have any extensions, either on the old host or the new host. We would like
to be able to use LDAP at some point but it isn’t looking good for keeping confluence overall.
I wiped the new box and I wiped the database host and redid the entire process from the get go
- we’re still experiencing the same problem.
It looks like RT is having problems matching the SHA hashes, but I’m really not sure what’s
going on. I know in users.pm we convert the password the first time the user logs in from MD5
to SHA, but then it seems to fail all the new SHA matches. WTF?
You should be running the vulnerable-passwords script as documented in
the UPGRADING-3.8 documentation which means passwords will already be
in the new SHA format.
Did you do all the upgrade steps?
Please run ‘SHOW CREATE TABLE Users’
-kevin
On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
I just tracked this down to the password changing in the database…
If I try to log in after upgrading - it works for awhile then stops working. The question is
why?
The workaround:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘knarrj’;
This isn’t good. I would vastly prefer to not have to run the upgrade again and I would really
like to use the old passwords. Is there a workaround? What changed?
What changed was
[1][Rt-announce] Security vulnerability in RT 3.0 and up
It is also documented in docs/UPGRADING-3.8
It sounds like you have an extension somewhere that clobbers the new
password checking routine. It also sounds like you missed some parts
of the upgrade.
-kevin
On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then continued to 4 per the
instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly everyones account
gets locked.
I restarted the services, I checked my configs, I'm coming up empty. What went wrong or
where should I be looking?
–
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. [2]http://www.gsicommerce.com
E-Mail: [3]knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is intended only for the use of
the individual or entity named in this transmission. If you are not the intended recipient of
this transmission, you are hereby notified that any disclosure, copying or distribution of the
contents of this transmission is strictly prohibited and that you should delete the contents
of this transmission from your system immediately. Any comments or statements contained in
this transmission do not necessarily reflect the views or position of GSI Commerce, Inc. or
its subsidiaries and/or affiliates.
References
Visible links
- [Rt-announce] Security vulnerability in RT 3.0 and up
- http://www.gsicommerce.com/
- mailto:hellerk@gsicommerce.com
–
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. http://www.gsicommerce.com
E-Mail: knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.
99% sure I did it.
Since I have a trashed staging DB here I ran the command again and it
had no effect.
We’re going from 3.4.5, reading the upgrading docs sequentially doesn’t
mention anything about this schema change nor how to effect it. Looking
in the script you pointed me to, this doesn’t actually change the
schema.
Running the upgrade-mysql-schema.pl produces the following:
ALTER TABLE Users
DEFAULT CHARACTER SET utf8;
However there’s nothing here that actually changes the password from
varchar(40) to whatever value it needs to be.On Tue, 2011-06-07 at 16:04 -0400, Kevin Falcone wrote:
On Tue, Jun 07, 2011 at 03:48:19PM -0400, Joshua Knarr wrote:
Attached.
You don’t appear to have run the database upgrades.
Which upgrade steps have you done? Please show exactly what you ran
and the outputs. You should be sure to review all relevant
docs/UPGRADING-*
Password varbinary(40) default NULL,
That is not the right size for the passwords, which is why your users
get locked out after the upgrade. Please note that merely fixing the
size is unlikely to fix other problems caused by skipping upgrades.
-kevin
On Tue, 2011-06-07 at 11:52 -0400, Kevin Falcone wrote:
On Tue, Jun 07, 2011 at 09:23:42AM -0400, Joshua Knarr wrote:
We seriously do not have any extensions, either on the old host or the new host. We would like
to be able to use LDAP at some point but it isn’t looking good for keeping confluence overall.
I wiped the new box and I wiped the database host and redid the entire process from the get go
- we’re still experiencing the same problem.
It looks like RT is having problems matching the SHA hashes, but I’m really not sure what’s
going on. I know in users.pm we convert the password the first time the user logs in from MD5
to SHA, but then it seems to fail all the new SHA matches. WTF?
You should be running the vulnerable-passwords script as documented in
the UPGRADING-3.8 documentation which means passwords will already be
in the new SHA format.
Did you do all the upgrade steps?
Please run ‘SHOW CREATE TABLE Users’
-kevin
On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
I just tracked this down to the password changing in the database…
If I try to log in after upgrading - it works for awhile then stops working. The question is
why?
The workaround:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘knarrj’;
This isn’t good. I would vastly prefer to not have to run the upgrade again and I would really
like to use the old passwords. Is there a workaround? What changed?
What changed was
[1][Rt-announce] Security vulnerability in RT 3.0 and up
It is also documented in docs/UPGRADING-3.8
It sounds like you have an extension somewhere that clobbers the new
password checking routine. It also sounds like you missed some parts
of the upgrade.
-kevin
On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then continued to 4 per the
instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly everyones account
gets locked.
I restarted the services, I checked my configs, I'm coming up empty. What went wrong or
where should I be looking?
–
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. [2]http://www.gsicommerce.com
E-Mail: [3]knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is intended only for the use of
the individual or entity named in this transmission. If you are not the intended recipient of
this transmission, you are hereby notified that any disclosure, copying or distribution of the
contents of this transmission is strictly prohibited and that you should delete the contents
of this transmission from your system immediately. Any comments or statements contained in
this transmission do not necessarily reflect the views or position of GSI Commerce, Inc. or
its subsidiaries and/or affiliates.
References
Visible links
- [Rt-announce] Security vulnerability in RT 3.0 and up
- http://www.gsicommerce.com/
- mailto:hellerk@gsicommerce.com
–
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. http://www.gsicommerce.com
E-Mail: knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. http://www.gsicommerce.com
E-Mail: knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.
99% sure I did it.
Since I have a trashed staging DB here I ran the command again and it had no effect.
We’re going from 3.4.5, reading the upgrading docs sequentially doesn’t mention anything about
this schema change nor how to effect it. Looking in the script you pointed me to, this doesn’t
actually change the schema.
Running the upgrade-mysql-schema.pl produces the following:
ALTER TABLE Users
DEFAULT CHARACTER SET utf8;
However there’s nothing here that actually changes the password from varchar(40) to whatever
value it needs to be.
There are multiple upgrade steps, UPGRADING.mysql is not the only thing
you need to do. There are at least 2 other etc/upgrade scripts to run
besides upgrade-mysql-schema.pl and it doesn’t appear that you’ve run any
of the rt-setup-database steps as mentioned in the README 6b.
If you’ve actually skipped all of the database upgrades between 3.4.5
and 4.0.0 you’re missing a lot of changes.
-kevin> On Tue, 2011-06-07 at 16:04 -0400, Kevin Falcone wrote:
On Tue, Jun 07, 2011 at 03:48:19PM -0400, Joshua Knarr wrote:
Attached.
You don’t appear to have run the database upgrades.
Which upgrade steps have you done? Please show exactly what you ran
and the outputs. You should be sure to review all relevant
docs/UPGRADING-*
Password varbinary(40) default NULL,
That is not the right size for the passwords, which is why your users
get locked out after the upgrade. Please note that merely fixing the
size is unlikely to fix other problems caused by skipping upgrades.
-kevin
On Tue, 2011-06-07 at 11:52 -0400, Kevin Falcone wrote:
On Tue, Jun 07, 2011 at 09:23:42AM -0400, Joshua Knarr wrote:
We seriously do not have any extensions, either on the old host or the new host. We would like
to be able to use LDAP at some point but it isn’t looking good for keeping confluence overall.
I wiped the new box and I wiped the database host and redid the entire process from the get go
- we’re still experiencing the same problem.
It looks like RT is having problems matching the SHA hashes, but I’m really not sure what’s
going on. I know in users.pm we convert the password the first time the user logs in from MD5
to SHA, but then it seems to fail all the new SHA matches. WTF?
You should be running the vulnerable-passwords script as documented in
the UPGRADING-3.8 documentation which means passwords will already be
in the new SHA format.
Did you do all the upgrade steps?
Please run ‘SHOW CREATE TABLE Users’
-kevin
On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
I just tracked this down to the password changing in the database…
If I try to log in after upgrading - it works for awhile then stops working. The question is
why?
The workaround:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘knarrj’;
This isn’t good. I would vastly prefer to not have to run the upgrade again and I would really
like to use the old passwords. Is there a workaround? What changed?
What changed was
[1][1][Rt-announce] Security vulnerability in RT 3.0 and up
It is also documented in docs/UPGRADING-3.8
It sounds like you have an extension somewhere that clobbers the new
password checking routine. It also sounds like you missed some parts
of the upgrade.
-kevin
On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
I am upgrading from RT 3.4.5 to RT 4.
I read the docs and stopped at 3.8, did the schema stuff, and then continued to 4 per the
instructions for upgrading mysql also.
On the new system it runs for a few hours just fine, but then suddenly everyones account
gets locked.
I restarted the services, I checked my configs, I'm coming up empty. What went wrong or
where should I be looking?
–
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. [2][2]http://www.gsicommerce.com
E-Mail: [3][3]knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is intended only for the use of
the individual or entity named in this transmission. If you are not the intended recipient of
this transmission, you are hereby notified that any disclosure, copying or distribution of the
contents of this transmission is strictly prohibited and that you should delete the contents
of this transmission from your system immediately. Any comments or statements contained in
this transmission do not necessarily reflect the views or position of GSI Commerce, Inc. or
its subsidiaries and/or affiliates.
References
Visible links
- [4][Rt-announce] Security vulnerability in RT 3.0 and up
- [5]http://www.gsicommerce.com/
- [6]mailto:hellerk@gsicommerce.com
–
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. [7]http://www.gsicommerce.com
E-Mail: [8]knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.
–
Joshua Knarr
Systems Engineer
GSI Commerce, Inc. [9]http://www.gsicommerce.com
E-Mail: [10]knarrj@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371
The information contained in this electronic mail transmission is intended only for the use of
the individual or entity named in this transmission. If you are not the intended recipient of
this transmission, you are hereby notified that any disclosure, copying or distribution of the
contents of this transmission is strictly prohibited and that you should delete the contents
of this transmission from your system immediately. Any comments or statements contained in
this transmission do not necessarily reflect the views or position of GSI Commerce, Inc. or
its subsidiaries and/or affiliates.
References
Visible links
- [Rt-announce] Security vulnerability in RT 3.0 and up
- http://www.gsicommerce.com/
- mailto:knarrj@gsicommerce.com
- [Rt-announce] Security vulnerability in RT 3.0 and up
- http://www.gsicommerce.com/
- mailto:hellerk@gsicommerce.com
- http://www.gsicommerce.com/
- mailto:knarrj@gsicommerce.com
- http://www.gsicommerce.com/
- mailto:hellerk@gsicommerce.com