Using SPident to reveal the running SuSE release

To verify the Suse 10 release and its Service Packs you can either consult the /etc/SuSE-release file or execute the following command.

[] xxx:/> SPident -v

Summary (using 840 packages)
Product/ServicePack conflict match update (shipped)
SLE-10-x86_64 0 0% 306 36.4% 0 (2754 11.1%)
SLE-10-x86_64-SP1 0 0% 443 52.7% 0 (2938 15.1%)
SLE-10-x86_64-SP2 0 0% 840 100% 0 (2337 35.9%)

CONCLUSION: System is up-to-date!
found SLE-10-x86_64-SP2

[] xxx:/>

Export Oracle Wallet with unencrypted private key

Today i was asked to export the private key of an Oracle Wallet.
After some searching and trying is was able to export this by using openssl.
Oracle Wallet Manager normally only exports the context of the wallet in encrypted format.
This is an Oracle by design decision not to allow export of unencrypted private keys as of security reasons from within the Oracle Wallet Manager. If you however require to export the unencrypted private key and certificate you should use the following command :

openssl pkcs12 -in ewallet.p12 -passin pass: -out ewallet.txt -nodes

wdeploy.sh hangs with FUTEX_WAIT_PRIVATE, 1, NULL

The wdeploy.sh returns a normal output, but hangs at Validating Configuration:

Buildfile: wcommon.xml

config:
Loading config.oas1013
Loading PerformanceManagement.properties

Warning: as_mode property not set. Standalone deployment assumed.

preconfig:

checkargs:
Validating configuration…

When looking at which process is causing the installer to stale. We preformed this command by hand to see what is going wrong here.
In order to get more detail on what is causing the stale we added strace for the $ANT command at the end of the wdeploy.sh script.

..
strace $ANT_HOME/bin/ant –noconfig -f wcommon.xml -Das_type=$as_type -listener org.apache.tools.ant.listener.Log4jListener -emacs -Dwdeploy.dir=$HERE -Dbo.dir=$BODIR -Depm.dir=$EPMDIR -Dolap.dir=$OLAPDIR -Dolap.bin.dir=$OLAPBINDIR -DBOBJE=$BOBJE -Dplatform=$platform -Dproperties.file=$propsfile $cmdline
..

executing this command ;

./wdeploy.sh oas1013 -DAPP=PerformanceManagement -Das_admin_password=”oc4j_admin_password” -Dlanglist=”en,nl” deploy

shows us that the process is waiting for resources which it does not get.

