Monthly Archives: April 2009

Signing jar-files

A project is using Sferyx in Webforms, and the file HTMLEditorLight.jar is used. But ‘copy and paste’ from outside the form to the editor is not working. Cause: the jar-file need to be signed. To sign a jar-file the tools ‘keytool’ and ‘jarsigner’ is needed. But… why not use a script from e.g. webutil:  sign_webutil.sh? With a few adjustments it’s a quite common, usable script.

Below is the script. In bold the variables which you need to adjust. Beware of the different paths for ‘keytool’ / ‘jarsigner’ !

#!/bin/sh
#
# sign_jar.sh
#
# Copyright (c) 2002, 2004, Oracle. All rights reserved.
#
#   NAME
#      sign_jar.sh – Sample script to sign jar-files
#   USAGE
#      sign_jar.sh <jar_file>
#      jar_file : Path of the jar file to be signed. Prefer to use forward
#                 slash instead of back-slash. Otherwise, some characters may
#                 be strangely escaped. e.g. \f may be printed as ‘female’
#                 symbol character on some systems.
#   NOTES
#      This script uses keytool and jarsigner utilities, which usually comes
#      along with JDK in its bin directory. These two utilities must be
#      available in the PATH for this script to work. Otherwise, signing
#      will fail even though the script may show a successful signing.
#
# The following are the Distinguished Names for keytool. You can change them
# to generate your own key.
# CN = Common Name
# OU = Organization Unit
# O  = Organization
# C  = Country code
#
# Certificate settings:
# These are used to generate the initial signing certificate
# Change them to suite your organisation
#
DN_CN=”Example Firm”
DN_OU=”Development Tools”
DN_O=Mydomain
DN_C=nl

#
# Give your keystore file
KEYSTORE=/home/oracle/dba/key/.keystore
#
# If KEYSTORE already exists, old KEYSTORE_PASSWORD for the keystore file must
# be correctly given here. If KEYSTORE does not already exist, any password
# given here will be taken for the new KEYSTORE file to be created.
#
KEYSTORE_PASSWORD=<keystore_passw>
#
# Give your alias key here.
#
JAR_KEY=<app_name>
#
# Key Password for the given key to be used for signing.
#
JAR_KEY_PASSWORD=<file_passw>
#
# Number of days before this certificate expires
#
VALIDDAYS=360

#
# Signing script starts here…
#
if test $# -lt 1
then
echo Jar file name not given for signing. Use
echo “$0 <jar-file>”
exit 1
elif test $# -ne 1
then
echo Incorrect parameters. Use
echo “$0 <jar-file>”
exit 1
fi

echo “Generating a self signing certificate for key=$JAR_KEY…”
error_text=`$ORACLE_HOME/jre/1.4.2/bin/keytool -genkey -dname “CN=$DN_CN, OU=$DN_OU, O=$DN_O, C=$DN_C” \
-alias $JAR_KEY -keypass $JAR_KEY_PASSWORD -keystore $KEYSTORE \
-storepass $KEYSTORE_PASSWORD -validity $VALIDDAYS`
# Check for any error
found=`echo “$error_text” | grep -c “already exists”`
isError=`echo “$error_text” | grep -c “error”`

if test $found -ne 0
then
# Let us show this as warning.
echo “Warning: $JAR_KEY already present in $KEYSTORE”
elif test $isError -ne 0
then
echo $error_text
else
echo “…successfully done.”
fi

echo “\n”
# Signing the jar
echo “Backing up $1 as $1.old…”
cp -f $1 $1.old
echo “\n”
echo “Signing $1 using key=$JAR_KEY…”
error_text=`$ORACLE_HOME/jdk/bin/jarsigner -keystore $KEYSTORE -storepass $KEYSTORE_PASSWORD -keypass $JAR_KEY_PASSWORD \
$1 $JAR_KEY`
# Check for any error
if test “$error_text” != “”
then
echo $error_text
echo “Signing $1 failed.”
else
echo “…successfully done.”
fi

By |April 29th, 2009|Categories: App. Server|Tags: , , |0 Comments

Status application server down in Grid Control, while all components are up.

m4s0n501

Platform:  application server 10.1.2.0.2 on Suse Linux 9. Grid Control agent 10.2.04.

All components within the application server are up, but the home page of Grid Control showing it down.

Underlying cause: bug in discovering ports by the agent.  Agent discovering process gets Forms url Port from < HOME_IAS>/10.1.2/forms/server/target2add.xml. But this port is not the expected port.

Two actions:

I – changed port in targets.xml in agent-home.

