It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×7,451
×6,108

question asked: Mar 26 '18, 10:48 a.m.
question was seen: 1,781 times
last updated: Mar 27 '18, 5:26 p.m.

Related questions

Can I change port number on apps on proxy server without a rename

0
David Mehaffy (901●2●33●38) | asked Mar 26 '18, 10:48 a.m.
JAZZ DEVELOPER
edited Mar 26 '18, 11:22 a.m.

I have a sandbox setup with all apps on a single server and the public URL is https://clm-sb...../jts.
Now I want to move some of the apps to separate servers and use a IHS reverse proxy on https://clm...../
It seems very easy to do for the apps that are moved as I rewrite the incoming URL to point to the new app location
For the apps that are staying on the original server which also has the proxy server can I just change the app server to listen on say :9443 and rewrite the incoming request to be https://clm-sb..../jts -> https://clm-sb....:9443/jts ?

BTW - I am using 6.0.5 with Liberty Profile

2 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Daniel Barbour (250●3●23) | answered Mar 26 '18, 2:03 p.m.

In the long run it would be best to perform the server rename.  From the wording of the question I assume that your Public URI does not include a port number (i.e. the network is using the implied 443 port number and you modified your server.xml file to use 443 for https instead of 9443).

While I have seen what you are asking for work in an 'experimental' environment - i.e. the Public URI remained unchanged (no port number) and the server.xml file was modified to use port 9443 - it is necessary to use a port forwarding mechanism to forward tcp/udp messages that are addressed to https://clm-sb.../<app_context> to https://clm-sb...:9443/<app_context>.  But this additional network activity comes with a cost, in my case I observed a 30-40% performance hit.

Secondly - If you are running your server in a Windows environment - I found that when trying to use netsh as the port forwarding app that application server eventually stopped working (netsh could not 'keep up').  There is 'freeware' tool I found that was more reliable than netsh (PassPort)..available on sourceforge.net that worked for my experimental tests but I cannot attest to its reliability for long-term usage (plus, these days one should always be concerned about what security holes are introduced by using 'free ware' apps).

If using a unix-based OS for your app server you could try using iptables to configure port-forwarding.

All-in-all though, my recommendation is to bite-the-bullet and use the server rename rather than continue forward with your original public URI.

Comments
David Mehaffy commented Mar 26 '18, 2:18 p.m.
JAZZ DEVELOPER

Thanks for the answer.  I had originally done a server rename to remove the 9443 a while back.  I have been experimenting with changing it back to 9443 in a rename but that did not seem to work well with the apps communicating with each other.  This is a unix system and I will be setting up a reverse proxy.  Maybe I am missing something but if I have :443 as the port coming in an remap to :9443 isn't :443 really being passed to the server and translated coming back?

David Mehaffy commented Mar 26 '18, 3:02 p.m.
JAZZ DEVELOPER

I think the challenge is this:  I have the following in mappings.txt:

I am renaming clm to clm-sb

original
source https://clm.../jts
target https://clm...../jts

source https://clm....:443/jts
target https://clm....:443/jts

I would rename like this ?

new mapping:

source https://clm..../jts
target https://clm-sb:9443/jts

source https://clm....:443/jts
source https://clm-sb:443/jts

I would have thought the last target would be 9443 but it will not let me have the same target

this does not seem right - can anyone verify

Daniel Barbour commented Mar 26 '18, 3:15 p.m. | edited Mar 26 '18, 3:15 p.m.

It has been a couple of years since I performed a server rename - but I think that you are seeing an error because the last block should use :9443 in the second line, i.e.

source https://clm....:443/jts
source https://clm-sb:9443/jts

My comment is based on the following help info:
https://jazz.net/help-dev/clm/topic/com.ibm.jazz.install.doc/topics/c_server_rename_plan.html (Go to 'Mapping File for Server Rename' and then search for URLs with default ports)

Since 443 is a 'default port', i.e. 'implicit' port,  your first 'new mapping' entry takes care of the 'default' scenario - while the second pair covers the cases where the internal URL includes an 'explicit' entry for port 443.

David Mehaffy commented Mar 26 '18, 3:43 p.m.
JAZZ DEVELOPER

Well if I do as suggested I get a duplicate port error.  But the link you supplied looks like I would do the way I have but what I find is the cross application links for things like workitems don't get renamed

Daniel Barbour commented Mar 26 '18, 3:52 p.m.

In regard to "..cross application links for things like workitems don't get renamed.." did your mapping file include entries for ALL of the apps (jts, ccm, rm, qm, etc...(i.e all apps you have installed))?  workitems would fall under ccm.  If your apps are distributed across multiple servers (implied by your reference to a 'reverse proxy server' in the original post - you would also need to complete a server rename operation on each individual server.

David Mehaffy commented Mar 26 '18, 4:27 p.m.
JAZZ DEVELOPER

My mapping file includes all apps.  I guess I am not clear on my scenario.  I have 5.0.2 production with everything on one server with implied 443 in URL.  I am setting up a test server - so I have to do a server rename first.  Then I will upgrade to 6.0.5 with all applications on a single server (makes the upgrade simpler).  Then I want to move to a distributed environment with an IHS reverse proxy connecting to CLM-Liberty servers - so I need a reverse proxy anyways as our users want a single name space.  This is for testing before moving production

Daniel Barbour commented Mar 27 '18, 9:29 a.m.

David,

For some reason clicking 'show 1 more comments' isn't working for me on this forum but your last comment did show up in my email.  Your setup (all-in-one, implicit 443 port) is the same as our current one...if your are still having issues, and if I get time, I can try to perform a rename on one of my VM snapshots but I don't have a 5.0.2 env anymore..oldest is 6.0.3).  A copy of your (edited) mapping file and error/log file might be helpful too.

