[chrisplough]

Just a quick note to say that OTM v5.5 CU04 has been released and is on the Oracle Metalink site earlier than I had expected! The patch number is 6705191 and it's a whopper (640MB for Linux). You can find the release notes here:

https://updates.oracle.com/ARULink/R...92&no_header=1

We haven't installed it yet, but plan to play with it in late December / early January and will report back.

BTW - thank you Shells for the tip

--Chris

[nick.polites]

After applying CU-4 we saw the following errors when applying the dbpatch_55

Adding patch data content
Updating general content...
(Call for updating content is ./update_content.sh /otm/glog/config V55P)

GLOGOWNER connection set to dbaglogowner
REPORTOWNER connection set to dbareportowner

java.io.FileNotFoundException: /otm/glog/config/glog.patches.properties (No such file or directory)


The installer is supposed to remove the glog.patches.properties file after each CU upgrade, however something else is now referencing it and as it doesn’t exist, it throws the stack trace. I believe that you can ignore the errors and the database should be upgraded correctly. To fix the error, you can create a blank file named glog.patches.properties in your OTM/glog/config directory and re-run dbpatch_55.sql.

Also there is a typo in the release notes for this patch under the section on removing a weblogic file.

It says the following:

File To Be Removed for WebLogic
You must remove a file from the WebLogic installation because of a code conflict between it and the latest JDBC drivers with which OTM ships. The simplest and safest way to do this is to rename the file. The file in question is:
<weblogic_install_path>/server/lib/odbc14.jar
rename it to be:
<weblogic_install_path>/server/lib/odbc14.jar.bak


The filename is incorrect, it is ojdbc14.jar.

[nick.polites]

I also found an issue after installing CU-4. When you try logging into the application you get the following error:

javax.security.auth.login.LoginException: javax.security.auth.login.LoginException: java.lang.SecurityException: User: guest, failed to be authenticated.
javax.security.auth.login.LoginException: javax.security.auth.login.LoginException: java.lang.SecurityException: User: guest, failed to be authenticated.

It appears that the installer is not entering the correct encrypted password in the OTM/tomcat/bin/tomcat.conf file. You may see something like this:

wrapper.java.additional.18=-DGuestEncodedPassword=TVdPVE1HVUVTVA==

This is incorrect...the correct entry should be: wrapper.java.additional.18=-DGuestEncodedPassword=VAU9uZtJtMwEb3tIVKgN49bfrnE=

I however tried this and that did not work as well. I had to use the plain password entry to get the application started: wrapper.java.additional.18=-DGuestPassword=CHANGEME

Please make sure to restart both your application and web instances when making this change. I tried restarting just the web instance as was still getting the error message.

[naveengupta4s]

Hi,

We have successfully installed OTM 5.5 CU4 patch over CU3 in HP UNIX test environment. The menus look fine, but I can notice a strange thing that for some old field and all new fields being added in this release, the label name is prefixed with "label.<field name>".

Eg. Old fields like, on the main menu, Role appears as label.Role
New fields for instance in Location Manager, the PostalSplc appears as label.PostalSplc.

Kindly advise.

Regards,
Naveen

[nick.polites]

Are all fields appearing with the label. or just a few? If it is just a few, than this looks like either the database update script was not run or there were errors in your update_content part of the database script. Take a look update_content log file and see if any errors occurred in the translation and translation_d updates.

[naveengupta4s]

Hi Nick,

I checked the update_content log file and didn't find any errors. I have also uploaded the same for your reference.

Regards,
Naveen

[nick.polites]

Hi Naveen,


If that is the case then something at startup may be causing the issue. Most likely the problem is occurring at the tomcat layer. Please check the console.log for any errors but I would also check the console.log for weblogic.

A while back in version 4.5 of OTM I found out that my Nagios monitoring of Oracle Reports within OTM was causing tomcat to not initialize properly and the end result was a label.username and label.password at login. I had to have the check sleep 10 minutes after restart to ensure this didn't happen again. I haven't seen this issue since 4.5 but yet again I have also set my sleep windows to 10 minutes after startup. If you have any monitoring applications keep that in mind.

Nick

[cspadola]

A general question to anyone that has installed CU4 and played with it for a little while:

We are currently on OTM 5.5 CU3 and have looked at a couple of fixes that come with CU4. In the meantime, we have workarounds in place until we install CU4. We probably do not expect to upgrade to CU4 for another couple of months (due to time contraints).

Taking into consideration some of the installation issues with CU4, is it worth the effort required to upgrade now or is there already a CU5 in the works to correct some of these issues? Is there an overall positive or negative feel about CU4?

Thanks for your feedback.

CS

[chrisplough]

Hello,

I'm sure that CU5 is in the works (there's always a new one in development), but I wouldn't expect a release for another 6-9 months. Of course, this is speculation, but is based on the previous release cycles.

If you're going to move up and there is a business need to take advantage of the new functionality in CU4, then I'd go ahead and do it. There will be RUs released for CU4 that will resolve any current issues, so you can always wait for CU4 RU1 to implement. Otherwise, if the business need doesn't exist, then you can simply wait until it does and then take the latest CU/RU combination at that time.

As for CU4 - there are some issues with installation and it is quiet a large change -- especially if you're running OAS. As long as you have a solid test plan, though, it shouldn't be an issue. There were also quite a few SCA (scalability) updates in this release, so several of our clients are preparing to move it it.

--Chris

[sknmail@rediffmail.com]

Dear Nick,

Please refer to your post as below -

"It appears that the installer is not entering the correct encrypted password in the OTM/tomcat/bin/tomcat.conf file. You may see something like this:

wrapper.java.additional.18=-DGuestEncodedPassword=TVdPVE1HVUVTVA==

This is incorrect...the correct entry should be: wrapper.java.additional.18=-DGuestEncodedPassword=VAU9uZtJtMwEb3tIVKgN49bfrnE=

I however tried this and that did not work as well. I had to use the plain password entry to get the application started: wrapper.java.additional.18=-DGuestPassword=CHANGEME

Please make sure to restart both your application and web instances when making this change. I tried restarting just the web instance as was still getting the error message."

I was also facing the same issue (same error message as mentioned), however I could find that there was another user "guest" (Not GUEST.ADMIN) which was having password in database in gl_password column as NWdeaPS1r3uZXZIFrQ/EOELxZFA= (My database was newly created available from CU#4 OTM installer). I am not sure what this password was. Now I had to set the password of this user to CHANGEME in encrypted format as VAU9uZtJtMwEb3tIVKgN49bfrnE=. This resolved my issue and I could see my login page.
The parameters in TOMCAT.conf was not set as my current password for GUEST.ADMIN was already CHANGEME. I could find in one of the thread that if the password is already CHANGEME for GUEST.ADMIN, no need to set this parameter; so I removed it. I think this is another issue resolution.
Please let me know if you have faced same issue.

Thanks,
Suresh

After writing above email, I found that there was error while running update_password.sh as a part of dbpatch_55.sql, so my passwords were not reset as CU4 standard password. So I resolved the problem and again re-ran dbpatch_55.sql again. So we have to take care that if for some reason update_password.sh file didn't get executed as part of dbpatch_55, then the problem I mentioned can happen.
- Suresh