Upgrade confusion

john norris

(207●3●40●44) retagged

Mar 14 '13, 4:34 p.m.

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

0 votes

Comments

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Mar 08 '13, 5:45 a.m.

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.

john norris

Mar 08 '13, 6:57 a.m.

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

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Mar 08 '13, 7:09 a.m.

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.

john norris

Mar 08 '13, 8:33 a.m.

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.

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Mar 08 '13, 11:07 a.m.

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.

1 answer

8,984 views

0 votes

One answer

Permanent link

Bo Chulindra

JAZZ DEVELOPER (1.3k●2●7●18) Mar 08 '13, 11:16 a.m.

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:

Copy the Derby databases from the old installation directory

Go to the directory where you just installed the version 4.0.1 applications and delete the Derby repositoryDB directory. Alternatively, you can open a command prompt and enter the following commands to clear the default version 4.0.1 Derby repositoryDB directory:

del /s /f 4.0.1_install_dir\server\conf\jts\derby\repositoryDB

Go to the directory where you previously installed the CLM applications, copy the Derby database, and paste it in the equivalent directory for version 4.0.1. You can also open a command prompt and enter the following commands to copy the Derby database.

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.

xcopy /s old_install_dir\server\conf\jts\derby\repositoryDB 4.0.1_install_dir\server\conf\jts\derby\repositoryDB
xcopy /s old_install_dir\server\conf\jts\derby\warehouseDB 4.0.1_install_dir\server\conf\jts\derby\warehouseDB

			
			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.

1 vote

Comments

john norris

Mar 08 '13, 12:35 p.m.

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

john norris

Mar 08 '13, 1:05 p.m.

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.

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Mar 08 '13, 1:56 p.m.

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.

Bo Chulindra

JAZZ DEVELOPER Mar 08 '13, 2:09 p.m.

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. Sorry I didn't mention that you would have to re-run upgrade after moving your database to the correct location as Ralph pointed out. The first time you ran upgrade, it upgraded the wrong database, so simply moving over the old database which was not upgraded isn't enough. > Finally do you know what the upgrade scripts do do if they are not moving data around? The upgrade scripts also make modifications to the RTC configuration files that are not in the database and the Tomcat configuration files.

showing 5 of 7 show 2 more comments

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.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers

Answers and Comments

Question details

rational-team-concert

× 43,075

troubleshooting

× 6,081

administration

× 4,755

upgrade

× 268

Question asked: Mar 08 '13, 4:30 a.m.

Question was seen: 8,984 times

Last updated: Mar 14 '13, 4:34 p.m.

Upgrade confusion

Comments

1 answer

8,984 views

0 votes

One answer

Copy the Derby databases from the old installation directory

Comments

Your answer

Follow this question

Question details

Related questions