Daniel Barbour commented Mar 27 '18, 12:23 p.m.

David,

I seem to be reproducing your problem.  There seems to be an issue with the server rename tool (I tried in a 6.0.4 environment) for the specific scenario where one is trying to go from a URL with an 'implicit' Port number (443) back to an explicit Port.

I am in a 'catch-22' scenario: (the URLs below are not publicly accessible)

With the following content (no alternate URL) I get the following error during -verifyULRMappings: "When a URL has no port specified, or when it has the default port specified, the alternate URL must be mapped as well..."

/rm


source=https://ct-clm-tqk/rm
target=https://ct-clm-tqk:9443/rm

However - when I follow the intent and DO provide the alternate (below) I get the following error during -verifyURLMappings: "Source and Target entries in the mapping file cannot be duplicated..."

/rm


source=https://ct-clm-tqk/rm
target=https://ct-clm-tqk:9443/rm

source=https://ct-clm-tqk:443/rm
target=https://ct-clm-tqk:9443/rm

I rec opening a PMR (I would if I actually needed to change  my URL back)


showing 5 of 8 show 3 more comments
0
permanent link
Daniel Barbour (250●3●23) | answered Mar 27 '18, 12:49 p.m.
edited Mar 27 '18, 5:26 p.m.

David,

I'm repeating my last commentary since there seems to be an issue with displaying the entirety of a comment thread (at least there is a problem for me to view them).

I appear to be having the same problem (with a 6.0.4 environment) during a server rename that you are having - at least for the specific scenario where a Public URL is being renamed from one which uses an 'implicit' (default) port number (i.e. 443) to one which uses an explicit port number (9443).

For a mappings file that looks like the following -

#/gc
source=https://ct-clm-tqk/gc
target=https://ct-clm-tqk:9443/gc

source=https://ct-clm-tqk:443/gc
target=https://ct-clm-tqk:9443/gc

#/ccm
source=https://ct-clm-tqk/ccm
target=https://ct-clm-tqk:9443/ccm

source=https://ct-clm-tqk:443/ccm
target=https://ct-clm-tqk:9443/ccm

#/rm
source=https://ct-clm-tqk/rm
target=https://ct-clm-tqk:9443/rm

source=https://ct-clm-tqk:443/rm
target=https://ct-clm-tqk:9443/rm
etc..

I get the following warning during -verifyURLMappings:
When a URL has no port specified, or when it has the default port specified, the
n the alternate URL must be mapped as well. The following URLs lack their altern
ate forms:
https://ct-clm-tqk/qm

Source and Target entries in the mapping file cannot be duplicated.  The followi
ng URLs were found to be duplicated as source or target entry in the mapping fil
e:
https://ct-clm-tqk:9443/gc
https://ct-clm-tqk:9443/ccm
https://ct-clm-tqk:9443/rm
https://ct-clm-tqk:9443/converter/htmlgen
https://ct-clm-tqk:9443/jts
https://ct-clm-tqk:9443/clmhelp
However - when I remove the 'duplicate' entries, as in:
#/gc
source=https://ct-clm-tqk/gc
target=https://ct-clm-tqk:9443/gc

#/ccm
source=https://ct-clm-tqk/ccm
target=https://ct-clm-tqk:9443/ccm

#/rm
source=https://ct-clm-tqk/rm
target=https://ct-clm-tqk:9443/rm
I get the following warning during -verifyURLMappings

When a URL has no port specified, or when it has the default port specified, the
n the alternate URL must be mapped as well. The following URLs lack their altern
ate forms:
https://ct-clm-tqk:443/gc
https://ct-clm-tqk:443/ccm
https://ct-clm-tqk:443/rm
https://ct-clm-tqk:443/converter/htmlgen
https://ct-clm-tqk:443/jts
https://ct-clm-tqk:443/clmhelp
https://ct-clm-tqk:443/qm
Given the warnings during the 'verify' step.  This looks like a 'Catch-22' issue with server rename that needs to be escalated for repair.

----- Update ----
Regardless of the warnings raised during the 'verify' step - I did actually 'try' importing the mappings files from both of the above cases.

The first one (where the 'duplicate' warning was raised) did NOT work.  When the import was started for the second 'gc' entry an error message was raised indicating that the mapping had already been completed and the import operation halted (leaving the partially updated environment in unhelpful state..annoying, but I had a VM snapshot so no harm).

The second one (where the warning informed of a missing 'alternate' entry) completed successfully.  As far as I can tell, all of my projects are present and accessible using the updated public URL (where I restored the :9443 port number to the URL).  Your mileage may vary. 

However, I do believe that the the mappings.txt file with the 'alternate' address entries SHOULD have worked and a PMR is still warranted but I won't be entering one since it entails an time obligation that I cannot make since we are staying with our current URL (no port number) pattern.

Your answer

Register or 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.