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

Any step-by-step guide to switching CLM 5.0.2 from Tomcat to WAS?

Questions
Tags
Users
Badges
long TRUONG
(365●4●123●147) May 11 '16, 4:27 p.m.
 Are we lucky enough to be pointed to a step-by-step guide to switching CLM 5.0.2 from Tomcat to WAS, stumbled upon by a member of our community?

After the 8-day-7-night long saga ( post 220347) we maxed out the memory at 32GB  allowed by Windows Server 2008 on a VM. Thus far, we have been advised "More Memory! More Memory!....more Resources! More Resources" with every occurence of interruption/issue. We are now looking at upgrading our hardware/VM to beyond the 32GB limit. We are also looking at switching to WAS for more stability.

  • From backing up files and DB's as precaution
  • To Setting up WebSphere Application Server
  • To the mid-stream step Deploying applications for CLM on WAS which guides through a new installation of CLM apps. We assume for an existing Tomcat installation, we should:
    • skip this step as described.
    • Stop Tomcat Service and disable it
    • Configure WAS to point to the existing CLM app area previously served by Tomcat.
This would be our first installation of WAS, our questions:
  • We configure WAS with exactly same JVM options (mainly -Xmx16G, -Xms16G. -Xmn2G) as current Tomcat and server.startup.bat?
  • Can we choose to run server.startup.bat on command linejust like before. We noticed that doing so wpuld spawn a Tomcat console while using Tomcat ... With WAS what should we expect? Any required config changes to server.startup.bat?
  • Any other pointers? Anything we should be aware of?

0 votes

Comments
long TRUONG
May 11 '16, 4:51 p.m.

 Did find Post 12361: How migrate from tomcat to was? but it does not answer our questions.

1 answer
2,804 views
0 votes

Accepted answer

Permanent link
Donald Nong
(14.5k●6●14) edited
May 11 '16, 11:35 p.m.
You can use the same JVM heap size settings in WAS.

After you switch from Tomcat to WebSphere, you should stop using the server.startup script. That script is used for starting up the bundled application server (previously Tomcat, and now WAS Liberty in 6.0.x).

Starting up WAS is very simple, just run <was_profile>/bin/startServer <server_name>. If you follow the instructions for configuring the WAS server, all necessary environment variables (such as JVM heap size) are already stored within WAS, and you don't need to pass them on with a script.

Stopping WAS is equally simple just run <was_profile>/bin/stopServer <server_name> -username <wasadmin> -password <userpassword>.

There are no direct method to migrate the user repository though, if you're not aware of. If you are switching from Tomcat User Management to WAS Federated Repository, you simply have to create each single user manually. If you are using LDAP, you have to configure LDAP in WAS from scratch.

EDIT: Read your post again and found something wrong. You should not skip any steps in "Deploying applications for CLM on WAS". WAS does not use anything in the existing "tomcat" directory.
long TRUONG selected this answer as the correct answer

0 votes

Comments
long TRUONG
May 12 '16, 10:37 a.m.

 Thx Don,


Was hoping the user repo issue only a non-LDAP one: an LDAP user repo just magically hopping into place. Or rather unconciously swept unpleasant thoughts to the back of my mind.

From scratch, you meant to import users again one by one from LDAP? Still an unpleasant (minor?) requirement, even though that will clean up the hundreds of invalid, non-LDAP users somehow made their way to our register. Wonder if there is an import in bulk facility.

What will we do with the archived (&departed) users no longer on LDAP? We have to tap into WAS (apparent?) ability of having concurrent LDAP and non-LDAP users?

If CLM is to be deployed anew, how will the backed up war and teamserver.properties files be incorporated into the new install area? And we will have to do either a full reindex or copy a sync'ed appSide index over to new install area?

long TRUONG
May 12 '16, 11:07 a.m.

 Also, as 6.0.x is bundled with Liberty, would the upgrade include procedures to migrate the user repo and appSide index?

Donald Nong
May 12 '16, 10:36 p.m.

By "from scratch", I mean that you cannot "migrate" the LDAP configuration from Tomcat to WAS - the steps for setting up LDAP in WAS have nothing to do with Tomcat, whether you previously used Tomcat or not.

