John Paul van Helvoort, Linux, Tips & Tricks
|
Tags: Linux 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:/>
John Paul van Helvoort, Oracle Application Server
|
Tags: Oracle Application Server 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
John Paul van Helvoort, Oracle Database, Oracle RMAN
|
Tags: Oracle Database,
Oracle RMAN Inleiding
Naast het installeren van de Oracle software volgens de Optimal Flexible Architecture (OFA) richtlijnen is een gedegen backup en recovery procedure ondenkbaar in een productie omgeving. Een correcte installatie en configuratie is cruciaal voor het slagen van welk project dan ook en voor de juiste inrichting van een backup en recovery strategie van een organisatie in het algemeen. Onze ervaring leert dat indien men dit niet tijdens de installatie correct uitgevoerd, dit zal leiden tot complexe herstel werkzaamheden achteraf. De technieken die Oracle ter beschikking stelt voor het online veiligstellen van data zijn voor de Database Server RMAN en voor de Applicatie Server Oracle backup scripts, welke de noodzakelijke configuratie files verzamelen en wegschrijven naar een zelf te kiezen locatie (bijvoorbeeld op een SAN systeem).
Oracle Database Backup
De meest gebruikte en meest betrouwbare backup methode die Oracle nu kent voor haar databases is RMAN. RMAN maakt het mogelijk een online backup te maken van een database naar een zelf te kiezen veilige online filesysteem locatie. De backup wordt samengesteld uit een set componenten welke middels policy’s bijhoud wanneer een backupset veroudert is en opgeruimt kan worden. Deze techniek stelt de beheerder in staat altijd een actuele backup onder handen te hebben die geen overbodige informatie bevat. De backup methode wordt meestal in de avond uren ingepland en kan, indien nodig, tijdens kantoor uren bijgewerkt worden met alleen transactie logging data van die dag (incrementele archive logs ). Dit geeft de beheerder de mogelijkheid herstel werkzaamheden uit te voeren tot de laatste transactielog van de database in geval van een disaster recovery. Ongeacht de frequentie van de de backup taken is er geen garantie op de laatste data bij database problemen (er kan tijdens een transactie een database crash optreden). Naast de kans op het verliezen van kostbare data zal er ook hersteltijd noodzakelijk zijn om een backup terug te zetten op een andere database server. De database zal gedurende deze werkzaamheden niet bereikbaar zijn.
Mocht meer data zekerheid vereist zijn of een hogere beschikbaarheid wenselijke zijn, dan adviseren wij naast het maken van een RMAN backups, een standby database aan te maken. Voor het managen van de standby database adviseren wij de Oracle Data Guard techniek in te zetten. Deze techniek zorgt voor een gecontroleerde manier van “dupliceren” van data. In geval van problemen kan tevens direct overgeschakeld worden naar de 2de locatie om zo de continuïteit en de beschikbaarheid te waarborgen voor de organisatie. Hieronder staat schematisch aangegeven hoe dit precies werkt:

De primary database stuurt transactie logging (archivelogs) via SQLnet naar de standby database welke in een “online recovery” mode staat (door deze modues hoeft deze 2de database niet apart gelicenseerd te worden, deze 2de database mag in dit geval maximaal 7 dagen per jaar online worden ingezet). Hierdoor zal de database altijd de laatste gegevens bevatten in geval van een primare database problemen. Een relatief simple actie maakt het mogelijk om door te werken op de standby database onderwijl de primare site opnieuw opgebouwd wordt.
Oracle Applicatieserver Backup
Voor het veiligstellen van de applicatie server data wordt er door Oracle standaard scripts meegeleverd die de gebruikte configuratie veiligstelt op een zelf aan te geven online filesysteem locatie. Bij problemen is het mogelijk deze backup terug te lezen om zo weer de laatste “juiste” configuratie te gebruiken. Deze script bevatten in principe voldoende informatie om een primaire vorm van backup en recovery te implementeren in de organisatie.
John Paul van Helvoort, Oracle Application Server
|
Tags: Oracle Application Server 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 ).

John Paul van Helvoort, Oracle Application Server
|
Tags: Oracle Application Server 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)
John Paul van Helvoort, Oracle Application Server
|
Tags: Oracle Application Server 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:
[code lang='xml']
[/code]
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.
John Paul van Helvoort, Linux
|
Tags: Linux 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
John Paul van Helvoort, Linux
|
Tags: Linux 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 :)