Some problems after restoring database backup to another Jazz Server
Hi all:
I want to move the database to another Jazz Server, I have already restored the database backup which come from a Jazz Server Oracle Database to another Jazz Server, but I have a problem with the database setting in the database configuration of the jts/setup process, and someone told me I should run the " repotools-jts -resetRepoLockId " command and I did it, I seems that this problem resolved, after that , I re-run the jts/setup, but when I go to the "Finalize Application" step, when I click the "Finalize Application Setup" button,It says:
"Unable to save the consumer key and secret into the application's database. See details for more information.ID CRJAZ1850E"
The detail message is:
"HTTP Status 500 - A friend or application with the title "Jazz Team Server" is already configured. Please choose a new title. -------------------------------------------------------------------------------- type Status report message A friend or application with the title "Jazz Team Server" is already configured. Please choose a new title. description The server encountered an internal error (A friend or application with the title "Jazz Team Server" is already configured. Please choose a new title.) that prevented it from fulfilling this request. -------------------------------------------------------------------------------- Apache Tomcat/5.5.35"
hope someone can help me
Accepted answer
Hi,
- If you run without a proxy and you want to restore an application server on a different machine, you have to give the machine the host name of the original machine (or whatever matches the name used in the public URI). You have to make sure that the new machine is the only one reachable using this name. E.g. with the hosts file or DNS.
-
If you use backup and restore to move to the new machine and make it available under the old host name to keep the public URI you don't have to run setup. Especially you don't have to register any new application and you can not change the Public URI either. If you could, you failed to bring all required files over. Please carefully read https://jazz.net/library/article/795 .
-
Today moving a project area from one server to another is not supported. If you mean you wanted to install two servers on one machine, this is possible if there are no conflicts in used ports and host names/host name aliases.
Comments
Very clear. Thanks Ralph. And what about a situation in which I just don't want to move anything but just create a connection to the repository in a different way than what I used for the public URI (i.e. public uri https://aaa.bbb.ccc/jazz/ while the connection I use for working and versioning files is https//10.16.33.66:9443/jazz/ )?
Is it supported? The Repository Connection URI MUST be the same of the public URI or not?
8 other answers
If you are on 3.x or 4.x you can not do this and you risk the possibility of corrupting the original server if it is still up and running. Links are stored in the repository that are hardcoded and point to your old server. You don't run set up to do this. You must look at doing a server rename and you must isolate this new server from the old server so it can not access the old server. You must also bring over the teamserver.properties files and a few other files - the reason you are seeing the first error is because there is a friends.config in admin and rm that have storage keys in them to access the repository. You need to follow the documentation on doing a server rename to do what you are trying if you have 4.x - if you have 3.x it is not possible to move a repository to another server
Comments
Ah, I didn't realize @wuhaizi may have been trying to move the Jazz Team Server to another URL. Good catch.
The URI is the same as the old Jazz Team Server, although I can't finish the jts/setup, I can access the CCM project area, seems that everything is ok as the old server, But the RQM and RM project is unavailable, I can't see any RQM and RM project
The most confusing in this thread is that the question indicates that the DB is required to be moved to another server - which is supported, but the description looks as if the attempt really is to move the applivation server / Public URI, which is not.
It is not possible to move the application(s) to another server and change the public URI, composed from protocol, server name, port, context root. e.g. https://<servername>:portNo/ccm. See: https://jazz.net/library/article/749
This is supported after upgrading to CLM 2012 (4.x) in some selected use cases only. See https://jazz.net/library/article/818 and https://jazz.net/library/article/898
Comments
Oh, I think I should tell you the whole things I did, actually I think what I did is not very complicated, I have two server which both run the CLM 3.0.1.3, but for some reasons I have to move the project area from the old server to the new server, I thought of two ways, the first one was retore the old server DB backup to the new server, the other one was just export the WI and import them to the new server, but that was just for RTC, for RRC and RQM, I didnot know how to do,
Also I knew I would lost many information such as links and history of the WI if I use the second method, but for the first method it also have critical problem, which is that the URI cannot be modified, so if the two server have a different URI, that would be not possible to do the moving, but I remembered actually the both server didnot have a real URI, we are using their integral host name(include domain name) as URI during the jts/setup after both server installation, and the client have to add the "serverIP myhost.com" to their Hosts files if they want to access the server
what I did is:
1. restore the old jazz server db backup to new server
2. run the repotools-jts -resetRepoLockId
2. change the new server's hosts file makes the URI the same as the old server
3. run the jts/setup in new server, and re-configure the public URI
4. change every application's teamserver.properties
5. and that problem I mentioned above appear
the is the brief process, the sequence may be wrong I don't remember exactly
so you can see where is the problem, and I will try give you more detail
thanks so much!!
Hi Stefano,
to access the repo using another URI is frowned upon. Seriously, you should not do that. The reason is, you could end up creating artifact links with your unofficial URL which will stay in the repo. They might not work for other users.
We had customers asking for internal and external URI's and the answer is, don't try that.
to access the repo using another URI is frowned upon. Seriously, you should not do that. The reason is, you could end up creating artifact links with your unofficial URL which will stay in the repo. They might not work for other users.
We had customers asking for internal and external URI's and the answer is, don't try that.
We had really to bypass our public URI from the build engine (because the public URI points to a reverse proxy that has some other products for security checks and so on and the build workspace is 800MB, 8000 files....) so we tried to change the hosts file of the build server (so aaa.bbb.ccc points to the direct ip of the rtc server and not the reverse proxy) and we used IIS to map 443 port to the 9443 port of the Tomcat.
Everything seems to work (even the artifacts URL), builds are really up to 40% faster but we have a strange log error on the server
2012-09-28 12:20:15,728 [ TP-Processor8] ERROR .ibm.team.jfs.app.discovery.utils.RootServicesUtil - Error while fetching and parsing the root services document from "https://null:443/jazz/rootservices" with host "10.16.34.200:443"
java.net.UnknownHostException: null
I hope that fooling the public uri with hosts file and port mapping is not frowned upon too ...;-)
Comments
Just want to mention here your forum question (which I believe is similar):
https://jazz.net/forum/questions/88046/connection-url-different-from-public-uri-any-side-effects
Stefano,
as far as I am aware/have been told it is.
Sure, it might work since everybody does it, but you don't know if the artifact linking did not already infest your repository with all the wrong URI's. As long as these work, you might not even see anything real bad happening. As soon as you switch off the redirect you might be screwed. I can not tell. I can't even tell if "Server rename" which is actually rather URI change in 4.0 would be able to fix all the URL's in case they are really broken. Have you ever checked e.g. work item to work item links, with respect to the URL they have stored?
as far as I am aware/have been told it is.
Sure, it might work since everybody does it, but you don't know if the artifact linking did not already infest your repository with all the wrong URI's. As long as these work, you might not even see anything real bad happening. As soon as you switch off the redirect you might be screwed. I can not tell. I can't even tell if "Server rename" which is actually rather URI change in 4.0 would be able to fix all the URL's in case they are really broken. Have you ever checked e.g. work item to work item links, with respect to the URL they have stored?
Artifact linking seems ok. And we also make a lot of post processing like versioning back the output of the builds using plain java api (we're on 2.0.0.2 ifix 6), creating baselines, promoting baselines, adding messages to the work items and so on.
If I point to the Change Set created with the scripts + plain java api after the builds on build machines that uses that file hosts + IIS port mapping I see everything right. Even with "copy url" I see an URI created with the right name I used on the public URI property defined on jazz server. I don't really know a way to understand if there's some "infected" URL. All what I may do gives me the right "public URI related" artifact URL.
I mean, what is written in latest blog as https://jazz.net/blog/index.php/2012/09/10/keeping-my-jazz-server-happy-and-my-users-overjoyed/ referring to https://jazz.net/library/article/325 is the same technique, or not?
Comments
I can only tell you what I was told. We had customers that wanted to use different public URI's e.g. for internal users and external users. That did not work. I played around with it and , I think I recall, managed to get a URL stored that contained localhost instead of the public URI when I connected to the server (web UI) using localhost instead of the public URI.
The article https://jazz.net/library/article/325 refers to SCM caching, where the client works against a proxy, that caches and also forwards the request to the right public URI. My assumption is, the client use the correct URI but the message goes to the proxy instead, which forwards it to the right URI if necessary or provides the cached content (with the correct public URI).
Comments
Bo Chulindra
JAZZ DEVELOPER Sep 26 '12, 11:56 a.m.@wuhaizi: What application is the "Finalize Application" step for? You may be seeing the error message because the application you are attempting to finalize is configured with the original Jazz Team Server. Since you have now restored a database backup for the Jazz Team Server, the application may not recognize this new Jazz Team Server as being the same as the old. So it will stop you from trying to register a second Jazz Team Server with the same title.
A workaround for now may be to visit the application's Admin page and change the title of the registered Jazz Team Server to a different one. This may allow you to continue with setup.