If you only switch Tomcat to WAS, the users in CLM remain the same, and the users on the LDAP server remain the same. There is no magical "cleanup" happening.

If you want to utilize the WAS Federated User Repository for a more complicated configuration (such as multiple LDAP server, and perhaps plus non-LDAP users), that's a different story. Keep it simple for the switch - basically, from file based to file based, or from LDAP to LDAP.

If you want to have a completely new installation, the .war files should be readily available whether you back them up or not. The teamserver.properties file should be copied over to the new environment. The indices can be copied over to the new environment to avoid rebuilding them (make sure the teamserver.properties file has the correct index folders).

long TRUONG
May 13 '16, 1:42 a.m.

 Thx Don

long TRUONG
May 25 '16, 5:17 p.m.

 Don, 

Reread&reread your last comments, still not understand all.
From "let keep it simple", in our case LDAP to LDAP: if have to re-import existing users under Tomcat, one-by-one from LDAP, when switch to WAS: Then how can we accommodate those archived users who are no longer in LDAP.
Could we have read your answer wrong: actually the users imported from LDAP are kept in CLM DBs. Hence once switched to WAS, we could still use the users repo on the CLM DBs, as long as we set up WAS properly to use LDAP? In that case we need not to worry about re-import one-by-one nor should we be worry about archived users.

And in the first case, where we need to rebuild the user repo, can we use the repotools command to export users to a csv file while Tomcat is in effect. Then when switched to WAS, we again use the repotools command to import users (including archived ones) from that same csv file? (https://jazz.net/forum/questions/169021/any-api-or-command-line-interface-cli-in-clm-which-will-help-us-to-do-user-management-like-user-import-and-license-assigne)

Donald Nong
May 25 '16, 9:08 p.m.

You don't need to do anything on the CLM side when switching from Tomcat to WAS, if there are no changes on the LDAP server. As long as you correctly configure LDAP in WAS, everything should just work.

I'm not quite sure why you are worried about the "archived users". Regardless these users exist on the LDAP server or not, they can no longer log on to CLM.

Keep in mind that the user repository in the application server (WAS or Tomcat) and the one in CLM are separate. The only thing linked between them is the user ID. The user authentication is done on the application server (LDAP or not). Once authenticated, the application will map the security role(s) to the user, and pass it along to the (CLM) application, for example, dnong(JazzAdmins). The application will retrieve the user based on the user ID, and load dashboards and other stuff being requested.

Note that the LDAP configuration in the JTS Advanced Properties page is for "user synchronization" (full name and email) only, and has nothing to do with authentication.

long TRUONG
May 26 '16, 2:48 p.m.

 Thx Don,


Ah! I had a completely wrong picture of the authentication process: import from LDAP ==> user repo on CLM DBs, and authentication was just a black box (not thinking any further! ) and it picks up the infos from this user repo to authenticate.

Now though not yet completely clear, I perceived that: 
  • Authentication is using either a local list or LDAP repo for its user repo
  • Can't migrate Tomcat local list to WAS local list
  • To use LDAP repo on WAS, proper configuration of WAS to be done, just as it was done on Tomcat previously according to Tomcat requirements.
  • Application (WAS or Tomcat) maps security role to user, then send the pair userID/security role to CLM which in turn uses the pair for access..
  • Nighly sync's are for changes of other infos on the LDAP accounts, based on userID

Donald Nong
May 26 '16, 9:09 p.m.
  • Sort of right. The authentication is done by the application server against the configured user repository.
  • By "local list", if you mean the file based user repository, actually you can do it manually. No scripts can help you though, as far as I know.
  • Correct.
  • Correct.
  • Correct.

long TRUONG
May 31 '16, 1:14 p.m.

 Thx Don


We are on our way now without any apprehension.

showing 5 of 9 show 4 more comments

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.

Ask a question
Guidelines
FAQ
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

Question asked: May 11 '16, 4:27 p.m.

Question was seen: 2,804 times

Last updated: May 31 '16, 1:14 p.m.

Confirmation Cancel Confirm