..
mmap2(NULL, 528384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = 0×8d275000 clone(child_stack=0×8d2f54b4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|
CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|
CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0×8d2f5bd8, {entry_number:6, base_addr:0×8d2f5b90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0×8d2f5bd8) = 9401 sched_setscheduler(9401, SCHED_OTHER, { 5 }) = -1 EINVAL (Invalid argument) futex(0xa2878ec, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xa2878e8, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 futex(0xa2ae550, FUTEX_WAKE_PRIVATE, 1) = 1 mmap2(NULL, 528384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = 0×8d1f4000 clone(child_stack=0×8d2744b4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|
CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|
CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0×8d274bd8, {entry_number:6, base_addr:0×8d274b90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0×8d274bd8) = 9402 sched_setscheduler(9402, SCHED_OTHER, { 5 }) = -1 EINVAL (Invalid argument) futex(0xa2b2dd4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xa2b2dd0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xa2b2ce8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xa2b2f4c, FUTEX_WAIT_PRIVATE, 1, NULL

As it turned out a “preferred option” was not set correctly.

In order to deploy the BussinessObject files on a Oracle Application Server 10.1.3.1.0 succesfully, you need to adjust the
Max Heapsize to 1024M and -XX:MaxPermSize=256m. This can be done from within the ascontrol tool of the Oracle Application Server 10.1.3.1.0 ( http://server/em ).

EMAGENT defunct spawns on an Application Server 10.1.2.0.2

Alot of emagent defunct processes are spawned on an Application Server 10.1.2.0.2.

[oracle@xxx bin]$ ps -ef | grep defunct

…
oracle 18274 10893 0 Mar11 ? 00:00:17 [emagent]
oracle 28218 10893 0 Mar12 ? 00:00:18 [emagent]
oracle 5595 10893 0 Mar27 ? 00:00:12 [emagent]
oracle 19773 10893 0 Apr06 ? 00:00:25 [emagent]
oracle 11317 10893 0 Apr21 ? 00:00:15 [emagent]
oracle 30937 10893 0 Apr22 ? 00:00:14 [emagent]
oracle 9499 10893 0 Apr24 ? 00:00:13 [emagent]
oracle 14341 10893 0 May08 ? 00:00:15 [emagent]
oracle 500 10893 0 May15 ? 00:00:17 [emagent]
oracle 20530 10893 0 May21 ? 00:00:12 [emagent]
oracle 19296 10893 0 Jun11 ? 00:00:13 [emagent]
oracle 22293 10893 0 Jun14 ? 00:00:13 [emagent]
oracle 2288 10893 0 Jun18 ? 00:00:13 [emagent]
…

This can be traced back to the iasconsole process that calls for a “Windows_NT” file which is not available on the server.

[oracle@xxx bin]$ ps -ef | grep 10893

oracle 10893 1 0 Feb10 ? 00:01:02 /u00/oracle/product/10.1.2/as/perl/bin/perl /u00/oracle/product/10.1.2/as/bin/emwd.pl iasconsole /u00/oracle/product/10.1.2/as/sysman/log/emiasconsole.nohup

This is causing the system to spawn defunct processes which intime will cause the server to hang.

Solution wil be to :
( perform as the oracle user )

Stop the iasconsole by executing “./emctl stop iasconsole” on the commandline from the $ORACLE_HOME/bin

cd $ORACLE_HOME/bin

touch Windows_NT

chmod 544 Windows_NT

Start the iasconsole by executing “./emctl start iasconsole” on the commandline from the $ORACLE_HOME/bin

(Reference : BUG 5504078 EMWD.PL SPWANS DEFUNCT PERL PROCESSES AFTER OMS PATCH 10.1.2.0.2)

error: org/apache/log4j/Category while deploying BussinessObject ix 3.1 on an Oracle Application Server 10.1.3.4.0

Manually deploying the InfoViewApp under the home ocj4 container works fine, but when deployed under its own container returns this error;

[12-jun-2009 10:36:11] Binding InfoViewApp web-module for application InfoViewApp to site default-web-site under context root InfoViewApp
[12-jun-2009 10:36:12] Operation failed with error: org/apache/log4j/Category

As it turned out i ran into a bug reported on Metalink;

Unpublished Bug 5871305 : APACHE.COMMONS.LOGGING LIBRARY HAS DEPENDENCY ON LOG4J CLASSES

In the OC4J class loading framework, by default, system level shared library takes precedence to that of application
defined shared library. commons-logging.jar is defined as a system level shared library in OC4J.
This shared library has a dependency on log4j.x.jar file which has not been properly declared.
A properly defined shared library should declare and resolve all its dependencies.
This error is reported in unpublished Bug 5871305

A couple of solution are possible here,

* The issue will be fixed in version 10.1.3.5.0. so wait for that
* Use this workaround

Remove the inherited system library “apache.commons.logging” from the application. .
One of the ways of doing is this to update the application’s orion-application.xml with the following lines:

<imported-shared-libraries>
  <remove-inherited name="apache.commons.logging"/>
</imported-shared-libraries>
 

Repackage the ear file with the updated orion-application.xml and deploy the application again.

As both are not suitable here i would recommend to downgrade to 10.1.3.1.0 as this error would not occure on this version( i applied this option ) or deploy your app under the home container for the time being.

runInstaller Segmentation fault

Today i was challanged with an error which suddenly appeared after running multiple installs on the system.

oracle@xxx 1021 $ ./runInstaller
Starting Oracle Universal Installer…

Checking installer requirements…

./runInstaller: line 65: 4245 Segmentation fault $CMDDIR/install/runInstaller -oneclick SHOW_CUSTOM_TREE_PAGE=false $*

when strace is used to find the error occuring i was able to find this ;

oracle@xxx 1021 $ strace ./runInstaller -oneclick SHOW_CUSTOM_TREE_PAGE=false $*

…
…
write(3, “\nChecking operating system versi”…, 44) = 44
write(3, “redhat-Red Hat Enterprise Linux “…, 192) = 192
access(“/etc/redhat-release”, F_OK) = 0
stat64(“/etc/redhat-release”, {st_mode=S_IFREG|0700, st_size=45, …}) = 0
open(“/etc/redhat-release”, O_RDONLY) = -1 EACCES (Permission denied)
— SIGSEGV (Segmentation fault) @ 0 (0) —
+++ killed by SIGSEGV +

As it turned out , someone just changed the security properties on the redhat-release file so that public could not read it anymore.

WRONG
-rw——- 1 root root 56 Apr 11 2007 redhat-release
(chmod 600 )

RIGHT
-rw-r–r– 1 root root 56 Apr 11 2007 redhat-release
(chmod 644)

After changing this back to original chmod 644 , the installer started perfectly

-bash: /bin/rm: Argument list too long

Ever ran into this error ?
Well the solution other then removing the directory and recreating it would be to run a command similar to this from within the directory you want to clean;

find . -name ‘*.trm’ | xargs rm
find . -name ‘*.trc’ | xargs rm

Just a nice to know :)