It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×7,387
×4,693

question asked: Feb 27 '14, 2:22 p.m.
question was seen: 4,764 times
last updated: Mar 30 '16, 6:30 p.m.

Related questions

FAQ - How this Forum works

Can I change the db password in the web UI for Jazz applications without restarting the server?

0
Alex Fitzpatrick (558●3●8●16) | asked Feb 27 '14, 2:22 p.m.
JAZZ DEVELOPER
 We have a requirement to change all passwords on a regular basis, it would be much easier for us to manage if we didn't have to include a server restart in our procedure or schedule downtime.

Is that possible with CLM applications?

Accepted answer

4
permanent link
James Bognar (143●3●4) | answered Feb 27 '14, 2:26 p.m.
JAZZ DEVELOPER
Short answer is...no, the server does not need to be restarted.

Long answer....
When you change the database password on the advanced properties page, it triggers the connection pool service to restart. This causes all services that depend on it to also restart (which is practically all of them). So the server will practically restart anyway, and the UI will likely be unresponsive for a period of time while all the services restart.

Several bugs were fixed in 4.0.3 that caused deadlocks to occur when services were stopped and restarted.  Therefore, if you're on 4.0.2 or earlier, the better option would be to restart the server.

Alex Fitzpatrick selected this answer as the correct answer
Comments
Alex Fitzpatrick commented Feb 28 '14, 11:43 a.m.
JAZZ DEVELOPER

It sounds to me that there are advantages and disadvantages to both approaches since an on-the-fly change will impact end-users.


It seems that such a change should be treated as preventative maintenance, scheduled accordingly and users warned of potential impacts.

One other answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
long TRUONG (365●4●118●146) | answered Mar 30 '16, 6:30 p.m.
 A late addition to maybe complement the right answer above:

The impact would be so brief, if SCM and DBA team up well to complete the implementation or the below procedure is adopted, to be worth a notification.

The following procedure we adopted would further minimize the risk and the weight of impact, and would as well remove the necessity of schedule sync between the two teams (SCM & DBA):
  • At their convenience, DBA team creates a second set of bona fide ID/passwd, switchToID/switchToPasswd (assuming the same set used for all DB's) ahead of passwd-change D-day.
  • SCM team changes the passwd (via thus created set of ID/passwd or another existing set of ID/to-be-used-newPasswd)
    • Independently verify login, credentials, permissions ( by direct access to the DB's) rigorously (to avoid the brouhaha we got in due to permissions to the switchToID, and too shallow check: Jazz Forum Post 218742) of the switchToID
    • Change the database DB/passwd on the Data Connection web page. Note that for each app (JTS, RTC, RRC, RQM) there are two sets of ID/passwd on the web page, one for the app DB, one for datawarehouse DB: Switch from switchFromID/switchFromPasswd to switchToID/switchToPasswd. 
    • Save the web page: Be patient, the save of the web page may take time to complete
    • Verify access from the Jazz tools.
    • Optionally verify the DB log(s).
  • Again at their convenience, post passwd change completion, DBA team changes the switchFromPasswd, of the now idle ID switchFromID, to an agreed-to new passwd for the next passwd change.
On subsequent passwd change, the first step of creating a new set of ID/passwd will be skipped, the passwd change procedure will start with the SCM team performing the passwd change on the waiting set of ID/passwd.

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.