Setting up IHS on top of single server CLM installation
Karen Steele (1.2k●4●139●148)
| asked Apr 16 '19, 3:17 p.m.
retagged May 06 '19, 2:36 p.m. by Ken Tessier (841●1●7) This also refers to the my question 262130 in this forum.
We have a single server installation of full CLM - it has a Public URI - and is an existing working installation. We have to move off this current server to a new one in a different domain. Initially we would like to be able to at least move it to the new server and add IHS using Liberty Profiles to provided a reverse proxy in front retaining the single server model - near long term is distributed, but we have to get single working first.
We have found at least 3 or 4 articles (and have been provided links to the same) on how to do this. We've followed this step by step but still have questions as the documentation merely stops at "test http://reverse proxy server" .. if we get the splash screen (presuming this means the notation that the service is running) - which we do that its a done deal.
If we call out the application using the IHS server name, the application loads at the project areas space, but we cannot get to a project dashboard as it returns an error as its referencing the public URI we have (so its not resolving). If we navigate away to say RQM or DoorsNG then it attempts to find the application using its public URI - which it cannot resolve to either, unless we're going to the https://reverse proxy server:port/rqm/web for example
There seems to be pieces missing on what to do once you've confirmed that the IHS is actually running (or as best we can tell running) given the other errors above.
We're on a timeline to get this moved due to some site restrictions and looking for help - we do not have access to Websphere so it has to be liberty plugins using IHS.
All assistance greatly appreciated.
|
3 answers
Ralph Schoon (63.5k●3●36●46)
| answered Apr 17 '19, 10:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Apr 17 '19, 10:29 a.m. To understand how to setup using IHS, I would suggest to look into the interactive install or upgrade guides. They usually contain the information needed.
The Deployment Wiki can provide additional information. Especially see https://jazz.net/wiki/bin/view/Deployment/StandardTopologyPatternsOverview . Note the hostmanes and URI's of the servers. Also see: https://jazz.net/wiki/bin/view/Deployment/UnderstandingReverseProxy
In general the key here is, that the IHS hosts the Public URI. E.g. Assume Public URI root https://clm.example.com:9443/ so public URIs https://clm.example.com:9443/ccm , https://clm.example.com:9443/jts .
Assume two servers server one is https://clm.example.com/ IHS configured as https://clm.example.com:9443/ . This is the IHS server that hosts the public URI. Note the port and host name must be from the public URI root.
Server two is https://somehost.nowhere.com/. The CLM is setup to be accessible at say https://somehost.nowhere.com:8443/ccm and https://somehost.nowhere.com:8443/jts . Different ports and different host names. However it knows itself as https://clm.example.com:9443/ccm https://clm.example.com:9443/jts, that is the Public URI that is set.
IHS maps
This step is the Plugin stuff in IHS.
If you don't get the redirection right, you can reach IHS, but no application.
E.g. CCM on https://somehost.nowhere.com:8443/ccm talks to https://clm.example.com:9443/jts which is redirected to https://somehost.nowhere.com:8443/jts.
Summary: the IHS hosts the public URI. The clem servers are installed on systems where the do not know the name of. They always talk to the IHS on the public URI which redirects to the applications. This way you can move the servers around, provided IHS stays where it is.
|
I also recommend reviewing the section 'What a reverse proxy will and will not do' in
to make sure that you are not trying to somehow go down a path where a reverse proxy introduced after the public uri is set will not help.
Without a server rename, the CLM applications will always want to be called by either a client like a browser or by a forwarded request from a reverse proxy by its original public URI.
|
thank you for all your input - we have got IHS to work with our new distributed environment after some trials and errors but we got it now.
Comments
That's great! can you share what resolved the issue? Is there anything missing from the articles you referenced? Continuous Improvement is key!
1
Karen Steele
commented May 10 '19, 12:31 p.m.
I'll be honest, we had a lot of great materials given to us. The issue we had with those materials is that there was some underlying assumptions made on all of them either that you had WebSphere, that you were single server, default application installs and different ways of creating the IHS server certificates or key databases - all of which led to some confusion. We had to bind together the references to pull from one and then from another to get what we needed. I'll be documenting exactly what we did and referring to these articles.
|
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
@nerack What do you mean by splash screen? Do you mean an IBM HTTP Server page, with icons like "Administration," "Information Center," "Support," and "Release Notes?"
Have you also used ikeyman.bat to create the keystore?
There is no workable information in the question. No version, no app server. No references to what articles you refer to etc. This basic information is key in a forum.