1. Check what is the real port for Forms application url (e.g. 7779 in stead of 7778, you can see this in the home-page of the middle-tier in Grid Control), this is  the Oracle HTTP Server Listen port, take the portlist.ini (if you are sure nothing has changed), or in httpd.conf, or through the Grid Control, search for ports in the http-section.

2. Edit <GRID_AGENT_HOME>/sysman/emd/targets.xml

For Target TYPE=”oracle_forms”  change the port in parameter :  Property NAME=”ServletUrl” — In my case from 7778 to 7779.

3. Restart the agent then check if Forms status change in grid control.

II – Changed port in targets.xml in midtier.

1. Navigate to “$ORACLE_HOME /sysman/emd” and open the “targets.xml” file.

2. Find the line reffering to the “ServletUrl” property. It should look like this:
<Property NAME=”ServletUrl” VALUE=”http://<HOST>:<PORT>/forms/lservlet”/>

3. In the above line replace the PORT with the Oracle HTTP Server Listen port).

5. Save and close the targets.xml

6. Run the following command: “opmnctl reload”

7. Run the following command “opmnctl restartproc process-type=HTTP_Server” – or restart through the Enterprise Manager.

8. Test a couple of times the status of the “Forms” component in Enterprise Manager by refreshing the data (In the EM page on the upper right)
References

But remember: actions like ‘agent -ca’ (rediscovering) may cause this to do the actions above again…

757363.1 : Forms Target Status Shows as Down Although It is UP.
469577.1 : Forms Looks Always Stopped From Oracle Enterprise Manager

By |April 21st, 2009|Categories: grid control|Tags: , |2 Comments

Crash Grid Control agent, too many open files;health check-error

Agent (10.2.0.4) crashes – on a site (64-bit) with many databases (10.2.0.3) a lot, intermittently – , too many open files, emagent.trc gives ‘health check’ error

Agent gave messages – in the past – like this:

Number files opened by Agent is 1140.
These files appeared to be the $ORACLE_HOME/dbs/hc<instance>_.dat which is loaded a lot in memory.

Checked this out by first determining which process the agent has:
–> ps -ef |grep emagent
Then checked the memory map of the process of the agent (here e.g. : 23645)
–> pmap -x 23645
And this is a very, very long list,so I hit the jackpot…

Logging of the emagent.trc ($AGENT_HOME/sysman/log):

2008-04-22 15:29:20,221 Thread-4094679984 ERROR engine: [oracle_database,<rep_database>,health_check] :
nmeegd_GetMetricData failed : Instance Health Check initialization failed due to one of the
following causes: the owner of the EM agent process is not same as the owner of the Oracle
instance processes; the owner of the EM agent process is not part of the dba group; or the
database version is not 10g (10.1.0.2) and above.

Cause: Bug 5872000 – HEALTHCHECK ERROR OCCURS FOR 32BIT DATABASE ON 64BIT OS DUE TO BUG4526916 FIX.
The Healthcheck file, namely $RDBMS_HOME/dbs/hc_.dat file differs in  size from the memory structure used by the Agent to read it. This file is created by the database on startup time, if not present.

This happens when the database is e.g. 10.2.0.4 and the agent 10.2.0.3 and vice versa.
In the latter case this is solved by upgrading the database to 10.2.0.4. or 11.1.0.7.

Possible solutions for myself:

1. Apply Patch 5872000 to 32-bit or 64-bit databases on 64-bit machines.
This needs to be applied on top of 10.1 -> 10.2.0.3, and 11.1.0.6 databases.
The following file may need to be removed from the DATABASE $ORACLE_HOME/dbs directory before starting up the database after patch application: hc_.dat
NOTE: This file is created on database start up if not present. The agent uses this file for the
Healthcheck metric. By recreating the file on start up after the patch application, the file is
the correct one needed by the agent.

An easier way for the time being:
2. Disable the Healthcheck metric per database in grid Control:
This has no consequences for the monitoring the database if it’s still up for example (I tested this first..).
In the Metric and Policy settings page, tab Metrics, you will not see the metric Health Check displayed, even if you choose All metrics instead of the default Metrics with thresholds value in the Drop Down list titled View.

The Health Check metric is a composite metric which includes 7 metrics:
Instance Status
Instance State
Maintenance
Mounted
State Description
Unavailable
Unmounted

a. Go to the database Home Page for which you want to disable this metric
At the bottom pane Related Links, click on the link Metric and Policy Settings
b. Go to the metric Instance Status (or to any other metric belonging to the Health Check metric)
Click on the link in the column “Frequency Schedule”: 15 seconds by default
c. Once in the Edit Collection Settings Home Page
Press the disable button to disable this metric collection or
Change the collection frequency and any other value you want to change in this page
Note: you will see at the bottom of the page a sheet titled “Affected Metrics” which lists all the metrics which will be changed in the same way as the current metric.
You will notice that all the metrics pertaining to the Health Check metric are listed there.
Hence they will all been disabled or they will all have the new frequency collection as the one currently updated.
d. Click on Continue then on OK in order for this changes to be saved in the repository
e. Then click on OK once the Update confirmation received.
A new collection file for this database will be created in the Monitoring Agent of this target in the directory $ORACLE_HOME/sysman/emd/collection.

