Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Setting up IHS on top of single server CLM installation

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. 

0 votes

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?"

If this is where you are getting, have you created the plugin-cfg.xml file, and put it in the correct location on the Reverse Proxy Server? Something like IBM\Websphere\Plugins\config\serverName

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. 


All the articles you mention here Ralph are the ones you gave us previously so those are the articles

CLM 6.0.4
IHS Archived version as also indicated in the above articles.

Preston .. same comments as replied to Ralph .... following the article mentioned by Ralph ... followed it to the letter ... when we run http://ihsservername we get a splash screen on the browser of "permission denied" followed by IBM HTTP Server 9.0x listening on port 80 ... when we run the same for https, we get the same message but listening on port 443 ... which is the indication that its running.

We follow thru by using the same URL and expanding it to include for example https://ihsservername:9447/jts/admin or ccm/admin or ccm/web etc ... which does load CLM at the required page.  But the minute we select a project area (if running the command ccm/web) we get a cannot load dashboard as "clmweb.test.local" is not known .. this is the public URI in our standalone configured (working) version without IHS on top of it.

Ralph / Preston ... so I think I got a little further, however, I still have an issue .. so to elaborate further :

Single server installation of CLM 6.0.4 with a public uri of clmweb.test.local sitting currently on a server and being access directly by the url https://clmweb.test.local:9447/x

Can't move between project areas using the IHS server URL it's trying to resolve to my public URI which has not changed ?



3 answers

Permanent link

 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.

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.

0 votes


Permanent link
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.

0 votes


Permanent link

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.

0 votes

Comments
That's great! can you share what resolved the issue? Is there anything missing from the articles you referenced? Continuous Improvement is key!

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.

1 vote

Your answer

Register or log in to post 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.

Search context
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
× 7,494
× 1,381

Question asked: Apr 16 '19, 3:17 p.m.

Question was seen: 3,355 times

Last updated: May 10 '19, 12:31 p.m.

Confirmation Cancel Confirm