Upgrade confusion
john norris (207●3●40●44)
| asked Mar 08 '13, 4:30 a.m.
retagged Mar 14 '13, 4:34 p.m. by Bo Chulindra (1.3k●2●7●18) I have upgraded from 4.0 RC3 to 4.0.1. There were a few problems (see my previous question) but I can now log on via the browser to admin. But the upgrade has not given me what I would expect of the term "upgrade". The 4.0RC3 set up had several users. I can log on to 4.0.1 as those users (good) but it actually logs me in as "ADMIN" user rather than "jnorris". If I try with an incorrect user ("fred") then result is invalid username / password. Which is correct. And as "jnorris" when I go to active users, there are none. Yet if there are none, how can I log in. So I assumed upgrade meant that it was going to read the old db and put the data in the new db. And I guess it has because otherwise it should not let me log in. But neither should it log me in as one user and then make known as a different user. Does anyone know what is going on? Regards, John
|
One answer
This would happen if the container (Tomcat/WAS) is successfully authenticating you but your user does not exist in the JTS database.
Upgrade does not move data from your old database to your new one. If you look at the interactive upgrade guide, you'll see the following instructions:
If you did not copy the database over and your database location is relative, then your 4.0.1 server will use its prepackaged database which is empty. This would explain why you are being authenticated successfully but your user information is not found. Comments Hi Bo, I am happy to do that - it is what has happened during previous upgrades. But I could not find this in the notes I looked at. Even with the interactive upgrade guide. After I had entered my setup, the generated instructions were 4 steps the first three were prepare, the final being "now go to manual on how to upgrade". I do feel the docs on this have not been as straightforward as previous upgrades (1->2, 2->3). Finally do you know what the upgrade scripts do do if they are not moving data around? John Hi Bo, tried the copying (I am on Linux) and now the databases are corrupted and I just get lots of errors. I will delete 4.0.1. Other products really are not this difficult to upgrade for a simple fix pack. See clearcase and clearquest for how to do this. Hi John,
RTC is an enterprise product. It is supposed to support thousands of users. The required infrastructure adds complexity.
Derby is only meant to be used for playground test systems. This is noted on the download pages. If you had used a real DB you would not have had the issue.
The releases you mention are full releases, not fix packs. Upgrading requires changes to the database. You can not just copy the database that was not upgraded to the new upgraded version. You can however run the upgrade again with the database from your RC3. You would have to run the upgrade again, so that the DB gets upgraded.
Another issue is, you ran on a release candidate, a milestone build, not on a release build. There is only support to go from a milestone build to the next, or the full release. All these upgrades are side by side installs and upgrade.
Upgrade does not require the user to move from one database to another. This generally doesn't require anything special except the case when the server is using the prepackaged Derby which lives in the same location as the server. Since upgrade requires using a new server and generally removing the old, this means the prepackaged Derby should be moved to the new server's location. The alternative is to move the Derby db out of the server directory completely and change the database location to an absolute location. Then as you upgrade, you will not have to move the database.
On another note, I'm confused as to how you're not seeing the Derby move instructions in the interactive upgrade guide. Here's the guide for 4.0.1: http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m1/index.jsp. Hi Bo, this confuses me too. unfortunately the link sends me to the front page on the help guide. Can you paste the bread crumbs at the top of the page in. Then I can navigate to the page. Thanks, John This link will take you directly to the interactive upgrade guide:
showing 5 of 7
show 2 more comments
|
Note: The following commands work if you are using the Derby database that is provided with the packaged product. If you changed your Derby database location, update the path accordingly.
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
John, people need to understand the middleware to answer this kind of questions. If you would have upgraded successfully and succeeded in the deployment of the new binaries and connecting to LDAP if used. You should now work on a 4.0.1 version with all the old data and the users etc. If you don't, you either failed with the upgrade or you have an issue in the deployment.
Hi Ralph, thanks for the comment. I do not use LDAP, the users should be in the database as they were on the previous installed version. When I log into admin via the browser, the server says 4.0.1 so the install went well.
When I run the upgrade scripts no errors were shown. I have checked the upgrade logs - again no errors.
So, as you say, the upgrade either failed invisibly or the upgrade does not do what you say it does.
When I say the upgrade scripts, I mean the scripts under server/upgrade.
The licenses are there from the previous version. So some things have gone across. And the users are there - otherwise how would I have been able to log on as jnorris? But they are not listed in active users.
So, instead of just saying "you failed" perhaps you can explain just that one point.
John
John,
Only the user ID's are in the DB, repository roles and passwords are managed by the app server or LDAP.
If you use Tomcat then the users are in the database, as well as in the tomcat-users.xml. Tomcat actually manages the passwords there. If you use WAS with no LDAP the users would be maintained in the local realm.
So you should check that tomcat users was brought over into the new tomcat during upgrade. Another thought is browser caches and versions. I would suggest to delete the browser cache after/during the upgrade.
So looked at tomcat-users.xml - it has all of the users there. So that is why RTC is allowing me to log in I guess. But then RTC switches the user to ADMIN and has not kept any of the users in the database.
The only solution I can see at the moment is to delete 4.0.1 and reinstall, not do an upgrade and start from fresh with adding all of the users and projects and adding source. It is something I would rather avoid so if there is an explanation as to why users were not transfered from the old database to the new one during the upgrade then I would be interested.
John, I would assume you should be able to upgrade from 4.0.1 RC3 to 4.0.1. Your question shows you started with 4.0 RC3 (typo?). If not a typo, you would have to upgrade to 4.0 first and then to 4.0.1.
Sorry, I can't help, too few information. You could also check the application logs and the tomcat logs, if there is a hint to what is wrong.