Oh, and don’t forget to stop and start the agent on the target nodes after you’ve done this.

Grid 10.2.0.5:

Mr Akhtar Tiwana checked this issue with Oracle support,  and they suggested to remove the warning and critical thresholds for health check metrics (making them NULL) and that will do the same. The functionality to disable these metrics apparently have been taken away in grid 10.2.05.

Used sources:
564617.1 Agent Fails on Instance Health Check Following Upgrade To 10.2.0.4
566607.1 Healthcheck Metric Collection Fails Since Agent was Upgraded to 10.2.0.4 on Linux x86-64 platform

By |April 16th, 2009|Categories: grid control|Tags: |2 Comments

Designer upgrade, 10.1.2.4 to 10.1.2.5, freezing import and connection lost…

Decided to upgrade designer (yes ! we’re still working with this tool…). First tested it by importing the owner (and in my case HSU65 from headstart, and a testuser) in another database…
Downloaded patch 10_2_r5. Unzipped, runInstaller, upgrade the client. No problem.
Started the RAU-utility for upgrading the repository, pushed the button ‘Upgrade’ and off we go… Box opens with an import, and it stays open / freezes with the following text:

import done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
export client uses WE8ISO8859P1 character set (possible charset conversion)
. importing DES10G_OWNER objects into REPOS_OWNER
. . importing table “CK_INSTALLED_OBJECTS” 7800 rows imported
. . importing table “CK_PRODUCT_ELEMENTS” 545 rows imported

Waited for half an hour, but it hangs, no doubt about it. Closed the import box, and the process continues!
Upgrade repository o.k.
Then the test. Opening designer, delete an object and connection was lost with the database:
Message
——-
RME-02102: Not connected to a database
RME-02121: Failed to open cursor
RME-02124: Failed to execute SQL statement: select decode(the_tab.state, ‘I’, 0, ‘O’, 1, ‘N’, 2, -1) from i$sdd_object_versions the_tab , I$SDD_WA_CONTEXT CTXT WHERE CTXT.OBJECT_IVID = THE_TAB.IVID AND CTXT.WORKAREA_IRID = :WA AND CTXT.WASTEBASKET = ‘N’ AND THE_TAB.IRID = :IRID

Solved this by :
alter system set “_optimizer_cost_based_transformation”=off scope=both;

Let’s say this is the Oracle way…

By |April 15th, 2009|Categories: Database||0 Comments

Internet Explorer crashes with Oracle forms / Jinitiator

Problem: when running form modules using Internet Explorer and JInitiator 1.3.1.x, the browser window opens and crashes immediately before the applet starts. When using Mozilla Firefox, there’s no problem at all.

Several notes on Metalink about this:  602001.1, 430359.1, 550301.1
The issue does not occur when using Sun JRE version 1.4, 1.5 and 1.6.

This issue is first logged as JInitiator Bug 5643502 – INTERNET EXPLORER WITH WINDOWS LIVE TOOLBAR PLUG-IN CRASHES, but based on Sun Bug 4741238, the bug occurs in JRE version 1.3 (JInitiator is based on JRE 1.3) and the bug is fixed in JRE versions 1.4 and higher.

Solution according the notes
To avoid the crash,
(1) Use Sun JRE 1.4 and higher
– OR –
(2) Uninstall Windows Live Toolbar (or other software what you suspect is the cause)
– OR –
(3) Disable the toolbar’s associated Add-ons as the following:
1. Open Internet Explorer
2. From the menu open Tools -> Manage Add-ons -> Enable or Disable Add-ons
3. Select the following Add-ons and disable each of them by clicking the “Disable” button

– Windows Live Sign-In Helper
– Windows Live Toolbar
– Windows Live Toolbar Helper
– Windows Messenger
4. Restart Internet Explorer
– OR –
(4) Disable 3rd-party browser extensions as follows:
– From the browser menu Tools -> Internet Options -> Advanced
– Uncheck “Enable third-party browser extensions”

First I chose for the last option, the policy was changed by the Windows system administrators for all the clients in the network, and done.. But there were (un)expected side-affects, like a particular SSO-application could’nt be reached anymore. People didn’t appreciate this  ;-)

By |April 3rd, 2009|Categories: App. Server|Tags: , , |19 Comments