Unknown opened 2 years ago
|
|
Which MySQL version do you use? First of all I would suggest doing staged upgrade - first upgrade do version 8.0.x and then to the 8.2.x. Collation problem most likely stems from differences in Tigase connection and database default collation. Please make sure that those match. The problematic StoredProcedure operates on
|
|
Thank for the feedback, we are using Mysql 5.7.41 Do you think is possible to understand exactly which query is failing? I have seen that the
and in
I didn't find in the public repos with SQL file, what is I will try as suggested to fix the default collation and I will also try to make upgrade before to 8.0.0 and to 8.2.x (without anyway running 8.0.0) as suggested and check if there is any error. Regarding this:
for what I have understood from the doc I have to add inside
this block:
as described here. For sure I need the I have also seen that |
|
The offending call is this one: If you have not enabled unified-archive, there shouldn't be any calls to it. Regarding The encoders/decoders - if you add decoders, your users will be able to login using data covered by the existing decoder (i.e. MD5 passwrods). Encoders are responsible for storing passwords, so if you create a new user or existing user updates password it will be encoded in the database using all enabled encoders. So the transition/migration can be gradual. You can also force migration to new mechanism by forcing everyone on your system to update passwords. |
|
ok, it seems all clear, so there is no need to add credentialEncoders, regarding how can we replicate the same behaviour with the 8.2.2 ? |
|
You would have to create your own decoder based on |
|
ok, so we need to re-build the code?
Cannot we just use:
'user-login-query' = '{ call TigUserLoginPlainPw(?, ?) }'
with a modified version of the "new version" of |
|
Not exactly. You can create a dedicated maven project, add If you want to use your solution ( |
|
well for the name we could just create a new one with a custom name so it cannot be re-deleted during upgrades
ok, we can create the maven project, but I did not understood how it will be linked the implementation, I guess we have to create a new string for our mechanism implementation like "CUSTOM" and add in the configuration:
correct? |
|
Your implementation will basically look like You will have to change Encoder and Decoder bean names, value returned by Please be aware, that we do plan on deprecating MD5* based implementations, and we would suggest switching to |
|
I more than happy to remove the MD5* implementations but there is no other solution for the users already created. We have developer our implementation and will enable only the decoder so user can connect but new users/change of password will create only SCRAM-*. I need some time to test it and I will let you know if all works correctly, thank you |
|
You can have decoders for both YourDecoder and SCRAM, so new users would use SCRAM and old users would use YourDecoder. But you can prompt users to update their passwords, that would trigger encoding them to SCRAM (i.e. migrating to new decoder). Alternatively you can run both of them and over the time, when the users update the passwords, all userbase would be migrated to SCRAM eventually. |
|
Hi,
I have been able to upgrade the vesion changing the collation to
it seems all correct, right? I have notice that some table withour 'tig_' prefix are still there:
is it correct that they are not deleted during the migration? Can I delete them? I have also noticed that the table |
|
Hmm... it's because we support upgrading only from 3 "big" versions back, thus you could upgrade to 8.2.* from 7.2.x (7.2 -> 8.0 -> 8.1). If you want to upgrade from 7.1.x you have to upgrade to 8.1.x first and then you can upgrade to either 8.2.x or even 8.3.x. |
|
I have to call with:
there is no reference to that code |
|
@davidemarrone yes, my bad. Please see my previous commend regarding version upgrade compatibility. |
|
ok thanks, tomorrow I will try to update to 8.1.x and I will let you know |
|
It worked:
but still are remainig this tables (now empty)
but the migration seems good, regading:
this should not happen with production env because there is valid licence there, for this copy I have deleted the licence before running the upgrade. Do you think anyway that can cause problem? |
|
actually there is a big problem, the migration seems that worked but there is a "bug" somewhere. I cannot authenticate to the new instance and I see that in tig_user_credentials all the rows has the same value for"
I will try to upgrade first to 8.0.0 and then to 8.2.2 |
|
As for the authentication issue, it is explained in the logs from the upgrade stage. Inside them there are following lines:
According to the documentation for version 8.0.0, you need to change your configuration, see https://docs.tigase.net/en/latest/Tigase_Administration/Database_Management/Management.html#schema-updates (especially As for duplicated values in |
|
ok thanks, I saw the same values and I (wrongly) assumed that there was the bug there. I have added in the config
I will make another test with 8.0.0 if something is different |
|
Ok, it works also the migration directly to 8.1.2. Thank you, the only strange thing noted on the startup is:
but anyway the login is working correctly |
|
We have created our code:
what should be the correct configuration only:
or we have to use?
Considering that all the entries in the db of |
|
Considering that you relayed on lowercase matching and also that existing |
|
ok, we will use our AUTH in the future making more test, at the moment I have to migrate from 7.1 to 8.1.2 that is compatible for the DB migration. I have put in the config
ad described in the doc and I can successfully login old user created with 7.1 But if I create a new user or if I modify the password of an existing user I cannot login anymore with that user, in table the DB tig_user_credentials after the creation of modification I only found for that user 3 rows with SCRAM-SHA-1 SCRAM-SHA-256 SCRAM-SHA-512 and there is no row with MD5-USERNAME-PASSWORD. What I'm doing wrong? Is the row with MD5-USERNAME-PASSWORD needed since I'm using 'user-login-query' ? |
|
I have noticed in the logs:
isn't the configuration correct? |
|
in the 8.1.2 it was with ths S! |
|
If I understood correctly, since I'm using
and finally it worked !
I will see in the future how to handle the migration to scram but at least I will be already on the 8.1.2 with all the password only in the form of |
|
this should be documentated, it would be nice that command |
|
The check is already there. The problem is that in versions older than 8 we handled upgrade differently, and we didn't store current schema version in the database thus it wasn't possible to reliably detect if you upgrade from 7.1 or from 4.0. |
Hi, I'm trying to upgrade tigase from
7.1.5-b4512
to8.2.2-b11697
this is the output of
./scripts/tigase.sh upgrade-schema etc/tigase.conf
how can I fix it? regards